SOA Records: The Start of Authority Explained

The SOA (Start of Authority) record marks the beginning of a DNS zone and holds the zone's top-level administrative settings. There is exactly one SOA record per zone, and it always lives at the zone apex — the root name of the zone itself, such as example.com. You cannot have two SOA records, and you cannot have a zone without one; it is mandatory and unique.

Because it sits at the apex, the SOA describes the whole zone rather than any single hostname. It answers three questions: which nameserver is the authoritative primary for this zone, who is the human responsible for it, and on what schedule should other nameservers and resolvers treat its data as fresh or stale. For how zones fit into the wider system, see What is DNS? and Nameservers and NS records.

An SOA record bundles three kinds of information into one entry:

• The primary nameserver — the server that holds the master copy of the zone (the MNAME field).
• The responsible party — an administrative email address, written in a special dotted form (the RNAME field).
• The timers — a serial number plus four time values (REFRESH, RETRY, EXPIRE, and MINIMUM) that govern zone transfers and negative caching.

The next two sections break those fields down one by one.

An SOA record has seven fields. The first two are names; the rest are numbers:

MNAME	The primary (master) nameserver for the zone — the server considered the authoritative source of the zone data, e.g. ns1.example.com.
RNAME	The responsible party's email, with the @ written as a dot. So hostmaster.example.com means hostmaster@example.com.
SERIAL	The zone's version number. You must increase it on every edit; secondaries compare it to decide whether to pull a fresh copy. A common convention is YYYYMMDDnn (date plus a two-digit counter), e.g. 2026061901.
REFRESH	How often (in seconds) a secondary checks the primary's serial to see if the zone has changed.
RETRY	How long a secondary waits before trying again after a failed refresh attempt.
EXPIRE	How long a secondary keeps serving the zone if it cannot reach the primary at all. After this, it stops answering for the zone.
MINIMUM	The negative-caching TTL — how long resolvers may cache "no such record" (NXDOMAIN) answers, per RFC 2308.

The RNAME dotted form trips people up: because the local part is encoded with a dot, an address like john.doe@example.com has to escape that internal dot. In practice administrators avoid the issue by using a simple role mailbox such as hostmaster — which is exactly why hostmaster.example.com is the conventional value.

The timers exist to keep secondary (slave) nameservers in sync with the primary (master). The primary holds the editable copy of the zone; each secondary pulls a copy via a zone transfer and serves identical answers. The SOA timers choreograph that relationship:

1. Every REFRESH seconds, a secondary asks the primary for its SOA and compares the SERIAL. If the primary's serial is higher, the zone changed, so the secondary transfers the new version.
2. If that check fails (the primary is unreachable), the secondary waits RETRY seconds and tries again, repeating until it succeeds.
3. If the primary stays unreachable for as long as EXPIRE, the secondary decides its data is too old to trust and stops serving the zone entirely, rather than handing out stale answers indefinitely.

So EXPIRE should always be comfortably larger than REFRESH and RETRY — it is the safety net for a prolonged primary outage. The SERIAL is the linchpin of the whole loop: it is the single signal a secondary uses to know whether anything needs transferring.

Here is a realistic SOA record for example.com:

• MNAME: ns1.example.com — the primary nameserver.
• RNAME: hostmaster.example.com — i.e. hostmaster@example.com.
• SERIAL: 2026061901 — the zone was last edited on 2026-06-19 (first change of the day).
• REFRESH: 7200 — secondaries check for changes every 2 hours.
• RETRY: 3600 — after a failed check, retry every 1 hour.
• EXPIRE: 1209600 — keep serving for up to 14 days without reaching the primary.
• MINIMUM: 3600 — cache "no such record" answers for 1 hour.

In standard zone-file form the same record reads roughly: example.com. IN SOA ns1.example.com. hostmaster.example.com. 2026061901 7200 3600 1209600 3600. Read left to right, those numbers are serial, refresh, retry, expire, and minimum.

The single most common SOA mistake is editing the zone but forgetting to increase the SERIAL. Remember that secondaries detect changes purely by comparing the serial. If you change an A record but leave the serial untouched, each secondary's periodic check sees the same number it already has, concludes nothing changed, and never pulls the update.

The result is a split-brain zone: the primary serves the new answer, but every secondary keeps serving the old one until something else forces a transfer. Because resolvers treat all authoritative nameservers as equal, visitors get inconsistent results depending on which nameserver they happen to reach. The fix is simple discipline — increase the serial on every edit — which is exactly why the YYYYMMDDnn convention is so popular: it makes a forgotten bump easy to spot and keeps serials monotonically increasing.

If you run your DNS through a managed provider — a registrar's DNS, a cloud DNS service, or a CDN's DNS — you usually never touch the SOA by hand. The provider creates the SOA automatically when the zone is set up, fills in its own primary nameserver and a default responsible-party address, and picks sensible default timers.

Crucially, these providers bump the serial for you on every change you make through their dashboard or API, so the stale-secondary problem above simply doesn't arise. Many large providers also run their own internal replication rather than classic public zone transfers, so the REFRESH/RETRY/EXPIRE values you see are essentially informational. The fields most worth checking on a managed zone are the MNAME (does it point at the right provider?) and the MINIMUM negative-cache TTL.

The MINIMUM field no longer means what its name suggests. Originally it was a floor on record TTLs; under RFC 2308 it was redefined to set the negative-caching TTL — how long a resolver may cache a negative answer such as NXDOMAIN ("this name does not exist") or a "no records of this type" response.

This matters more than it looks. If you create a brand-new subdomain and resolvers recently cached an NXDOMAIN for it, that name can appear "not to exist" until the negative cache expires — governed by MINIMUM. A long MINIMUM makes mistakes and absences linger; a short one lets new names appear faster but slightly increases query load. It is the negative-answer counterpart to a record's own TTL, covered fully in TTL and propagation.

To see a domain's SOA record, run it through the who.is DNS lookup and look for the SOA entry. You'll see the primary nameserver, the responsible-party address, the current serial, and the four timers — a quick way to confirm the zone is hosted where you expect and that its serial is advancing as it should.

Pair it with the nameserver lookup to confirm the MNAME matches the delegated nameservers, and with WHOIS for the registration-side view. When the SOA's primary nameserver, the delegation, and WHOIS all agree, your zone is healthy and consistently configured.