The DNS SOA Record Explained

Every DNS zone begins with a single record that quietly governs how the rest of the zone behaves: the SOA, or Start of Authority. It names the primary nameserver, records a contact address, and carries the timers that secondary servers obey when they copy and refresh the zone. Most people never touch it because their DNS provider manages it automatically, yet when something goes wrong, such as a change that never appears on a backup nameserver or two servers disagreeing about your records, the SOA is almost always where the answer hides. This guide explains what the SOA is, decodes every field, shows how secondary servers use those numbers, and covers the common problems and how to inspect your own. You can read your domain's SOA at any time with the SOA Lookup tool.

The SOA record marks the start of authority for a DNS zone, meaning it identifies the server that holds the original, authoritative copy of that zone's data and sets the administrative parameters everyone else follows. A zone is the slice of the DNS namespace you control, for example everything at and under example.com. By the rules of DNS, every zone has exactly one SOA record, and it must appear at the apex of the zone (the bare domain name, example.com, not www or any subdomain). It is not optional: a zone without a valid SOA is malformed, and most nameservers will refuse to load it.

The SOA does not point users to your website or mail; that is the job of A, AAAA, and MX records. Instead it answers a different set of questions: who is the master copy of this zone, who do I contact about it, which version of the data is current, and how long should the backup servers wait before checking for updates or giving up.

The first two fields of an SOA are names rather than numbers. MNAME is the fully qualified hostname of the primary (master) nameserver for the zone, the server treated as holding the original copy of the data. It is also the server that dynamic-update clients send changes to. Note that MNAME is informational about which server is the master; it is not necessarily the same list of servers published in your delegation, which lives in your NS records. You can compare the two with the Nameserver Lookup tool to confirm your delegation matches what you expect.

RNAME is the email address of the person or team responsible for the zone, written with a quirk that confuses almost everyone the first time they see it. Because the @ sign has special meaning in zone files, it is replaced by a dot. So the contact [email protected] is written hostmaster.example.com in the SOA. If the local part of the address itself contains a dot, that dot is escaped with a backslash. When reading an SOA, replace the first unescaped dot with @ to recover the real address; the convention is to use a role mailbox such as hostmaster, which is reserved for exactly this purpose.

The SERIAL is a 32-bit number that acts as the version stamp for the zone. Its single job is to tell secondary nameservers whether the zone has changed: when a secondary checks in, it compares the master's serial against the copy it already holds. If the master's serial is higher, the secondary knows there is a newer version and pulls it; if the serial is the same or lower, the secondary assumes nothing changed and does nothing. This means the cardinal rule of editing a zone by hand is simple: every time you change any record, you must increase the serial. Forget to, and your edits will never reach the secondaries.

The most widely used convention encodes the serial as a date plus a daily counter in the form YYYYMMDDnn. For example 2026062701 means the first revision made on 27 June 2026, and a second edit that day would become 2026062702. This is human-readable and naturally increasing, which is why so many operators adopt it. The format is only a convention, though; DNS itself just requires the number to grow. Some automated systems prefer a plain incrementing counter or a Unix timestamp. Whichever you choose, the serial must move forward and stay within the 32-bit range, and you should not mix incompatible schemes once you have picked one.

The remaining four SOA fields are time values, expressed in seconds, that control the relationship between the master and its secondaries and the caching of negative answers. REFRESH is how often a secondary should check the master's serial to see whether the zone has changed; a common value is 3600 to 14400 seconds (one to four hours). RETRY is how long a secondary waits before trying again if a refresh attempt fails, and it should be shorter than REFRESH; values around 900 to 3600 seconds are typical.

EXPIRE is the safety limit: if a secondary cannot reach the master for this entire span, it stops serving the zone altogether rather than handing out data that may be hopelessly stale. Because it represents a worst-case outage, EXPIRE is deliberately long, often a week (604800 seconds) or two. MINIMUM is the final field, and in modern DNS its job is to set the negative-caching TTL, that is, how long resolvers may cache a "this name does not exist" (NXDOMAIN) answer. Historically MINIMUM also served as a default TTL for the whole zone, but that role has been superseded; today the negative TTL is the smaller of the SOA record's own TTL and this MINIMUM value. This is why a brand-new record can appear missing for a while after you create it, because resolvers cached the earlier negative answer for the MINIMUM duration. You can see every one of these timers laid out for any domain with the SOA Lookup tool.

The SOA timers exist for one purpose: to coordinate zone transfers between a master and its secondary (slave) nameservers. Running more than one authoritative server is good practice, and even required by many registries, but only one holds the editable original. The others keep synchronized copies, and the SOA tells them how. The cycle runs like this: every REFRESH seconds, each secondary queries the master for its SOA and compares the SERIAL with its own. A higher serial on the master triggers a zone transfer (an AXFR for the full zone, or an IXFR for just the changes) to pull the new data.

When a refresh fails, perhaps the master is down or a link is broken, the secondary waits RETRY seconds and tries again, repeating until it succeeds or reaches the EXPIRE limit. If EXPIRE is hit without a single successful contact, the secondary concludes its data is too old to trust and stops answering queries for the zone entirely, so resolvers fall through to servers that are still healthy. Modern setups often supplement this polling with NOTIFY messages, where the master tells secondaries the moment a change is made, so updates land in seconds rather than waiting for the next REFRESH; the SOA timers remain the fallback when NOTIFY does not arrive.

By far the most common SOA mistake is editing a zone and forgetting to increment the serial. The master serves the new records immediately, but every secondary sees an unchanged serial and never pulls the update, so you end up with authoritative servers that disagree. Symptoms are intermittent: users land on different servers and get different answers depending on which nameserver their resolver happened to query. The fix is to bump the serial and let the secondaries refresh. The mirror-image problem is a serial that was set too high by accident (for example a fat-fingered future date); because the serial can only safely go up, recovering from an over-large serial is awkward and sometimes requires a documented reset procedure.

Mismatched serials between your nameservers are the clearest red flag and worth checking routinely. If you query each authoritative server for the SOA and the serials differ, your servers are out of sync, whether because of a missed transfer, a blocked AXFR, a NOTIFY that never arrived, or a forgotten increment. Other recurring issues include an RNAME with a literal @ instead of the dot form, REFRESH and RETRY values set unrealistically low (hammering the master) or absurdly high (slow propagation between servers), and an EXPIRE shorter than REFRESH, which makes no logical sense. If your zone is signed, remember that any zone change must be re-signed, and the DNSSEC Check tool can confirm the signatures are valid after an update.

The fastest way to read a zone's SOA is the SOA Lookup tool, which fetches the record and breaks out the primary nameserver, the contact address (with the @ restored), the serial, and all four timers in plain language. On the command line, dig example.com SOA returns the same fields, printed in the order MNAME, RNAME, SERIAL, REFRESH, RETRY, EXPIRE, MINIMUM. To diagnose synchronization problems, query each authoritative server directly, for example dig @ns1.example.com example.com SOA and dig @ns2.example.com example.com SOA, then compare the serials; matching numbers mean the servers agree, and differing numbers point straight to a transfer or increment problem.

When you have just published a change, the SOA serial is also a handy progress marker. Confirm the new serial is live on every authoritative server first, then watch the actual records spread through the world's caches with the DNS Propagation tool, which compares answers from many locations at once. For a complete picture of a zone, pair the SOA check with a full record lookup using the DNS Lookup tool so you can see the SOA timers alongside the A, MX, and NS records they govern.