DNS Propagation Checker

How to use this DNS propagation checker

1. Enter a domain and record type.
2. See what each major public DNS provider currently returns.
3. If all providers agree, your change has fully propagated.

Why check multiple providers instead of one?

DNS changes don't apply everywhere instantly — each resolver caches records for the TTL duration set on that record. Comparing providers shows whether a recent change has fully rolled out, or whether some resolvers are still serving a cached, older value.

A note on what this tool is (and isn't)

This compares results across different DNS provider networks, not different geographic locations — it runs entirely from your browser, so it can't simulate querying from servers physically located in other countries. For true worldwide geographic propagation testing, a server-based tool is needed.

Why do A records sometimes never fully "agree"?

If a domain is behind a CDN or proxy like Cloudflare, it uses anycast: the same hostname intentionally resolves to different edge server IPs depending on which resolver asks, purely for performance routing — not because anything is broken or still propagating. For these domains, a mismatch on A/AAAA records is completely normal and expected, even long after any change has fully settled.

Why lowering TTL before a planned migration is a standard practice

If you know in advance that you're about to make a DNS change — migrating to a new host, switching mail providers, moving to a new CDN — a common, deliberate practice is lowering the record's TTL well ahead of the actual change, sometimes days in advance, then making the change once that shorter TTL has had time to propagate everywhere. Since a resolver won't cache a record longer than its TTL, a record with a 5-minute TTL at the moment of the actual change will finish propagating globally within minutes rather than potentially taking up to 24 hours if the original, longer TTL were still in effect. Raising the TTL back to a normal, longer value (which reduces DNS query load and is generally preferred day-to-day) once the migration is confirmed stable is the standard follow-up step.

Why nameserver (NS) changes propagate differently — and often more slowly

Changing which nameservers are authoritative for a domain behaves differently from changing a regular record like an A or MX record, because the relevant TTL isn't fully within the domain owner's control. NS record propagation is governed partly by the TTL set at the parent zone (the domain registrar or the TLD registry level, like .com's own root servers), which is often set to a longer default (commonly 24-48 hours) than most domain owners would choose for their own records, and isn't something you can shorten yourself the way you can lower a TTL on your own A or MX records before a change. This is exactly why a nameserver migration is generally expected to take longer to fully settle than other DNS changes, and why patience specifically around NS changes is standard advice rather than a sign something went wrong.

Negative caching — why a "record not found" can also get stuck

It's not just successful lookups that get cached — resolvers also cache the fact that a record doesn't exist, a behavior called negative caching, controlled by the minimum TTL field in the domain's SOA (Start of Authority) record. This matters specifically when adding a brand-new record type to a domain that didn't have one before: if a resolver already queried for, say, a TXT record before it existed and cached the "not found" result, that resolver may keep returning "not found" for the negative-caching duration even after the record is actually published, independent of the new record's own TTL. This is a less commonly known but genuinely real cause of a newly added record appearing to "not be there yet" on some resolvers even well after publishing it.

Why comparing major resolvers is meaningful even though it isn't full geographic testing

While this tool genuinely can't simulate querying from physical servers in different countries (as noted above), checking against Google, Cloudflare, Quad9, and OpenDNS isn't a purely superficial comparison either — each of these providers operates its own resolver infrastructure across a globally distributed anycast network, meaning a query to any one of them is already being answered by whichever of that provider's many worldwide locations is closest to wherever the query actually originates from. Differences between these four providers can reveal genuine propagation gaps or caching differences between major resolver operators, even though it's a different kind of comparison than querying from specific countries directly — useful and meaningful, just answering a somewhat different question than pure geographic propagation testing would.

Limitations of this tool

This tool compares results across four major public DNS providers, which cover a large share of internet DNS traffic but aren't the complete universe of resolvers — many internet users are still served by their ISP's own resolver, which isn't included in this comparison and can have its own independent caching behavior. It runs entirely from your browser, so it queries these providers from wherever you currently are, not from multiple simulated geographic locations, and it doesn't check or display negative caching status for records that don't yet exist. Agreement across these four providers is a strong, practical signal of propagation, but not an absolute guarantee that every resolver worldwide has already picked up the change.