If one nameserver goes down, does your domain go with it?
Enter a domain. This reads your nameservers, zone record, addresses, mail routing and certificate rules the way a resolver would, and shows you what it found. No signup, no email required.
Every test, explained
Six record types decide whether your domain works at all. Here is what each one does, and what this tool looks at.
Nameservers — who is allowed to answer
Your nameservers are the servers that answer questions about your domain. Everything else depends on them. If they stop answering, your website and your email stop together, and no amount of working hosting will save you.
So this tool counts them first. Then it resolves each one, because a nameserver listed in your delegation but missing an address record is worse than useless — resolvers still try it, wait, and time out before moving on.
Finally it looks at where they sit. Four nameservers are no better than one if all four share a rack. The tool compares their address ranges and tells you whether the redundancy is real or decorative.
SOA — the record the zone keeps about itself
Every zone carries one SOA record. It names the primary nameserver and sets the timers that keep your secondary servers in step with it.
Those timers matter more than they look. expire decides how long a secondary keeps serving your zone when it cannot reach the primary. Set it too short and a long outage takes your domain down entirely, even though the secondary is running and has a perfectly good copy.
The last field, minimum, controls how long resolvers remember that a name does not exist. Set it high and a typo you fix in seconds keeps failing for a day. This tool checks all of them against ranges that actually matter, not against a textbook default.
A, AAAA and www — where the domain points
The tool resolves both the bare domain and www. Then it compares them, because the common failure is not that both are missing. It is that one works and the other does not.
That failure is invisible from your own analytics. Visitors who hit the broken form never arrive, so they never appear in your traffic. They just see an error and assume the business is gone.
It also checks the addresses themselves. A private IP published in public DNS makes the site unreachable from outside, and it tells anyone looking how your internal network is arranged. IPv6 gets the same treatment: publishing it on one hostname and not the other causes failures that only appear on mobile networks.
MX — where your mail is delivered
MX records name the servers that accept mail for your domain. This tool reads them, resolves every hostname, and checks that none of them point at an IP address or an alias instead of a real host.
It also spots a null MX, which is the correct and deliberate way to say "this domain accepts no mail". A domain that receives no mail is a different situation from a domain that receives mail badly, and the report says which one you have.
Worth knowing: MX records govern incoming mail only. Whether someone can forge mail from your domain is a separate question, answered by the Email Domain Health Check.
TXT — the records everything else piggybacks on
TXT records hold domain verification tokens for every service you have ever connected. They accumulate. Nobody removes them, because nobody remembers which service each one belongs to.
That matters for one specific reason. Once the whole TXT set outgrows a standard UDP response, resolvers have to ask again over TCP. Most can. Some corporate firewalls and older appliances block DNS over TCP outright, and for those the answer simply never arrives.
The effect is silent and partial: SPF and domain verification break for a subset of senders and work perfectly for everyone else. So the tool measures the total size and lists the non-policy records, so you can see what is safe to delete.
CAA — who may issue certificates for you
CAA records name which certificate authorities are allowed to issue for your domain. Every compliant CA reads them before issuing, and refuses if it is not on the list.
That makes them a genuine hardening measure. It also makes them a quiet way to break your own site. If the records exist but authorise nobody — or carry a critical flag on a tag the CA does not understand — then every CA refuses, including the one you already use.
Nothing happens immediately. Your current certificate keeps working until it expires. Then renewal fails, automated renewal retries and gives up quietly, and the first sign is a browser warning on your own site roughly ninety days later.
What usually goes wrong, and how it gets fixed
Most domains fail on the same handful of things. Here they are, with the fix.
One nameserver, or several in the same place
This is the finding worth acting on first. One nameserver means one failure takes the entire domain down. Several in the same network block means the same thing, dressed up as redundancy.
The fix is usually free. Most registrars and DNS providers include a second and third nameserver on separate infrastructure at no extra cost — you simply have to switch them on. If you run your own, add a secondary somewhere else entirely. Different provider, different network, different city.
Then check it worked. Two nameservers from the same provider often share a range, so the delegation looks improved and is not.
www resolves and the bare domain does not, or the reverse
Both forms have to work. People type them interchangeably, older links use www, and newer ones usually do not.
Point the missing one at the same place as the working one. For www, that is normally a CNAME:
www.example.com. 3600 IN CNAME example.com.For the bare domain, use an A record, or your provider's ALIAS or ANAME feature if you need it to follow a hostname. Then set up a redirect so one form is canonical — but get them both resolving first. A redirect cannot run on a name that does not resolve.
A private IP address in public DNS
Addresses in ranges like 10.x, 172.16.x and 192.168.x only exist inside a private network. Published publicly, they point the whole internet at something it cannot reach.
This almost always comes from an internal zone that was copied to the public one, or a split-horizon setup where the two halves drifted. Find the record and point it at the public address instead.
Do it promptly for a second reason. The record also publishes your internal addressing scheme to anyone who looks, which is free reconnaissance you did not need to give away.
CAA records that authorise nobody
A CAA set with no usable issue property tells every certificate authority to refuse. So does issue ";", which is the explicit way to say it.
Add the CA you actually use. For Let's Encrypt:
example.com. 3600 IN CAA 0 issue "letsencrypt.org"Add one line per authority, and remember to include any CA your CDN or host issues on your behalf. Cloudflare, AWS and most managed platforms document which value they need. Miss one and their renewals fail while yours succeed.
The TTL is too long to move anything
A TTL of a day means resolvers worldwide keep serving your old address for a day after you change it. You cannot migrate hosting, fail over to a standby or undo a mistake inside a working day, no matter how fast you edit the record.
Lower it before you need it, not when. Drop the apex record to 300 seconds at least twenty-four hours before any planned change, make the change, confirm it, then put the TTL back up.
The order matters. Lowering the TTL at the same time as making the change achieves nothing, because the old long TTL is already cached.
A CNAME at the zone apex
A CNAME cannot share a name with any other record, and the apex has to carry SOA and NS. So an apex CNAME is invalid, and what happens next depends entirely on your provider.
Some ignore the CNAME. Some ignore everything else — which quietly removes your MX records and stops your mail. That last one is the reason this finding is rated the way it is.
Use your provider's ALIAS, ANAME or CNAME flattening feature instead. All three do the same job properly: they resolve the target and serve real address records at the apex.
TXT records too big for a UDP response
Every verification token you have ever added is still there. Together they eventually outgrow a standard DNS response, and resolvers get pushed onto TCP to read them.
Start by deleting tokens for services you no longer use. Most verification records are only needed once, at setup, and can be removed afterwards — check the provider's documentation before you delete, because a few do re-verify.
While you are in there, look at your SPF record too. A long include chain is the other common cause of an oversized set, and it has a separate ten-lookup limit that breaks SPF entirely. The Email Domain Health Check counts that for you.
Found something broken?
Send me the result. I'll tell you what it takes to fix it, and whether it's worth paying anyone to do — including me.
Prefer to talk? Book a free call ↗ · Or hire me on Upwork ↗ · Typical reply within one business day.
Questions
How is this different from the Email Domain Health Check?
I entered a subdomain and it checked the main domain. Why?
blog.example.com for nameservers would report on example.com anyway, so the tool says so plainly instead of pretending otherwise.