An SOA (Start of Authority) record is the mandatory DNS record that opens a zone and stores its administrative parameters: the primary name server, the responsible party's e-mail, a serial number, and refresh timers. Secondary servers read its serial to decide whether the zone changed and to trigger a transfer. One SOA per zone.
This guide walks through all seven SOA fields defined in RFC 1035, the YYYYMMDDnn serial format, the role of minimum as the negative TTL from RFC 2308, how SOA drives primary/secondary zone transfers, verification with dig, and common mistakes such as forgetting to bump the serial. Written for domain admins and DevOps.
What an SOA record is
SOA (Start of Authority) is defined in RFC 1035 as the first record in a zone file. It declares that the server is authoritative for the zone and sets the global parameters that govern how the zone is served. Every zone has exactly one SOA record, placed at the apex name (for example, example.com.).
The SOA is invisible to ordinary visitors but critical to infrastructure: secondary servers use it to decide whether to transfer the zone, and resolvers use it to know how long to cache negative answers (NXDOMAIN). A broken SOA does not take a site down instantly, but it desynchronizes servers and slows the propagation of every change you make.
The fields of an SOA record
An SOA holds two names (MNAME, RNAME) and five numeric timers. In a classic record it appears as one logical line, split across parentheses for readability.
MNAME — the primary name server
The fully qualified domain name of the primary (master) name server — the source of truth that secondaries pull from. MNAME is also used by DNS NOTIFY: this is the server that announces changes. Make sure MNAME points to a genuinely authoritative server, otherwise NOTIFY messages have no valid origin and transfers rely only on timers.
RNAME — the administrator e-mail
The contact for whoever is responsible for the zone, written in DNS format with the @ replaced by a dot. So hostmaster.example.com. means the address hostmaster@example.com. If the local part contains a dot, it is escaped with a backslash. Keep this mailbox monitored — problem notifications go there.
Serial — the version number
A 32-bit integer that is the zone's version. Every change to the zone file must increase the serial. A secondary compares its own serial with the primary's: if the primary's is higher, a transfer starts. If you forget to bump the serial, secondaries treat the zone as unchanged and keep serving stale data.
Refresh, Retry, Expire, Minimum
Four timers control the life cycle of zone transfer and caching. Refresh — how often the secondary checks the serial; Retry — the pause before retrying after a failure; Expire — when the secondary declares its data stale and stops answering; Minimum — the negative-caching TTL defined in RFC 2308.
| Field | Purpose | Typical value |
|---|---|---|
| MNAME | Primary NS server (zone source) | ns1.example.com. |
| RNAME | Admin e-mail in DNS format | hostmaster.example.com. |
| Serial | Zone version, grows on every change | 2026071301 |
| Refresh | How often the secondary checks serial | 7200 (2 h) |
| Retry | Pause before retry after failure | 3600 (1 h) |
| Expire | Data lifetime with no contact to primary | 1209600 (14 d) |
| Minimum | Negative-cache TTL (NXDOMAIN) | 3600 (1 h) |
Serial format: YYYYMMDDnn
The serial is simply an increasing number, but in practice almost everyone encodes the date: YYYYMMDDnn, where nn is a per-day edit counter. For example, 2026071302 is the second edit on 13 July 2026. This format is readable, increases monotonically, and survives several edits per day.
The key rule is that the serial must strictly increase. Mind the serial arithmetic in RFC 1982: the value is 32-bit and wraps around. Decreasing the serial (for example, rolling back to yesterday's date) can make secondaries read it as no change and skip the update entirely.
Example SOA record
$TTL 3600
example.com. IN SOA ns1.example.com. hostmaster.example.com. (
2026071301 ; Serial (YYYYMMDDnn)
7200 ; Refresh — 2 hours
3600 ; Retry — 1 hour
1209600 ; Expire — 14 days
3600 ) ; Minimum — negative TTL 1 hour
SOA and zone transfers
The SOA is the engine of replication between the primary and secondary servers. A standard cycle looks like this:
- The primary server changes the zone and increments the serial.
- On NOTIFY (or when Refresh elapses) the secondary queries the primary's SOA.
- The secondary compares serials: if the primary's is higher, it starts an AXFR (full) or IXFR (incremental) transfer.
- If the primary is unreachable, the secondary retries every Retry seconds.
- If contact is lost longer than Expire, the secondary stops considering itself authoritative and answers SERVFAIL.
That is why Expire must always be noticeably larger than Refresh and Retry — otherwise a brief primary outage lets the whole zone expire on the secondaries.
How to check an SOA record
The fastest way is the dig utility. It prints every SOA field and the current serial so you can compare it across servers.
# Short SOA output
dig SOA example.com +short
# Full output with the ANSWER section
dig SOA example.com
# Query the serial directly on a specific server
dig @ns1.example.com SOA example.com +short
To do it in a browser without installing tools, use our DNS tool: enter the domain, pick the SOA type, and compare the serial and timers. It is worth querying each authoritative server separately to confirm the serial matches everywhere.
Common mistakes
- Serial not incremented. After editing the zone you forgot to raise the number — secondaries see no change and keep old data. The single most common cause of "my change didn't apply."
- Serial decreased. A manual edit with a smaller number or a rolled-back date — secondaries ignore the transfer because of RFC 1982 arithmetic.
- Expire smaller than Refresh. A short primary outage expires the zone on secondaries and the site returns SERVFAIL.
- Minimum too large. A long negative cache means records deleted by mistake linger as NXDOMAIN in resolvers.
- Wrong RNAME. A forgotten
@-to-dot swap or a dead mailbox means problem notifications are lost.
For more on zone structure, see DNS record types, the TTL guide, and the NS record. Specifications: RFC 1035, RFC 2308, MDN: DNS.
Frequently Asked Questions
How many SOA records can a zone have?
Exactly one. The SOA must be the first record in the zone file and sit at the domain's apex name. Having two SOA records is a syntax error and the zone will not load. Every administrative parameter of the zone lives in that single record, so it can never be duplicated under any configuration.
What happens if you don't increment the serial?
The primary applies the change, but secondary servers compare serials, conclude the zone is unchanged, and skip the transfer. As a result, some resolvers get new data from the primary and others get old data from a secondary. Always raise the serial on every zone edit to keep servers in sync.
How is Minimum different from a record's TTL?
A record's TTL controls caching of positive answers. The SOA Minimum field, per RFC 2308, sets the negative-caching TTL — how long a resolver keeps an NXDOMAIN (name does not exist) answer. They are separate mechanisms: one speeds up access, the other limits repeated lookups of names that do not exist.
How do I choose SOA timer values?
Base them on update speed and link reliability. Refresh 1–4 hours, Retry 15 minutes–1 hour, Expire 1–4 weeks (always larger than Refresh), Minimum 5 minutes–1 hour. If you edit the zone often and NOTIFY works, you can raise Refresh — notifications trigger the transfer without waiting for the timer.
How do I quickly view my domain's serial?
Run dig SOA example.com +short — the serial is the third number in the output. To check synchronization, query each authoritative server separately with dig @nsX .... Without a command line, the same is available in the browser-based DNS tool from enterno.io.