DNS Propagation

About the DNS Propagation

This DNS propagation checker queries six named public resolvers directly, Cloudflare, Google, Quad9, OpenDNS, AdGuard and Level3, for the same domain and record type, then compares whether every resolver's answer actually matches. Each resolver is queried at its own IP address rather than through your device's configured DNS, so the results reflect what those specific, widely-used public resolvers currently hold, not your own possibly-cached local view.

You reach for this right after changing an A record, switching nameservers, or publishing a new TXT, SPF or similar record, when resolvers around the internet pick up the new value at different times depending on how long they cached the previous one. Instead of guessing from a single lookup, or from your own resolver which may still be serving a stale answer, this shows exactly which of six well-known resolvers have already picked up the change and which have not.

Each resolver's row is named rather than presented as an anonymous numbered vantage point, and answers are sorted and compared as a set before the verdict is decided, so a harmless ordering difference between two resolvers does not falsely register as "still propagating". MX answers are formatted as priority-plus-host, and TXT answers are rejoined from their underlying chunks, rather than being dumped as raw resolver output.

Each resolver is queried once, with a five-second timeout and no automatic retry, which keeps the check fast but also means an occasional "lookup failed" row can be a transient timeout rather than a real problem, worth a second run before drawing conclusions. If every resolver happens to fail at once, the overall verdict still reads as "still propagating" rather than a distinct error state, so the individual resolver rows, not just the headline verdict, are what to check when several show a failure.

How to use it

1. Enter the domain whose record you changed.
2. Choose the record type you are tracking: A, AAAA, MX, TXT, NS or CNAME.
3. Submit to query all six public resolvers at once.
4. Read the headline verdict, fully propagated only appears when every resolver that answered agrees.
5. Scan the individual resolver rows to see the actual values and spot which one still lags behind.
6. If a row shows lookup failed, re-run the check once before assuming a real problem, since each resolver gets a single attempt with a short timeout.
7. Recheck periodically until every row agrees, or lower the record's TTL well before your next planned change to speed this process up.

Examples

• After repointing an A record, confirm the new IP already shows at Cloudflare and Google while a couple of the others still return the previous address.
• Confirm a new SPF TXT string is visible at all six resolvers before cutting a sending provider over in production.
• Verify a nameserver (NS) change has propagated everywhere before decommissioning the old DNS host.
• Check MX records after a mail provider migration and see each resolver's answer formatted as, for example, 10 mail.example.com.
• A domain mid-change shows AdGuard and Level3 still serving the old CNAME target while Cloudflare, Google and Quad9 already return the new one.

Which resolvers are queried, and how

Each of the six resolvers below is queried directly at its own address, bypassing your device or ISP's configured DNS entirely, so the answers reflect what the wider internet is actually being served rather than one possibly-cached local view.

• Cloudflare, 1.1.1.1
• Google, 8.8.8.8
• Quad9, 9.9.9.9
• OpenDNS, 208.67.222.222
• AdGuard, 94.140.14.14
• Level3, 4.2.2.2

How the fully propagated verdict is actually computed

Each resolver's returned records are sorted and compared as a complete set, so a harmless difference in ordering between two resolvers never produces a false mismatch. The overall verdict is consistent, fully propagated, only when every resolver that answered successfully returns the identical sorted set. A resolver that itself errors out is excluded from that comparison but is still shown in its own row, which means it is technically possible to see a fully propagated headline while one resolver's row separately reads lookup failed, another reason to check the individual rows rather than the summary alone.

Reading TTL correctly into a propagation check

TTL, not this tool, ultimately controls how fast a change becomes visible everywhere, so understanding it changes what you should expect to see.

• Lower a record's TTL well in advance, a day or more before the planned change, not at the moment you make it.
• Lowering TTL after publishing the new record does nothing for the old value resolvers already cached under the previous, longer TTL.
• Once the old TTL naturally expires, every resolver will requery and pick up the new value on its own, with no action needed.
• Checking again within seconds or minutes of a change, before any cached TTL could plausibly have expired, is the most common reason people conclude propagation is "stuck" when it is simply still running its course.

Propagation check versus an authoritative lookup

A lookup against a domain's own authoritative nameservers always returns the newest published value immediately, since it goes straight to the source rather than through any caching layer. This tool deliberately does the opposite: it queries public recursive resolvers, the same ones real users, mail servers and other services actually query day to day, so its answer is a more honest signal of what has actually gone live for everyone else, cached copies included, rather than what the authoritative source alone is willing to hand back.

Frequently asked questions