DNS SOA Record: Structure, Fields & Examples
A DNS SOA (Start of Authority) record holds the administrative metadata for a DNS zone: which server is the primary source of truth for the domain, who is responsible for it, and the timers that control how secondary name servers and resolvers refresh and cache the zone. Every properly configured zone has exactly one SOA record, and it always sits at the zone apex (the domain root, e.g. example.com).
What is an SOA record?
SOA stands for Start of Authority. Defined in RFC 1035 and updated by RFC 2308, it marks the beginning of a zone's authoritative data. Its job is not to route traffic — that is the job of address records like A and AAAA — but to describe how the zone itself is managed and replicated. When a secondary (slave) name server decides whether to pull a fresh copy of the zone, and when a resolver decides how long to cache a "this name does not exist" answer, both read values straight from the SOA record.
SOA record structure and fields
An SOA record contains two name fields followed by five numeric timers. In standard zone-file syntax it looks like this:
example.com. 3600 IN SOA ns1.example.com. hostmaster.example.com. (
2024010101 ; Serial
7200 ; Refresh (2 hours)
3600 ; Retry (1 hour)
1209600 ; Expire (2 weeks)
3600 ) ; Minimum (negative-cache TTL, 1 hour)| Field | Meaning |
|---|---|
| MNAME | The primary (master) name server that holds the original zone data — here ns1.example.com. |
| RNAME | The email address of the person responsible for the zone, with the first dot standing in for @. So hostmaster.example.com means [email protected]. |
| Serial | A version number for the zone. It must increase every time the zone changes; secondaries compare it to decide whether to transfer. A common format is YYYYMMDDnn (date plus a two-digit counter). |
| Refresh | How often (in seconds) a secondary checks the primary's serial for changes. |
| Retry | How long a secondary waits before retrying after a failed refresh. |
| Expire | How long a secondary keeps answering for the zone if it cannot reach the primary at all. After this, it stops serving stale data. |
| Minimum | Since RFC 2308, this is the negative-caching TTL: how long resolvers cache an NXDOMAIN (name-not-found) response for the zone. |
How to check a domain's SOA record
You can read any domain's SOA record from the command line:
# dig (Linux/macOS)
dig example.com SOA +short
# nslookup (Windows/cross-platform)
nslookup -type=soa example.comIf you would rather not touch a terminal, run the domain through the free DNS lookup tool — it returns the SOA record alongside A, AAAA, MX, NS, and TXT records in one view.
Common SOA record problems
- Serial not incremented. If you edit the zone but forget to bump the serial, secondaries never pull the change and DNS goes out of sync across servers.
- RNAME written with an @ sign. The responsible-party field uses a dot, not
@. Writing[email protected]breaks the record. - Expire shorter than Refresh × Retry. If the timers are inconsistent, a secondary can expire the zone before it has had a fair chance to refresh, causing outages.
- Minimum set very high. A large negative-cache TTL means typos and just-created records stay "not found" in resolvers for a long time.
SOA vs other DNS records
The SOA record describes the zone; the other record types describe hosts and services inside it. If you are mapping out a domain's DNS, it helps to know the neighbours: AAAA records point a hostname to an IPv6 address, NS records delegate the zone to its authoritative name servers, and PTR records handle reverse lookups from IP back to hostname.
Frequently asked questions
How many SOA records can a zone have?
Exactly one. The SOA record is unique per zone and always lives at the apex. Seeing two is a misconfiguration.
Does changing the SOA record affect my website?
Not directly — the SOA record carries no address data, so it does not move traffic. But its timers govern how quickly changes to other records propagate, and its serial controls replication to secondary name servers.
What is a good SOA serial format?
The most widely used convention is YYYYMMDDnn: the date of the change plus a two-digit counter for multiple edits in one day (e.g. 2024010102). The only hard rule is that each new serial must be larger than the last.