DNS propagation checker
Enter your domain and record type to check propagation across 10 global DNS resolvers simultaneously.
About this tool
DNS propagation is a slightly misleading phrase. Nothing spreads outward from your zone — the authoritative record changes immediately, and what takes time is the expiry of cached copies held by resolvers all over the world. Each resolver keeps a record until its TTL runs out, then fetches the current value, so the delay you experience is bounded by the TTL that was in force when the old record was last cached, not by the one you have just set. Lowering a TTL to 300 seconds after making a change does nothing for the caches already holding the record at 86400. This is why the standard migration sequence is to lower the TTL well in advance, wait for the old TTL to fully expire, then make the change. Propagation is also uneven: some resolvers ignore short TTLs and impose a minimum, some ISPs run aggressive caching, and users on different networks see the switch at different times. This tool queries ten geographically distributed public resolvers at once and shows which return the new record and which still hold the old one.
- 1
Enter your domain name and select the record type you changed (A, MX, TXT, etc.).
- 2
Click Check Propagation — the tool queries 10 global resolvers simultaneously.
- 3
Green rows indicate resolvers that have the updated record; red rows show stale or missing data.
- 4
Check the consistency rate at the top to see how widely the change has spread.
Confirm that a new A record has spread to all major resolvers after a server migration.
Check whether your MX update has propagated before switching email providers.
Diagnose why some users see a new site but others still hit the old IP.
After migrating a server
example.com Type: A8/10 resolvers show new IP — 80% consistentAfter adding SPF record
example.com Type: TXT10/10 resolvers show v=spf1 record — 100% consistentJust after a change
newdomain.com Type: A2/10 resolvers updated — still propagatingSome resolvers still show the old record hours later
Cause: They cached the record under the previous TTL, which may have been 24 hours. Some ISP resolvers also enforce their own minimum TTL and hold records longer than the zone asks.
Fix: Wait for the original TTL to elapse — the one in force before the change, not the new one. Nothing you do at the authoritative side shortens a cache entry that already exists.
Every resolver shows the new record but users still reach the old server
Cause: Caching further down the chain. Operating systems, browsers, and applications keep their own DNS caches, and browsers additionally hold connections open to the old address.
Fix: Flush the OS resolver cache, restart the browser, and test in a private window. Keep the old server running until traffic to it stops, since a slow client can point at it long after DNS has moved.
Results are inconsistent between checks
Cause: Public resolvers are anycast services with many independent nodes, so consecutive queries can reach different instances with different cache states.
Fix: Expect a period where the same resolver flips between old and new answers. Treat propagation as complete only when repeated checks are stable, not on the first all-green result.
These answers explain common dns propagation tasks, expected input formats, and edge cases so both visitors and search engines can understand what this tool does.
How many resolvers are checked?
10 resolvers across different geographic regions: Cloudflare, Google, Quad9, OpenDNS, AdGuard, NextDNS, DNS.SB (Asia), Mullvad (Europe), BlahDNS (Japan), and CanadianShield (Canada).
What does the consistency rate mean?
The consistency rate shows the percentage of responding resolvers that returned the same record set. 100% means all resolvers agree. Lower values indicate the change is still in progress or some resolvers are serving stale cached data.
How long does DNS propagation take?
Propagation speed depends on the TTL of the old record. A low TTL (e.g., 300 seconds) spreads changes in minutes. A high TTL (e.g., 86400 = 24 hours) means resolvers may cache the old record for up to a day.