DNS Health Check
Enter a domain and get one deep, graded report on the health of its DNS: the records inventory (A/AAAA, MX, NS, SOA, TXT), DNSSEC signing and validation, CAA, DANE/TLSA, mail-adjacent SPF/DMARC, and nameserver hygiene. Each area is graded A+ to F with specific findings and fixes, and the most important problems are listed first.
Related guide: How to fix "DNS server not responding".
DNS health for example.com
DNS score: 95/100 · Grade A+
Overall 95/100 — improvements available in CAA, Nameserver Hygiene.
What to fix first
- medium Nameserver Hygiene: Spread authoritative DNS across two providers (or at least two diverse networks). Co-locating all nameservers under one operator removes the redundancy NS records are meant to provide.
- low CAA: Publish a CAA record naming only your CA (RFC 8659), e.g. example.com. IN CAA 0 issue "letsencrypt.org" — this blocks mis-issuance by any other authority. Add iodef for violation reports.
- low DANE / TLSA: DANE/TLSA is advanced and optional. If you want to pin certificates in DNS, it is most valuable for SMTP (mail server-to-server TLS) and only trustworthy when the zone is DNSSEC-signed (RFC 6698 / RFC 7672).
Records Inventory Apex resolves with 2 IPv4 / 2 IPv6 address(es) and 1 MX. A+
- A (IPv4): 2 IPv4 address record(s): 172.66.147.243, 104.20.23.154.
- AAAA (IPv6): 2 IPv6 address record(s) — the domain is IPv6-ready.
- SOA: Primary master elliott.ns.cloudflare.com, serial 2405749864.
- SOA timers: Refresh/retry/expire/minimum values are within healthy ranges (refresh 10000s, expire 7d).
- MX: 1 mail exchanger(s); lowest preference 0 is .
- Null MX: A null MX (RFC 7505) is published — the domain explicitly accepts no mail.
- TXT: 2 TXT record(s) at the apex (SPF and verification tokens live here).
DNSSEC DNSSEC is signed and validating. A+
- Signed & validating: A validating resolver set the AD (Authenticated Data) bit — DNSSEC is signed and the chain of trust validates to the root.
- DNSKEY: 4 DNSKEY record(s) (1 KSK / 3 ZSK).
- RRSIG: The zone's records carry RRSIG signatures.
- DS delegation: 1 DS record(s) published at the parent — the secure delegation is in place.
CAA No CAA record — any CA may issue. C
- CAA: No CAA record at the apex. Any publicly-trusted certificate authority may issue a certificate for this domain.
DANE / TLSA No DANE/TLSA records (optional). A+
- TLSA: No DANE/TLSA records found at the common service points (_443._tcp and _25._tcp). DANE is optional and only effective alongside DNSSEC.
Mail-adjacent DNS SPF present, DMARC present. A+
- SPF: SPF present and ends in -all (hard fail) — unauthorised senders are rejected.
- DMARC: DMARC present at p=reject — the strongest enforcement; spoofed mail is rejected.
Nameserver Hygiene 2 nameserver(s) published. A
- NS count: 2 authoritative nameservers published.
- NS diversity: All nameservers share one parent domain (cloudflare.com). If that provider has an outage, every nameserver goes down together.
- IP diversity: Nameserver IPs span 2 distinct /16 networks.
- SOA / NS agreement: The SOA primary master (elliott.ns.cloudflare.com) is one of the published NS records.
- Zone contact: SOA RNAME (admin contact): [email protected].
Catch the next DNS change automatically
DNS regressions are silent: a key rollover breaks the DNSSEC chain, a record gets edited, a second nameserver stops answering. Get an email the moment a record value for example.com changes - or run this audit on a schedule from your own code.
What is a DNS health check?
A DNS health check is a graded audit of everything in your Domain Name System configuration that decides whether a domain is reachable, resilient, and trusted. Instead of reading raw records and guessing whether they are correct, this tool queries your domain live, evaluates six areas against the relevant RFCs and operational best practice, grades each one A+ to F, and rolls them up into a single overall DNS-health grade with the highest-impact fixes listed first.
The overall grade is a weighted average of the area sub-grades. Any area that cannot be queried (for example a resolver timeout) is excluded from the average rather than scored as zero, so a single unreachable lookup never unfairly drags the grade down.
What each area measures, why it matters, and how to fix it
Records inventory - does the domain resolve correctly?
This is the foundation. The check reads the apex A (IPv4) and AAAA (IPv6) address records, the MX mail exchangers (including a sanity check that the lowest-preference host actually resolves to an address - an MX must not point to a CNAME, per RFC 2181), the SOA start-of-authority record and its refresh/retry/expire/minimum timers against RFC 1912 guidance, and the TXT records (flagging the classic mistake of publishing more than one SPF record, which is a PermError under RFC 7208). It also flags a CNAME at the apex, which RFC 1034 forbids because a CNAME cannot coexist with the SOA and NS records.
DNSSEC - can DNS answers be trusted?
DNSSEC (RFC 4033–4035) cryptographically signs DNS records so a resolver can detect tampering, spoofing, and cache poisoning. The check looks for DNSKEY records (is the zone signed?), RRSIG signatures (are the records actually signed?), and DS records at the parent (is the secure delegation in place?), then confirms the AD (Authenticated Data) bit set by a validating resolver, which proves the chain of trust validates up to the root. A zone that is signed but does not set the AD bit usually has a missing or stale DS record at the registrar - fix it there to complete the chain.
CAA - who may issue your certificates?
A CAA record (RFC 8659) lists exactly which certificate authorities are allowed to issue certificates for your domain. Without it, any publicly-trusted CA in the world may issue a certificate for you, which widens the blast radius of a CA compromise or a social-engineering attack. The check parses the issue and issuewild tags (which CAs are authorised, and whether wildcard issuance is restricted separately) and the iodef tag (where CAs report attempted policy violations).
DANE / TLSA - certificate pinning in DNS
DANE (RFC 6698) lets you pin a server's certificate or CA directly in DNS using TLSA records, removing reliance on the public CA system. It is most valuable for SMTP server-to-server TLS (RFC 7672) and is only trustworthy when the zone is DNSSEC-signed. The check looks for TLSA records at the common service points (_443._tcp for HTTPS and _25._tcp for SMTP) and reports the certificate-usage type. DANE is advanced and optional, so its absence is surfaced as information rather than penalised.
Mail-adjacent DNS - SPF and DMARC
Two DNS records do most of the work of stopping people spoofing your domain. SPF (RFC 7208) is a TXT record listing the servers allowed to send your mail; its all qualifier decides what happens to everyone else (-all rejects, ~all soft-fails). DMARC (RFC 7489) is a TXT record at _dmarc.<domain> that ties SPF and DKIM together and sets an enforcement policy (p=none monitors, p=quarantine sends to spam, p=reject blocks). This is a quick flag - for a full per-selector audit including DKIM, follow the link to the DKIM/SPF/DMARC lookup.
Nameserver hygiene - redundancy and diversity
Your NS records are what keep the domain resolving. The check confirms there are at least two (RFC 1034 and most registries require it), then looks at diversity: are the nameservers under more than one parent domain, and do their IPs span more than one /16 network? Co-locating every nameserver under one provider or one network removes the redundancy NS records are meant to provide. It also checks whether the SOA primary master appears in the NS set (or is an intentional hidden primary) and surfaces the zone's administrative contact.
How is the overall DNS grade calculated?
Each area is scored 0–100 and converted to a letter (A+ ≥ 95, A ≥ 90, B ≥ 80, C ≥ 70, D ≥ 60, otherwise F). The overall score is a weighted average that emphasises the areas with the broadest impact - the records inventory and DNSSEC carry the most weight, followed by nameserver hygiene and mail-adjacent DNS, then CAA and DANE. Because unreachable areas are excluded and the remaining weights are renormalised, the overall grade always reflects only what was actually measured.
How does this tool query DNS, and is it accurate?
The check uses the net_dns2 resolver library to send typed queries to the well-known public recursive resolvers (Google 8.8.8.8 and Cloudflare 1.1.1.1), which gives precise, structured parsing of every record type - including the security records (DNSKEY, DS, RRSIG, CAA, TLSA) that many environments cannot read natively. To confirm DNSSEC actually validates (not just that it is signed), it additionally reads the AD bit over DNS-over-HTTPS from a validating resolver. Results are cached for about 15 minutes, so a freshly-changed record may take a few minutes to appear - use the DNS Propagation Checker to watch a change roll out worldwide.
How often should I run a DNS health check?
Run it whenever you change nameservers, migrate DNS providers, enable DNSSEC, rotate keys, or update mail records - and on a recurring schedule (monthly is reasonable) to catch silent regressions such as a DNSSEC chain that broke after a key rollover, a DMARC policy that slipped back to p=none, or a second nameserver that quietly stopped answering. Each area links to a focused tool so you can drill into any finding in depth.
DNS health check FAQ
Is this DNS health check free, and is my domain stored?
Yes, it is free and needs no sign-up. Every query runs live against public DNS at the moment you submit the domain. We do not store the domains you check server-side; results are cached only briefly (about 15 minutes) so reloading or sharing a report link is fast and does not re-run every lookup.
What is the difference between DNSSEC being "signed" and "validating"?
"Signed" means your zone publishes DNSKEY and RRSIG records, so the data carries cryptographic signatures. "Validating" means a resolver can follow the chain of trust from the root down to your zone and confirm those signatures, which it signals with the AD (Authenticated Data) bit. A zone can be signed but fail to validate if the DS record at your registrar is missing or wrong - in that case the protection does not actually take effect until you fix the DS delegation. This tool checks for both.
Why does a missing CAA or DANE record only lower my grade a little (or not at all)?
Both are best-practice hardening rather than baseline requirements. A missing CAA record is a real gap - any CA could issue for your domain - so it costs a small amount and earns a low-priority fix. DANE/TLSA is advanced, rare, and only effective alongside DNSSEC, so its absence is reported as information and does not reduce your score at all. The weighting keeps the grade focused on the records that actually keep your domain resolving and trusted.
Why do you recommend more than one nameserver, on different networks?
NS records exist for redundancy: if one nameserver is unreachable, resolvers try another. RFC 1034 and most registries require at least two. But two nameservers under the same provider - or in the same network - fail together during an outage or a DDoS attack, which defeats the purpose. Spreading authoritative DNS across two providers or two diverse networks (different parent domains and different IP ranges) is what actually keeps your domain resolving when something breaks.
My domain does not send email. Does it still need SPF and DMARC?
Yes. A domain that sends no mail is still a spoofing target. The strongest stance for a non-mail domain is a null MX (RFC 7505), an SPF record of v=spf1 -all, and a DMARC policy of p=reject. Together these tell the world that no legitimate mail ever comes from the domain, which stops attackers from impersonating it.
Why is one area shown as "could not check" with an N/A grade?
An area degrades to "could not check" when its query could not complete within the time budget - for example a resolver timeout or a record type the upstream refused. To keep the overall grade fair, any area that could not run is excluded from the weighted average rather than counted as zero, so a single failed lookup never unfairly lowers your grade.
Does a perfect DNS grade mean my whole domain is secure?
No. This tool grades the DNS layer specifically - records, DNSSEC, CAA, DANE, mail DNS, and nameserver resilience. It does not test your TLS certificate, HTTP security headers, IP reputation, or application code. For a full-stack view that adds those, run the Domain Health Report. Treat an A+ here as "the DNS fundamentals are correct," then continue up the stack.
How this tool works: This tool runs in your browser and on our server in real time. Depending on the tool, results are computed directly from the input you provide or retrieved from live, authoritative data sources at the moment you run a lookup. We do not sell your data, and your lookups are kept private — any history shown here is stored only on your device.