Where the rules come from
DNS is forgiving in the short term. A zone with one dead nameserver, an MX that points at an alias or an SOA expire of one day will answer queries for months, then fail on the day a server goes down or a secondary loses contact with its primary. The checks encode the rules that prevent those failures: RFC 1034 for delegation, RFC 1912 for common operational mistakes, RFC 2181 for what MX records may point at and RFC 2308 for negative caching.
The SOA record is the clearest example. A typical one reads ns1.example.net. hostmaster.example.com. 2026101301 7200 3600 1209600 3600: primary server, contact mailbox, serial, then refresh, retry, expire and minimum in seconds. The validator passes a refresh between 1200 and 86400, a retry of at least 120 that is lower than the refresh, an expire between one and four weeks, and a minimum between 60 and 86400.
How the checks are carried out
Record lookups go through the public resolvers Cloudflare 1.1.1.1, Google 8.8.8.8 and Quad9 9.9.9.9. DS and DNSKEY are fetched over DNS-over-HTTPS because the standard resolver library cannot query those types. For the nameserver checks the tool resolves each NS hostname (up to eight), then sends an SOA query straight to that server's first public IPv4 address. The direct query fills the Responds, SOA serial and Time columns.
Network diversity is judged by counting the distinct IPv4 /24 networks the nameservers sit in, and a single /24 earns a warning. Only the first six MX hosts are resolved. Nothing is written to the domain: every query is a standard read of public data.
Reading pass, warning, error and info rows
Each row has a status icon, a title, a sentence explaining the finding and, where it helps, the record itself on a grey code line: the SPF string, the DMARC record, the MX list with priorities. An error is something that already breaks resolution, mail delivery or spoofing protection. A warning works today but removes a safety margin, such as nameservers with no IPv6 address or a DMARC policy of p=none.
Info rows mark optional features that are absent (no CAA record, no MTA-STS, no TLS-RPT) or a null MX declaring that the domain accepts no mail (RFC 7505). They appear in none of the three counters. Context changes severity as well: a missing SPF or DMARC record is an error when the domain has MX records and a warning when it has none.
Errors you are most likely to see
Failing reports tend to come down to the same few mistakes, most of them left over from a migration: a record copied from the old provider, a nameserver that was retired, a DNSSEC key rotated on one side only. Each has a specific fix at the DNS host or the registrar.
- One nameserver, or an NS hostname with no address record: add a second server or correct the hostname at the registrar.
- CNAME at the zone apex: replace it with A and AAAA records or your provider's ALIAS or flattening feature.
- Two SPF records: merge them into one v=spf1 record and confirm with SPF Checker.
- DS key tags that match no key: compare both sides with DS Record Lookup and DNSKEY Lookup, then remove the stale DS.
- MX host that does not resolve: correct the hostname or create its A record.
What a clean report does not prove
The validator reads configuration. It does not test service. It never connects to your mail servers, fetches the MTA-STS policy file over HTTPS, looks up DKIM selectors or verifies RRSIG signatures. The DNSSEC check stops at matching key tags between DS and DNSKEY. SPF is checked for presence, uniqueness and its all mechanism, not for the limit of ten DNS lookups.
A lookup that times out is treated like a record that is absent, so one slow reply can turn into a warning. Re-run before acting on a single unexpected finding. Nameserver queries use IPv4 only, so a server reachable solely over IPv6 shows as not responding. For a score and a ranked fix list built from the same data, open DNS Health Checker.