BUY WEBSITES
BUY DOMAINS
LOGIN
SIGNUP
The SOA Record Explained: Every Field of a DNS Start of Authority Record, and What It Means When a Domain Changes Hands
An SOA record, short for Start of Authority, is the mandatory DNS record that opens every zone and declares who is authoritative for it. Exactly one SOA record exists per zone, it sits at the zone apex, and during a zone transfer it is the first record sent.
The record packs seven administrative fields into one line: the primary nameserver, the administrator contact, a version number, and four timers that govern how a zone is kept in sync. Read correctly, those fields tell an operator whether a zone is healthy, stale, or misconfigured.
This guide defines every field against the RFCs that specify them, reads a real SOA record line by line, lists the misconfigurations that break a zone, and adds the angle the reference guides skip: what the SOA record reveals about a domain that has just changed hands. When an aged or expired domain moves to a new owner and a new DNS host, its SOA is rebuilt from scratch, and a clean record is one signal of a clean handover. SEO Domains operates the curated marketplace that screens that raw material before it changes hands, which is where a clean handover starts.
What is an SOA record?
An SOA (Start of Authority) record is a mandatory DNS resource record that holds administrative information about a zone: the primary nameserver, the responsible contact, a serial version number, and the timers that govern zone transfers. RFC 1035 defines it. Every zone carries exactly one, placed at the zone apex, and it is the first record transmitted in a zone transfer.
The phrase Start of Authority marks the point where authority for a portion of the domain name space begins. A zone is the slice of DNS that one set of nameservers answers for, and the SOA record stands at the top of that slice as its administrative header.
The plain-English definition of an SOA record
Think of a zone file as a register of every address inside a domain. The SOA record is the cover page of that register. It names the office that maintains the register, names the person responsible for it, stamps the edition number, and sets the schedule on which copies of the register are checked and renewed.
Because the cover page carries the edition number, any server holding a copy can compare its edition against the original and know in one read whether the register has been revised.
Where the SOA record sits and why it is mandatory
The SOA record lives at the zone apex, the root name of the zone, written as the @ symbol in a standard zone file. It is mandatory because the DNS specification treats a zone without an authoritative header as undefined. A nameserver that loads a zone file lacking an SOA record rejects it.
Two records are always required at the apex: the SOA record and at least one NS record listing the zone’s nameservers. The SOA names the single primary source of truth, while the NS records name every server permitted to answer for the zone.
The fields of an SOA record, one by one
An SOA record carries seven data fields wrapped in the standard resource-record envelope of name, TTL, class, and type. The seven are MNAME (primary nameserver), RNAME (administrator email), SERIAL (zone version), REFRESH, RETRY, and EXPIRE (the three zone-transfer timers), and MINIMUM (the negative-caching TTL). RFC 1035 defines the structure; RFC 2308 redefined MINIMUM.
The first two fields identify the zone’s owners. The serial tracks its version. The final four are durations in seconds that control synchronisation and caching. The table sets out each field, its job, and the source that specifies it.
| Field | What it holds | Defined or governed by |
|---|---|---|
| MNAME | The primary (master) nameserver for the zone, where authoritative edits originate | RFC 1035 |
| RNAME | The responsible administrator’s email, with the first dot read as the @ sign | RFC 1035 |
| SERIAL | The zone version number a secondary reads to detect a change | RFC 1035, conventions in RFC 1912 |
| REFRESH | Seconds a secondary waits before checking the primary for a new serial | RFC 1035 |
| RETRY | Seconds a secondary waits before retrying after a failed refresh | RFC 1035 |
| EXPIRE | Seconds after which a secondary stops answering if it cannot refresh | RFC 1035, range in RFC 1912 |
| MINIMUM | The TTL for caching a negative (NXDOMAIN) response | RFC 1035, redefined by RFC 2308 |
MNAME and RNAME: who runs the zone and who to contact
MNAME holds the hostname of the primary nameserver, the one server where authoritative changes to the zone are meant to originate. Secondary servers pull their copies from the MNAME host, so it names the single source of truth for the zone’s contents.
RNAME holds the administrator’s email address in a DNS-specific format. The @ sign is replaced by a dot, so an address of [email protected] is written as hostmaster.example.com inside the record. A literal dot in the local part is escaped, so [email protected] becomes john\.doe.example.com.
The serial and the four timers
SERIAL is an integer that increases every time the zone is edited. A secondary server compares the serial it holds against the serial on the primary, and a higher number on the primary signals that the zone changed and a transfer is due.
REFRESH, RETRY, and EXPIRE are durations in seconds that schedule those checks, and MINIMUM is the duration in seconds for which a negative answer is cached. Each carries enough behaviour to warrant its own section, covered below.
A real SOA record, read line by line
A working SOA record from a published zone makes every field concrete. The example below uses ICANN’s own zone, formatted in standard zone-file syntax. The procedure to retrieve any domain’s SOA record is a single command, dig SOA or nslookup -type=soa, and the steps that follow read each value of the output.
The standard zone-file representation places the apex symbol, class, type, the two name fields, then the five numeric values inside parentheses, each annotated with a comment. This sample is drawn from the verbatim record published in the Wikipedia reference for the SOA record.
How to retrieve and read any SOA record, step by step
The record above can be pulled for any zone from a terminal. The sequence below issues the lookup and interprets the result field by field, so a stale or misconfigured zone is visible at a glance.
-
Run the lookup
From any terminal, the command is dig SOA example.com on Linux or macOS, or nslookup -type=soa example.com on Windows. Both return the zone’s live SOA record from an authoritative nameserver. The dig form prints the seven fields on one answer line.
The mistake: querying a caching resolver and reading a stale copy. Append @ followed by the zone’s authoritative nameserver, for example dig SOA example.com @ns.example.com, to read the source directly.
-
Identify MNAME and RNAME
The first two tokens after SOA are the primary nameserver and the administrator email. In the sample, ns.icann.org is the primary and noc.dns.icann.org decodes to [email protected]. Confirm the primary names the host intended to be authoritative.
The mistake: reading the RNAME as a hostname. The first dot is the @ sign, so noc.dns.icann.org is a mailbox, not a server.
-
Read the serial
The serial 2020080302 is date-based: 2 August 2020, revision 02. A serial that has not advanced after a recent edit, or that runs backward, means secondaries are not picking up changes.
The mistake: editing a zone without incrementing the serial. Secondaries then keep serving the old data because nothing told them to transfer.
-
Check the four timers
Refresh 7200, retry 3600, expire 1209600, and the trailing 3600 negative-caching TTL are all in seconds. Confirm expire (here 14 days) is larger than refresh plus retry, and that it sits inside the RFC 1912 range, covered below.
The mistake: an expire shorter than the refresh-plus-retry cycle. A secondary can then stop answering before it has finished trying to refresh.
The serial number: three conventions for versioning a zone
The serial number is the zone’s version counter, and it must rise on every edit. Three conventions are in common use: a plain sequential counter, a date-based YYYYMMDDnn format recommended in RFC 1912, and a Unix-epoch timestamp used by djbdns. All three share one rule, the number only goes up, because a secondary treats a higher serial as the signal to transfer.
Sequential, date-based, and epoch serials
The sequential convention starts at 1 and adds 1 with each change. It is simple but carries no information about when the edit happened.
The date-based convention, recommended by RFC 1912, writes the serial as YYYYMMDDnn: the four-digit year, two-digit month, two-digit day, and a two-digit revision counter for that day. A serial of 2017031404 reads as the fifth edit on 14 March 2017, since the counter starts at 00. This format dominates production zones because the date is legible at a glance.
The epoch convention, the default in djbdns, stores the number of seconds since 1 January 1970. It rises automatically with every passing second and, as the Wikipedia reference notes, is not exposed to the year 2038 rollover that affects 32-bit time storage.
Sequential
Begins at 1, increments by 1 per change. Minimal, but reveals nothing about edit timing. Easy to break by forgetting to advance it.
Date-based YYYYMMDDnn (RFC 1912)
Encodes year, month, day, and a daily revision counter. The dominant convention because the edit date is readable in the number itself.
Unix epoch (djbdns)
Seconds since 1 January 1970, rising on its own. Avoids the year 2038 issue, but the value is not human-readable without conversion.
The rule all three obey
The serial only ever increases. A serial that goes backward, or wraps past its maximum, stalls zone transfers because secondaries no longer see a higher number to act on.
Refresh, retry, and expire: the zone-transfer timers
Refresh, retry, and expire are three durations in seconds that schedule how a secondary nameserver keeps its copy of a zone current. Refresh sets the check interval, retry sets the wait after a failed check, and expire sets the deadline after which a secondary stops answering. RFC 1912 recommends an expire of 2 to 4 weeks, and a sound configuration keeps expire larger than refresh plus retry.
What each timer controls
Refresh is the interval a secondary waits before asking the primary whether the serial has changed. A shorter refresh propagates edits faster but adds query load. Retry is the shorter interval a secondary waits before trying again after a refresh attempt fails to reach the primary.
Expire is the safety limit. If a secondary cannot reach the primary for the full expire duration, it concludes its data is too stale to trust and stops answering authoritatively for the zone. This prevents an isolated secondary from serving outdated records indefinitely.
| Timer | What it sets | A common value (seconds) | Reference point |
|---|---|---|---|
| Refresh | How often a secondary checks the primary’s serial | 3,600 to 86,400 (1 to 24 hours) | nslookup.io suggests 3,600; RFC 1035 sample uses 86,400 |
| Retry | Wait before retrying a failed refresh | 3,600 to 7,200 (1 to 2 hours) | Shorter than refresh, per common practice |
| Expire | Deadline before a secondary stops answering | 1,209,600 to 2,419,200 (2 to 4 weeks) | RFC 1912 recommended range |
| Negative TTL (minimum) | How long a negative answer is cached | 60 to 3,600 (1 minute to 1 hour) | RFC 2308 governs the meaning |
The timers and classic zone transfer
Refresh, retry, and expire govern the classic primary-and-secondary model, where a secondary pulls the zone over a transfer protocol. As the nslookup.io reference notes, modern cloud DNS providers replicate zones through proprietary database mechanisms, so on those platforms the three timers have little practical effect while the serial and the negative TTL still do. An operator running a self-hosted secondary, by contrast, depends on all three.
Minimum TTL and negative caching
The MINIMUM field originally set a floor on record TTLs, but RFC 2308 redefined it in 1998 as the negative-caching TTL: the duration for which a resolver caches a negative answer, such as a non-existent record. The effective negative-cache time is the smaller of the SOA record’s own TTL and this minimum value.
What negative caching does
When a resolver queries a name that does not exist, the authoritative server returns an NXDOMAIN, meaning no such record. Negative caching lets the resolver remember that absence so it does not re-query the authoritative server for every repeat lookup of the missing name. The MINIMUM field sets how long that memory lasts.
Under RFC 2308, the negative answer is cached for the lesser of the SOA TTL and the MINIMUM value. A minimum of 3,600 caches a not-found result for up to an hour, which cuts load but also delays the visibility of a newly added record by the same amount.
Why the redefinition matters
Before RFC 2308, the MINIMUM field was read as a lower bound on every record’s TTL, which produced inconsistent behaviour across resolvers. The 1998 redefinition narrowed it to negative caching alone, and that is the meaning every current resolver applies. Reading an old SOA record with the pre-2308 assumption is one way operators misjudge how a zone caches.
Common SOA misconfigurations and how to fix them
A handful of SOA mistakes account for the bulk of zone-sync and caching problems: a serial that does not advance, an expire outside the RFC 1912 range, an expire shorter than refresh plus retry, a wrong primary in MNAME, a malformed RNAME, and a negative TTL set so high that new records lag. Each has a direct, documented fix. The table consolidates them.
The left column is the misconfiguration, the centre column is why it breaks the zone, and the right column is the corrective move. Read down the fix column, the pattern is a serial that always increments, timers that respect the RFC ranges and the expire invariant, and contact and primary fields that are accurate.
| The misconfiguration | Why it breaks the zone | The fix |
|---|---|---|
| Serial not incremented after an edit | Secondaries see no higher number and never transfer the change, so they serve stale records | Advance the serial on every edit; date-based YYYYMMDDnn makes the omission obvious |
| Serial decreased or wrapped backward | A lower serial reads as no change, stalling all transfers until corrected | Set a serial higher than the current one; if wrapped, use a documented serial-reset procedure |
| Expire outside 2 to 4 weeks | Health checkers flag it; too short risks early expiry, too long lets stale data persist | Set expire within the RFC 1912 range of 1,209,600 to 2,419,200 seconds |
| Expire smaller than refresh plus retry | A secondary can stop answering before its retry cycle finishes | Keep expire larger than refresh plus retry by a clear margin |
| MNAME points to a non-authoritative host | Secondaries pull from, or NOTIFY goes to, a server that is not the real primary | Set MNAME to the actual primary nameserver listed in the zone’s NS records |
| RNAME malformed or unescaped dot | The contact address is unreachable, and a literal dot in the local part is misread | Write the @ as the first dot, and escape any literal dot as backslash-dot |
| Negative TTL (minimum) set very high | Newly added records stay invisible to resolvers caching the prior NXDOMAIN | Keep the negative TTL modest, commonly 300 to 3,600 seconds, per RFC 2308 practice |
Every fix in the table is an edit the new operator makes after a domain is on its nameservers. None of it can repair a domain that arrived with registration or reputation problems baked in, which is the case for screening the name before purchase. The aged and expired domains listed on the SEO Domains marketplace are checked across their history before pricing, so the zone an operator rebuilds starts from a name without inherited baggage.
Reading the SOA record on an aged domain you just acquired
When an aged or expired domain transfers to a new owner and a new DNS host, its SOA record is rebuilt at the new host. The primary nameserver, the administrator contact, and the serial all reset to the new operator’s values. Reading the SOA right after a handover confirms the zone now answers from the intended host, and a stale or mismatched SOA is an early sign the transfer did not fully land.
What changes in the SOA when a domain moves
A domain acquisition changes who controls the zone, and the SOA record is where that control is recorded. The MNAME shifts to the new primary nameserver, the RNAME shifts to the new administrator’s contact, and the serial begins a fresh sequence under the new host’s convention. None of this carries over from the prior owner, because the new DNS host generates a clean record.
This is why the SOA is the first record worth reading after pointing an acquired domain at new nameservers. If the MNAME still names the seller’s nameserver, or the serial has not moved off a placeholder, the nameserver change has not propagated. The mechanics of that change are covered in the DNS and nameservers hub.
Sourcing the domain that starts on a clean record
A clean SOA record after a move is downstream of one decision: which domain was acquired in the first place. A domain with a sound registration history and a real prior use transfers cleanly and starts its new zone without inherited baggage. A junk drop bought on a raw metric can carry registration and reputation problems that surface long before any DNS detail matters.
This is where sourcing from a screened catalogue separates a clean handover from a troubled one. SEO Domains operates the curated marketplace where aged and expired domains are checked across their history and profile before they are listed, so the domain that lands on a new owner’s nameservers is vetted raw material. Browse the catalogue at the SEO Domains marketplace when sourcing a domain to rebuild on fresh DNS.
Does the SOA record matter for SEO?
The SOA record is not a direct ranking factor, and no search engine reads its serial or timers as a quality signal. Its SEO relevance is indirect: a broken SOA can take a zone offline, and a domain that resolves intermittently or not at all loses crawlability, availability, and ultimately ranking. Availability is the link between DNS health and SEO, not the SOA record’s contents.
The honest answer on SOA and rankings
Search engines rank pages on relevance, links, and content quality, not on DNS administrative fields. An optimised serial number or a perfectly tuned expire value earns no ranking benefit. Treating the SOA as an SEO lever is a category error.
The connection runs through uptime. If an expire value lets a zone go stale, or a wrong MNAME stops secondaries from syncing, the domain can stop resolving. A crawler that cannot resolve a domain cannot fetch its pages, and repeated unavailability degrades how a site is crawled and indexed. The SOA matters to SEO only in the sense that a healthy zone keeps the site reachable.
SOA record frequently asked questions
The five questions operators and domain buyers raise when reading an SOA record, answered against the RFCs that define the record and the zone-health practice built on them.
Q1Can a zone have more than one SOA record?
Exactly one. The SOA record is mandatory and unique per zone, placed at the zone apex. A zone file without an SOA record is rejected by the nameserver, and a second SOA record at the apex is a configuration error.
Q2Why does the RNAME email have no @ sign?
DNS syntax does not permit a raw @ in that field, so the first dot stands in for it. The address hostmaster.example.com decodes to [email protected]. A literal dot in the local part of the address is escaped with a backslash, so [email protected] is written as john\.doe.example.com.
Q3What is a good expire value for an SOA record?
RFC 1912 recommends an expire between 1,209,600 and 2,419,200 seconds, which is 2 to 4 weeks. The value must also stay larger than refresh plus retry so a secondary does not stop answering before its retry cycle completes. DNS health checkers flag expire values outside this range.
Q4Does the SOA serial number have to be a date?
No. Three conventions are valid: a plain sequential counter, the date-based YYYYMMDDnn format recommended by RFC 1912, and a Unix-epoch timestamp. The only hard rule is that the serial increases on every edit, because a secondary treats a higher serial as the signal to transfer the zone.
Q5What does the SOA record show after a domain is transferred?
After an aged or expired domain moves to a new owner and a new DNS host, the SOA names the new primary nameserver in MNAME, the new administrator in RNAME, and a serial under the new host’s convention. An SOA still naming the seller’s nameserver means the handover has not fully propagated. A dig SOA on the domain confirms the change landed.
Start an aged domain on a clean SOA: source a vetted domain
A healthy SOA record is the visible result of a clean domain handover, and a clean handover starts with the domain that was acquired. A vetted aged or expired domain with a sound registration history transfers without inherited problems, and its zone rebuilds on fresh DNS under the new owner. SEO Domains operates the curated marketplace that screens that raw material before it is listed.
Why the domain decides the handover
Every DNS detail in this guide sits downstream of one choice: which domain entered the picture. A domain with real prior use and a clean registration record moves to new nameservers cleanly, and its SOA reads correctly from the first lookup. A junk drop bought on an inflated metric can carry registration disputes, reputation flags, or a tangled history that no DNS edit resolves.
The asset is the clean domain, not a service
The product behind a sound SOA record is the domain itself, screened before purchase. It is not DNS hosting, not a managed service, and not a monitoring tool. A clean, vetted aged or expired domain is the raw material on which a healthy zone is built, and a junk domain is where the trouble starts.
How to source a domain that transfers clean
A domain that lands on a clean SOA survives a history and profile check before money changes hands. The signals that matter are documented across the authority and lifecycle hubs:
- A registration history with real prior use and no spam or abuse flags.
- A backlink profile that is editorially earned, read in the Domain Authority & Metrics hub.
- Clean transfer status with no registrar lock or dispute that stalls the nameserver change.
- A lifecycle position confirmed through the Expired Domain Fundamentals hub before purchase.
A domain that passes these is an asset on whatever it is built. A domain that fails them is a liability the first time its DNS is touched.
