DNS Propagation Checker

DNS propagation is the period between when you publish a new DNS record and when every resolver on the internet stops serving the old value. It is not a single event but a distributed cache-expiry process: each resolver caches the answer it received for the duration of the record's TTL (Time to Live), then re-fetches the current value when that timer expires. If the previous record had a TTL of 3,600 seconds, every resolver that cached it holds the old answer for up to an hour after you changed it — longer if the resolver overrides short TTLs with its own minimum (a common practice among ISP-operated resolvers that apply a floor of 300–600 seconds regardless of what the zone publishes). During this window, two users making the same DNS query from different locations or different ISPs may receive different answers.

This is what creates the "it works for me but not for them" pattern during migrations. If your caching resolver already expired its record and fetched the new one, you see the new server. If your colleague's ISP resolver hasn't expired yet, they still see the old server. Both are correct answers from each resolver's perspective — they are serving valid cached data. The only way to verify that a change has rolled out to most of the internet is to query the name from a diverse set of resolvers simultaneously: major public resolvers (Google 8.8.8.8, Cloudflare 1.1.1.1, OpenDNS), regional ISP resolvers in multiple countries, and corporate resolvers with long caching policies.

What a propagation checker actually does

The AT USE DNS Propagation Checker opens a multi-region query against the domain you enter. The underlying service — DNSChecker.org — resolves the name from dozens of locations worldwide and shows you a per-resolver result: the current value and whether it matches the expected new value. Green checkmarks mean the resolver is serving the new record. Red or grey entries mean the resolver is either still serving the old cached value or is unreachable. At a glance you can tell what percentage of the global resolver landscape has picked up your change and which specific regions are lagging.

Why TTL planning matters before a migration

The most common propagation mistake is not lowering the TTL before making a change. If you lower a 24-hour TTL to 300 seconds at least 24 hours before a migration, every resolver will expire its cache within 5 minutes of when you make the actual DNS change. If you do not pre-stage the TTL reduction, resolvers that cached the old value with a 24-hour TTL will continue serving it for up to 24 hours. Running a propagation check before, during, and after a cutover gives you visibility into whether your TTL planning worked, whether the new record is resolving correctly, and whether any regions are substantially behind the rest.

Record types to check separately

Propagation is tracked per record type. A and AAAA records for the hostname, MX records for mail delivery, CNAME records for subdomains, and TXT records for SPF and DKIM all cache independently. For a full infrastructure migration, run a propagation check for each record type involved in the cutover, not just the A record. An email cutover that changes MX records can appear complete on the A record check while MX records are still lagging on legacy resolvers — causing some inbound mail to route to the old server.

After you confirm propagation

When the propagation checker shows the new value on the large majority of resolvers, it is safe to decommission the old infrastructure — stop the old server, release the IP, or update SSL certificates that are tied to the hostname. Do not decommission before you confirm propagation: requests still routing to the old server from uncached resolvers will fail with connection errors rather than falling back to the new server. The few remaining slow-propagating ISP resolvers will catch up on their own TTL cycle; for most migrations, 95% coverage within a few hours is enough to proceed.