3,932 Australian domains analysed. Most fail basic email authentication. [2026 Report]

SOA Record Lookup

Check the Start of Authority record — serial, refresh, retry, expiry.

Perform SOA Lookup

What is a SOA record?

The SOA record (Start of Authority) is the administrative record at the apex of every DNS zone. There is exactly one SOA per zone, and it is mandatory — a zone without an SOA is invalid. The SOA encodes the primary nameserver for the zone, the zone administrator's contact email, and six timing parameters that govern how secondary nameservers synchronise the zone from the primary.

The six fields:
Primary NS (mname): the hostname of the authoritative master nameserver. This is where zone changes are first made.
Admin email (rname): the zone administrator's email address, with the @ replaced by a . (so hostmaster@example.com becomes hostmaster.example.com). Rarely used in practice but technically required.
Serial number: a version number for the zone. Secondary nameservers compare their stored serial against the primary's; if the primary's is higher, they initiate a zone transfer. The convention is YYYYMMDDNN (date + sequence number), though some providers use Unix timestamps.
Refresh: how often (in seconds) secondaries poll the primary for updates. 3600 (one hour) is typical.
Retry: how long secondaries wait before retrying a failed refresh. Usually 600–1800 seconds.
Expire: how long secondaries keep serving a zone after losing contact with the primary. 604800 (seven days) is standard — after expiry, secondaries stop answering for the zone entirely.
Minimum TTL: the default TTL for negative responses (NXDOMAIN caching). Historically also the default positive TTL, but modern DNS decouples these.

How to read the results

The result panel breaks down the six fields. The most practically useful is the Serial number — it tells you when the zone was last changed. A serial of 2026042401 means "updated on 24 April 2026, first update of the day". If you're troubleshooting a DNS change that "didn't take", compare the serial across nameservers: if the primary's serial is higher than a secondary's, the secondary is out of sync and still serving old data.

Refresh, Retry, and Expire are relevant only to zone transfer reliability between primary and secondary nameservers — most users with hosted DNS never need to touch them. Minimum TTL affects how long negative answers (e.g. "this record doesn't exist") are cached; lowering it causes newly-created records to be discoverable faster but increases query load on the authoritative servers.

Primary NS should be one of the NS records for the zone. If it isn't, you have a configuration inconsistency that DNS health checkers will flag.

Common issues

  • Serial number not incrementing. If the SOA serial doesn't change when the zone changes, secondary nameservers won't detect the update and will keep serving old data. Most managed DNS providers handle serial incrementing automatically; self-hosted BIND installations require the admin to bump the serial manually (or use a tool like named-checkzone).
  • Serial format invalid or out of order. Some tools and DNS health checkers strictly validate the YYYYMMDDNN convention. Serials that go backwards (e.g. after a restore from backup) confuse secondaries — they treat the lower serial as "no new data" and keep serving the old zone. Fix by advancing the serial past the highest value the secondaries have ever seen.
  • Primary NS not in the NS record set. The SOA mname field should match one of the NS records. A mismatch is technically legal but often flagged as a warning by tools like Zonemaster, IntoDNS, and MXToolbox. It can also confuse dynamic update tooling that expects the primary to be reachable at the mname address.
  • Expire shorter than refresh. If the expire is shorter than the refresh interval, secondaries can expire a zone they just refreshed. Keep expire significantly longer than refresh — a factor of ~100 is reasonable (e.g. refresh 3600, expire 604800).
  • Admin email points to a non-existent mailbox. The rname field is sometimes used by registries and reputation services for automated contact. A non-existent mailbox won't cause resolution failures, but it may delay responses to important notices — transfer requests, abuse reports, registry violations. Point it at a monitored mailbox (usually hostmaster@example.com).