What "DNS propagation" actually is

There is no propagation phase in DNS — no wave of updates travelling around the internet. What happens instead is this: every resolver (your ISP's, Google's, Cloudflare's) keeps its own cache. When a resolver answers a query for example.com, it first checks its cache; if the cached entry hasn't expired yet, it serves that old copy without asking anyone. The record's TTL (time-to-live) is how long caches are allowed to keep it. So after you change a record, each resolver keeps serving the old value until its own cached copy expires — and because every resolver cached at a different moment, they all expire at different moments. "Waiting for propagation" is really waiting for caches to expire, one resolver at a time.

Why the resolvers show different answers and TTLs

• Different values — a resolver whose cache still holds the pre-change record returns the old value; one whose cache expired re-queries the authoritative servers and returns the new one. This disagreement is exactly what this tool exists to show, and it always resolves on its own as caches expire.
• Different TTLs for the same value — the TTL you see is the remaining time left in that resolver's cache, not the TTL you configured. Two resolvers serving the identical value will show different remaining TTLs because they fetched it at different times. The highest remaining TTL across resolvers is your worst-case wait for a stale value to clear.
• Different order — when a name has several A records (load balancing), resolvers rotate the order (round-robin). Order is not meaningful; that's why this tool compares record sets, not lists.
• CNAME handling — some resolvers flatten a CNAME chain and return only the final address, others include the chain. For CNAME comparisons this tool looks at the direct alias (the first hop) so resolvers are compared on the same fact.
• NXDOMAIN on one side only — if some resolvers say "name does not exist" while others return records, either a zone is being delegated (new nameservers at the registrar) or a stale cache is serving records for a name that no longer exists. Both clear within the relevant TTLs.

How long should I wait?

The honest answer: up to the TTL of the old record, as seen by the slowest resolver. After a comparison, look at the TTL column in each matrix — the largest remaining TTL is the longest any resolver can keep serving a stale copy. If the old record had a 3600s (1 hour) TTL, expect everything to agree within about an hour; with a 30-day TTL (the default at many registrars for NS records), it can genuinely take days. The "48 hours" folklore comes from TLD delegation: when the nameservers of the zone itself change, the parent domain's cache of the NS set (often 2–3 days) has to expire first — that is the one case where waiting really can take a long time.

Making your next change clear faster

The standard trick: lower the TTL before you change anything. A day or two ahead, reduce the record's TTL to something small (60–300s). Once caches have refetched at the low TTL, make your change — every resolver will pick up the new value within a few minutes instead of hours. Afterwards you can restore a normal TTL. Most DNS hosts let you set TTL per record; if yours doesn't, the zone default applies.

Verifying after you change DNS

A workflow that catches problems early: (1) confirm the change is actually published — check your DNS host's console and, if you can, query an authoritative nameserver directly (dig @ns1.yourhost.com example.com A); (2) run this comparison with the expected value filled in and watch resolvers flip from stale to match; (3) keep the auto re-check on until every resolver shows match; (4) if your own computer still shows the old value after all public resolvers match, your local resolver or OS cache is holding it — flush it (ipconfig /flushdns on Windows, sudo dscacheutil -flushcache on macOS) or wait out its TTL. For mail changes, re-check the MX and TXT (SPF/DMARC/DKIM) types specifically — those are the records that keep breaking delivery mid-migration.