SOA Start of Authority Flagship

What it's for

The SOA (Start of Authority) record is the very first record in every DNS zone, and every zone has exactly one. It doesn't route traffic or resolve anything by itself — instead, it holds the administrative metadata that describes the zone: who's the primary nameserver, who to contact about it, and a set of timing values that control how secondary nameservers stay in sync with the primary.

Think of it as the "header" of a zone file. Every other record (A, MX, TXT, etc.) exists within the zone that the SOA record describes.

Format & syntax

example.com.  86400  IN  SOA  ns1.example.com. admin.example.com. (
                              2026081601  ; serial
                              7200        ; refresh
                              3600        ; retry
                              1209600     ; expire
                              300 )       ; minimum TTL

• MNAME — the primary/master nameserver for the zone (ns1.example.com.)
• RNAME — the admin contact email, written with the @ replaced by a . (so [email protected] becomes admin.example.com.) — a historical DNS quirk that trips people up constantly
• Serial — a number that must increase every time the zone changes, used by secondary nameservers to know whether they need to re-sync. Commonly formatted as YYYYMMDDNN (date plus a same-day revision counter)
• Refresh — how often (seconds) secondaries should check the primary for updates
• Retry — how long secondaries wait before retrying if a refresh attempt failed
• Expire — how long secondaries can keep serving stale data if they can't reach the primary at all, before considering their copy invalid
• Minimum TTL — historically the default TTL for records without an explicit one; per RFC 2308 this field's modern meaning is specifically the TTL for negative (NXDOMAIN) caching

How it's used in practice

• Zone transfer synchronization — the refresh/retry/expire values are the whole reason secondary (slave) nameservers know when to pull updates from the primary in a classic primary/secondary DNS setup.
• Negative caching control — the minimum field controls how long resolvers cache "this name doesn't exist" answers, which matters for how quickly a newly created record becomes visible after a period of NXDOMAIN.
• Debugging zone propagation — checking the SOA serial number across different nameservers is a standard way to confirm whether a change has actually propagated to all of a domain's authoritative servers, independent of any specific record.
• Modern managed DNS — most people never hand-edit an SOA record directly since managed providers (Cloudflare, Route 53) auto-generate and auto-increment it; it's mostly relevant when running your own BIND/PowerDNS infrastructure or troubleshooting propagation issues.

Common mistakes & gotchas

• Forgetting to bump the serial number — on manually managed zone files (BIND, etc.), if you edit records but don't increase the serial, secondary nameservers won't notice anything changed and won't re-sync — your primary and secondaries silently diverge.
• Serial number rollover/format mistakes — using a serial format that can't safely increase forever (or that resets and goes backward) can confuse secondaries into thinking a legitimately newer zone is older. The YYYYMMDDNN convention exists specifically to avoid this.
• Confusing the RNAME email format — admin.example.com. in an SOA record means [email protected], not a subdomain called "admin." This trips up almost everyone the first time they read a raw zone file.
• Refresh/retry/expire values set too conservatively — very long refresh intervals mean secondary nameservers can lag behind the primary for a long time after a change, which looks like "propagation is slow" even though it's really just the SOA timers doing exactly what they were configured to do.
• Only one SOA record, always — a zone with more than one SOA record (or SOA on the wrong name) is invalid and will cause resolution problems; this is rarely a manual mistake with managed providers but is a real footgun in hand-maintained zone files.

Comparison & FAQ

Do I need to manually manage my SOA record?

Almost never with a managed DNS provider — they auto-generate and auto-increment it. It matters much more if you're running your own authoritative nameserver software (BIND, PowerDNS, NSD) with primary/secondary zone transfers.

What does the SOA serial number actually control?

It tells secondary nameservers whether the zone has changed since their last sync. If the serial hasn't increased, secondaries assume nothing changed and won't pull a fresh copy — so a manually edited zone with a stale serial can leave secondaries out of date indefinitely.

Why does the SOA record show an email address with a dot instead of an @?

It's a historical DNS encoding convention — the @ symbol has special meaning in zone file syntax, so the admin contact's @ is replaced with a .. admin.example.com. decodes to [email protected].

What's the "minimum TTL" field actually used for today?

Its modern, spec-defined purpose (per RFC 2308) is controlling how long resolvers cache negative answers — i.e., how long a "this record doesn't exist" (NXDOMAIN) response stays cached before a resolver will check again.