How it works
What each check does, which servers it asks, and how results are classified.
Principles
- Every finding comes from a real response. Nothing is inferred from a domain's name, popularity or third-party databases.
- Observations and interpretations are kept apart. Each finding lists what was observed, then separately what it probably means.
- No answer is not a negative answer. A timeout is reported as inconclusive, never as proof that a record or server is missing.
- Everything is reproducible. Each report lists every query sent, the server that answered and its response. With Pro, each one also comes with an equivalent
digcommand.
Which servers are queried
Recursive lookups use public resolvers: Cloudflare (1.1.1.1) by default, with Google Public DNS (8.8.8.8) and Quad9 (9.9.9.9) as fallbacks or alternatives. If the primary resolver doesn't respond, a query is retried once and then sent to the next resolver.
Delegation and DNSSEC checks also query servers directly with recursion disabled: the parent zone's servers for the delegation and DS records, and each of your authoritative nameservers. Direct queries are sent over IPv4 and only to public addresses—a nameserver that resolves to a private or reserved address is reported, not queried.
Registry status comes from the registry's own RDAP service, located through IANA's bootstrap registry. That is the authoritative source for registration status; DNS alone cannot show whether a domain is registered, expired or on hold.
How results are classified
| Status | Meaning |
|---|---|
| Fail | A problem was observed directly in the responses. |
| Warning | Works now, but is risky, unusual or worth reviewing. |
| Inconclusive | Not enough evidence — for example a server did not respond. |
| Pass | The check succeeded based on the observed responses. |
| Info | A neutral observation; nothing to fix. |
A missing record isn't automatically a problem: whether something is wrong depends on what you intended. An unsigned domain, for example, is reported as information rather than a failure.
DNSSEC validation
Whether DNSSEC validates is decided by real validating resolvers (Cloudflare and Google), not by this site. When a resolver returns SERVFAIL, the query is repeated with checking disabled: if the data then comes back, the failure is attributed to DNSSEC. Extended DNS Error codes returned by the resolvers are shown as reported.
To explain the result, the tool fetches DS records from the parent and DNSKEY records from each nameserver, recomputes each DS digest from the matching key, checks which keys sign the key set, and checks signature validity periods. Cryptographic verification of individual signatures is left to the validating resolvers.
SSL checks
The SSL Certificate Checker resolves the hostname itself, then connects by IP address to port 443 on up to 3 public IPv4 addresses and 2 public IPv6 addresses, sending the hostname via SNI as a browser would. Certificates are captured even when invalid, so problems can be explained, and trust is judged against the Mozilla root store. A further connection offers only TLS 1.0, and another only TLS 1.1, to see whether the server still accepts them.
For the redirect check, a plain HTTP request is sent to port 80 and redirects are followed one hop at a time, up to 5. Each hop is checked before it is followed: only http and https on ports 80 and 443, and only hosts that resolve to public addresses. Requests ask for headers only; page content is not downloaded.
Email authentication
SPF records are evaluated the way a receiving mail server would: every include and redirect is followed and DNS lookups are counted against the limits in RFC 7208 (10 lookups, 2 empty "void" lookups). The walk is bounded in depth and size so a malicious record cannot make this service send unlimited queries. DMARC records are checked at _dmarc on the domain, falling back to the parent zone's policy for subdomains.
DKIM keys can only be found if you know the selector. When none is given, a short list of commonly used selectors is tried, and not finding a key there is reported as "unknown", never as "missing". These checks describe how receivers will read your records; they cannot predict whether a particular message lands in the inbox.
Propagation comparison
The same question is sent to 8 public resolvers from different operators (Cloudflare, Google Public DNS, Quad9, OpenDNS, AdGuard DNS (unfiltered), Control D (unfiltered), Yandex DNS, AliDNS), each queried once without retries, and compared with the answer from the domain's authoritative nameservers. The TTL each resolver returns shows how long it will keep its cached copy.
Most of these resolvers are anycast networks, so the answer comes from the instance nearest this service. The comparison is a sample from one location, not a measurement of worldwide propagation.
Limits
- Results reflect one moment, from one location. Caches elsewhere may hold different data.
- A handful of resolvers is a sample, not a view of "global propagation".
- Each check has a time budget of about 14 seconds. Queries that would exceed it are marked as not sent.
- SSL checks on other ports use implicit TLS only. Services that upgrade with STARTTLS (SMTP on 25 or 587, IMAP on 143) are not supported, and the redirect and HSTS checks run on port 443 only.
- The tools are read-only. They never change DNS records or registrar settings.
Caching and rate limits
Complete reports are cached for 60 seconds so that repeated checks are quick; use Re-run to bypass the cache. Reports containing timeouts or network errors are never cached. To keep the service available, each visitor can run a limited number of checks per minute.