Run a lookup
How it works
Paste the domains
SOA exists once per zone, on the zone apex. Subdomains normally inherit it rather than carrying their own.
Query SOA over DoH
One lookup per domain, run from your browser against public resolvers.
Read the fields
Primary nameserver, hostmaster address, serial, and the four timers — each shown separately rather than as one unreadable string.
Use the serial
Compare it before and after a change to confirm the zone was actually rewritten, not just edited in a panel.
The field that catches people out
Most of the SOA record is administrative and you will never touch it. The one that has real operational consequences is the last field, the minimum TTL, because modern resolvers use it for negative caching — it controls how long a resolver remembers that a record does not exist.
This is the mechanism behind the single most frustrating DNS experience there is. You look up a record before creating it. It does not exist, so the resolver caches that absence for the duration of the minimum TTL. You then create the record correctly, look it up again, and still see nothing. Nothing is broken and no amount of re-checking will help — you are being served a cached negative answer, and the only fix is to wait it out. If that minimum is set to a day, you wait a day.
The practical lesson is to stop querying a record before you have created it. If you have already done it, this lookup tells you exactly how long the wait is rather than leaving you to guess.
The serial is your change receipt
Every time a zone is modified, the serial should increase. That makes it the cheapest possible confirmation that a change actually landed: note the serial, make the edit, look it up again. If the number has not moved, the change did not reach the authoritative zone — which usually means you edited a panel at a provider that is no longer authoritative for the domain. On a fleet assembled across several registrars, that happens more than anyone would like to admit.
What the timers actually control
Refresh, retry and expire govern the relationship between a primary nameserver and its secondaries — how often they check for changes, how quickly they retry a failure, and how long they keep answering if the primary stays unreachable. On a managed DNS provider like Cloudflare or Route 53 these are handled internally and the published values are largely decorative. On self-hosted DNS they matter, and an expire value shorter than a plausible outage means your domain stops resolving entirely while you are trying to fix the primary.
Frequently asked questions
What is the SOA minimum TTL used for?
Negative caching. It sets how long resolvers remember that a name does not exist. It is the reason a record you just created still appears missing — you queried it too early, the absence got cached, and you now have to wait out the timer.
Why has my zone serial not changed after an edit?
Either the change was not saved, or the provider you edited is not authoritative for the domain. Check which nameservers actually answer with the NS checker before assuming the record is broken.
What format should the serial be in?
Convention is YYYYMMDDnn, so a zone changed twice on 29 August 2026 would read 2026082902. Many managed providers ignore this and use an incrementing integer or a timestamp instead, which is perfectly valid — the only hard requirement is that the number increases.
Why is the hostmaster address written with a dot?
Because the @ is not permitted in that field, the first dot stands in for it. So hostmaster.example.com means hostmaster@example.com. If the local part itself contains a dot it will be escaped with a backslash.
Do I need to change SOA timers on managed DNS?
No. Cloudflare, Route 53 and similar providers replicate internally and do not use these values for anything meaningful. Leave them alone. They matter only if you run your own primary and secondary nameservers.
Can a subdomain have its own SOA record?
Only if it has been delegated as a separate zone with its own NS records. Otherwise it is part of the parent zone and inherits the parent's SOA. Seeing an SOA appear on a subdomain is a reliable sign that a delegation exists, which is worth knowing before you go looking for records in the wrong place.
Last reviewed
What to run next
The checks that most often follow this one.
More in this category
Guides that go deeper
When the tools tell you something is wrong
The diagnostics here are free and always will be. When the fix is bigger than a DNS record, this is the work I do.
Deliverability rescue
Mail landing in spam, replies gone quiet, or a domain suddenly blocked. I find the actual cause rather than guessing, and fix it.
- Authentication and alignment failures
- Blocklist delistings and reputation repair
- Gateway and filter-level blocks
- A written report on what broke and why
Email & sending infrastructure
Sending domains, inboxes, authentication and warmup, built to survive volume instead of burning down in a month.
- Domain and inbox fleets at any scale
- SPF, DKIM, DMARC and tracking domains
- Google Workspace and Microsoft 365 inboxes
- Handover documentation you actually own
Domain, DNS & migration
Changing registrar, mail provider or host without a day of downtime or a week of mail silently failing.
- Registrar and nameserver moves
- Workspace and Microsoft 365 migrations
- MX, SSL and subdomain cutover
- Staged rollout with rollback at every step
Monitoring & retainer
Infrastructure drifts. Records get edited, certificates expire, domains get listed. Ongoing eyes on the fleet.
- Scheduled checks across every domain
- Alerts before your clients notice
- Monthly reporting
- Priority response when something breaks
Start with a call
Bring a domain and the symptom. I will tell you what is actually wrong and whether you need me at all — plenty of people leave that call able to fix it themselves.
Thirty minutes, no pitch
We will run the checks together on your actual domains, and you will leave knowing what is broken, what it takes to fix, and what it should cost. If that is a job you can do in-house, I will say so.