DNS Propagation Checker

Check whether a DNS change has reached the major public resolvers. Enter a domain, pick a record type, and this tool queries Google, Cloudflare and Quad9 at the same time and compares their answers. If they all agree, your change has propagated to the big global resolvers; if they differ, some are still serving a cached older value. It is the fast "is my DNS change live yet?" check after editing a record.

How to use the DNS Propagation Checker

Enter a domain, choose the record type you changed, and press Check propagation. The tool reports:

• Each resolver's answer side by side — Google, Cloudflare and Quad9.
• A verdict: resolvers agree (the change has reached them) or answers differ (some still hold a cached older value).
• A note if a resolver is unreachable from the browser.

This compares the big global anycast resolvers rather than probing dozens of cities, so read it as "have the major resolvers picked up my change?" — the question that matters most right after an edit. Differences clear once the old record's TTL expires.

What DNS propagation really means

"DNS propagation" is the everyday name for the delay between editing a DNS record and the whole world seeing the new value. It is a slightly misleading phrase, because nothing actively pushes your change outward. What really happens is caching expiry: resolvers all over the internet cached the old value, and each one keeps serving it until the record's TTL (time-to-live) runs out, at which point it fetches the fresh value from your authoritative nameservers.

So the speed of "propagation" is governed almost entirely by the TTL that was in effect when the change was made. If your A record had a TTL of one hour, a resolver that cached it 20 minutes before your edit will keep serving the old IP for another 40 minutes. This is why the standard advice before any planned DNS change is to lower the TTL ahead of time (to a few minutes), make the change, let it settle, then raise the TTL again.

This checker compares the major public resolvers — Google (8.8.8.8), Cloudflare (1.1.1.1) and Quad9 (9.9.9.9). These are huge anycast networks: a single IP is served from data centres worldwide, so querying them from anywhere gives a good read on whether the big resolvers that most people and mail servers actually use have caught up. It is honest to be clear about the limit, though: this is a resolver-agreement check, not a per-city geographic map. Tools that show a world map of dozens of cities are probing many individual vantage points; a browser can only reach the public JSON resolvers directly. For the most common question — "has my record change reached the resolvers my users rely on?" — comparing the major resolvers answers it well, and when they all agree you can be confident the change is effectively live.

Common use cases

• After changing where a domain points — confirm the new A or CNAME is being returned by the big resolvers.
• After an email change — check that an updated MX or TXT (SPF) record has propagated.
• During a migration — watch for all resolvers to converge on the new value before cutting over.
• Diagnosing "it works for me but not for them" — see whether different resolvers are still serving different answers.
• Confirming a fix — verify a corrected record has replaced a bad one everywhere that matters.

Why resolvers still disagree, and what to do

If the resolvers do not agree yet, that is normal for a recent change. The reasons and remedies:

• The old TTL has not expired. A resolver caches the previous value for its full TTL. There is nothing to do but wait it out; the resolver will refresh automatically. Next time, lower the TTL before the change.
• You are mid-migration. If you changed nameservers, the delegation itself is cached at the parent TLD (often for a day or more), so resolvers may still be asking the old nameservers. This takes longer than a simple record edit.
• A resolver shows an empty answer. The record may not exist at that name, or you picked a type the name does not publish. Confirm the record with the DNS Lookup first.
• Negative caching. If the name briefly did not exist, the NXDOMAIN answer is itself cached for the SOA minimum TTL. Check the timer with the SOA Record Lookup.

Because the wait is driven by TTL, the single most useful habit is to plan ahead: drop the TTL a day before a change so propagation is a matter of minutes, then restore it afterwards. Use the DNS TTL Calculator to plan the timing.