What a propagation checker can and cannot measure
The idea behind this tool is simple enough to state in one line: ask more than one resolver the same question and compare the answers. A resolver is a cache, and a cache that received an answer one second before your change will keep serving it until its copy expires. Two caches that were warmed at different moments can therefore hold different answers at the same moment, and both are behaving correctly.
What no page can do is query the hundreds of thousands of resolvers that actually exist. The honest version of this check is to compare a small number of independent ones, state which ones were used, and show the timestamp of the comparison — which is what the report above does.
Why the report names its resolvers
Resolvers are not interchangeable opinions. A resolver belonging to a large content network may answer from its own edge, a resolver run by an internet provider may have a regional cache, and a public resolver may deliberately strip certain records for privacy. Naming them turns the result into evidence you can check instead of a verdict you have to trust.
Six record types are compared, because a change rarely affects only one. An A and AAAA change covers the addresses a website resolves to. MX and TXT cover mail routing and policy, which is where a mailbox change is usually felt first. NS covers delegate changes, which matter for WHOIS-adjacent questions. CAA covers which certificate authorities are permitted, which is a security control rather than a routing one.
Reading the agreement column
Identical means both resolvers returned the same set of record data. Differs means they returned different data while both answered successfully, and during a change that is the expected state rather than a fault. One resolver failed means the query reached one resolver and not the other, which points at the resolver rather than at your zone. Empty answer means the type is simply not published.
Record ordering is deliberately ignored when deciding agreement, because ordering carries no meaning for these types. TTL differences are also ignored for the same reason: TTLs count down as caches age, so two correct answers will rarely carry the same remaining lifetime.
The TTL is the number that decides your wait
The single most useful value in the report is the shortest TTL across all types. It is the longest time any correct cache could still be holding the previous answer after your change was published. Everything else in the comparison is context for that number.
A common mistake is lowering the TTL at the same moment as the record change, hoping to speed things up. It does not work in that direction. A copy that was already cached keeps its original lifetime, so lowering the TTL after a change shortens only copies created afterwards. The way to control the window is to lower the TTL before making the change and wait out the old value once.
Comparing with the run before
The second time you open this page for the same name, the record counts from the previous run are read back from this browser and any difference is reported. That turns a single snapshot into a simple observation about whether the change is landing.
The comparison is stored locally and never sent anywhere. It also only works on the same device and browser, which is a real limitation rather than a detail: open the page on a phone and there is nothing to compare against.
What this page does not tell you
It does not prove that a change is visible worldwide, and it does not tell you which resolver your visitors use. Those are different questions with different tools: the first needs distributed probes, and the second needs your own analytics.
It does not validate the records themselves. A record can be identical at both resolvers and still be wrong — an address that no longer serves the site, a mail route pointing at a decommissioned host, a certificate authority list that omits the one your provider uses. Agreement between caches says nothing about correctness. For the records themselves, DNS lookup shows the raw answers and the DNS record reference explains what each type is for.
It does not test whether mail actually arrives, whether a server accepts connections, or whether a certificate is valid. Those live on the email deliverability test and the SSL and certificate authority check. If a name resolves correctly but nothing loads, the network guide puts these checks in a sensible order.