Why do different DNS checkers show different results?

Because they query different resolvers, whose caches expire at different times. During a change, disagreement between resolvers is expected until the old TTL has elapsed everywhere.

It is not required, and adoption is uneven. It signs responses so a resolver can detect tampering; the trade-off is operational complexity, since a misconfigured signature makes a domain fail to resolve entirely.

What TTL should I use?

Long enough to benefit from caching, short enough to allow a change. Many operators lower the TTL a day before a planned migration and raise it again afterwards.

Tools

DNS checker

A DNS checker queries the public Domain Name System for a domain and reports what it finds: the addresses it resolves to, the mail servers it declares, the text records carrying email authentication, the authoritative nameservers, and the security-related records. It answers two questions — does this domain resolve, and is what it declares internally consistent — and the second is where most intermittent failures come from.

What it reads

A and AAAA: the IPv4 and IPv6 addresses. Absence of AAAA is not a defect, but is increasingly visible on mobile networks.

MX: where mail is delivered. Absent records mean mail bounces regardless of the website.

TXT: including SPF and the verification records services require.

NS: the authoritative nameservers, compared against what the domain delegates.

CAA: which certificate authorities may issue for the domain.

DNSSEC: whether responses are cryptographically signed.

What a clean result looks like

Resolution to addresses that are actually serving, with sensible TTLs.

Nameservers agreeing with the delegation, and agreeing with each other.

Exactly one SPF record, if email is sent from the domain.

MX records resolving to hosts that themselves resolve.

The inconsistencies that cause intermittent failure

Nameserver mismatch: the registrar delegates to one provider while the records live at another. The site works or fails depending on which resolver answers — the hardest kind of outage to reproduce.

Two SPF records, which is invalid and makes evaluation fail permanently.

An A record pointing at a decommissioned server, held alive by a long TTL.

MX records naming hostnames that no longer resolve.

How the manual equivalent works

`dig example.com A +short`, `dig example.com MX +short`, `dig example.com TXT +short`, `dig example.com NS`.

Query several public resolvers — `dig @1.1.1.1`, `dig @8.8.8.8` — to distinguish a real inconsistency from a cache holding an old value.

Remember TTL: a record changed an hour ago may still be served from caches until it expires.

What VeriFixScan uses

`dns.resolution`, `dns.ipv6`, `dns.nameservers`, `dns.ttl`, `dns.caa`, `dns.dnssec`, `dns.propagation`, `dns.conflicts` and `dns.nameserver_consistency` cover the records and their coherence.

`email.mx.present`, `email.mx.resolution` and `email.mx.redundancy` cover the mail side, and the SPF, DKIM and DMARC checks read the TXT records that carry email authentication.

`domain.expiry` and `domain.registrar` report the registration itself, which is the failure nobody notices until the domain stops resolving.

Reading a result while a change is in flight

During a migration a DNS check reports a moving target, and the usual mistake is to treat disagreement as a defect. It is not: caches expire independently, so two resolvers returning different values is the expected state until the old TTL has elapsed.

What is worth reacting to is disagreement between the authoritative nameservers themselves. Those should be identical at all times, and a difference between them is a real misconfiguration rather than a cache.

Equally worth reacting to: a delegation that points at nameservers which do not have the records. That produces a site that resolves for some visitors and not others, indefinitely, and no amount of waiting fixes it.

The practical sequence is to lower the TTL a day ahead, make the change, then verify against the authoritative nameservers directly — `dig @ns1.provider.net example.com A` — rather than against a public resolver whose answer may be an hour old.

And one detail that catches people: a record removed from the zone is still served by caches for its full TTL. Deleting is not faster than changing.

Frequently asked questions

Why do different DNS checkers show different results?: Because they query different resolvers, whose caches expire at different times. During a change, disagreement between resolvers is expected until the old TTL has elapsed everywhere.
Is DNSSEC necessary?: It is not required, and adoption is uneven. It signs responses so a resolver can detect tampering; the trade-off is operational complexity, since a misconfigured signature makes a domain fail to resolve entirely.
What TTL should I use?: Long enough to benefit from caching, short enough to allow a change. Many operators lower the TTL a day before a planned migration and raise it again afterwards.

Sources

VeriFixScan crawls a site and applies its checks to every page it reaches, keeping the evidence behind each finding. Scanning one website is free.

Scan a website