How This DNS Propagation Checker Works
Type in a domain, pick a record type, and this tool sends that exact query to 34 named public DNS resolvers at once, live, not from a cached list of past results. Whatever answer the most resolvers return becomes the consensus for that check; anything that disagrees, or a resolver that doesn't answer at all, gets flagged against it so the gap is obvious at a glance. Every resolver stays on the list in the same order every time, by name and IP, whether it agrees, disagrees, or times out. Nothing gets sorted away because the result looks bad.
What This Actually Measures
This is provider-level agreement: does Google's resolver, Cloudflare's, Quad9's, and 31 others currently return the same thing for a domain, each one queried directly from EncodeDesk's own server. It isn't a network of probes scattered across 24 countries. The map marks where each resolver's operator is publicly headquartered, not where the query supposedly traveled, and says so in its own tooltip. Most of the 34 are proper public DNS brands, Google, Cloudflare, Quad9, and similar, including India's own government-run BHARAT PUBLIC DNS. Nine of them, covering countries with no equivalent branded service (Denmark, Pakistan, Bangladesh, Indonesia, Vietnam, the Philippines, Nigeria, Turkey, and Brazil), are a regional ISP's or data center's own resolver instead, labeled "(Regional ISP Resolver)" rather than dressed up as something bigger. It can't see your own ISP's cache either, since that only shows from your own connection. What it can tell you is whether the resolvers most of the internet ultimately depends on have caught up yet.
Why "Propagation" Is Really Just Caches Expiring
DNS doesn't spread out from your registrar like a ripple crossing a pond. Every resolver that has ever looked up your domain cached the old answer, and it keeps serving that cached copy until the TTL you set runs out, no matter what the record says right now. A 300-second TTL means most resolvers should be showing the new value within about five minutes of the change going live. Leave it at the default 3600 or 86400 seconds, and a resolver that happened to cache the old answer a minute before your change could keep handing it out for that entire stretch. That's the whole mechanism behind DNS propagation: not a slow wave moving across the internet, just a few thousand independent caches counting down on their own separate clocks.
When to Actually Use This
Run it right after pointing an A record at a new server, before you shut the old one down, to confirm traffic is actually landing on the new IP everywhere you checked. Check MX record propagation after switching mail providers, to catch a typo before messages start bouncing somewhere you didn't expect. Check TXT record propagation after publishing a new SPF or DKIM string, since one resolver still holding the old value can mean mail quietly landing in spam for hours. Check CAA record propagation after locking a domain to a single certificate authority, so a resolver that hasn't caught up doesn't sit behind an otherwise valid certificate request. It's also the fastest way to explain to a client why their site "still shows the old version" for a little while after go-live: point at the resolver list and show them it's a caching gap, not a broken deploy.
One Checker, Every Record Type
Since it covers every common record type, people end up using this as an A record propagation checker right after a server migration, an AAAA record propagation checker for IPv6 rollouts, a CNAME propagation checker when repointing a subdomain, an MX record propagation checker during an email provider switch, a TXT record propagation checker for SPF and DKIM changes, an NS propagation checker when moving a domain to a new registrar, and a CAA record propagation checker before requesting a new certificate. Same 34 resolvers, same consensus logic, just a different record type picked from the dropdown.
