The Propagation Check compares the A-record answers for a hostname across 10 public recursive resolvers, so you can confirm whether a recent record change has fully propagated or is still serving stale data on some networks.
Enter a hostname (www.example.org) and run the tool. The probe queries each public resolver and reports the A-record answer each one returns.
Input: Domain — e.g. www.example.org.
Each line shows a resolver and the A-record answer it returned. The summary reports how many resolvers answered and whether their answers are consistent or divergent. If some resolvers return the old value while others return the new one, propagation is still in progress — wait for the old TTL to expire across all networks.
→ Confirm a DNS change has propagated globally after a cutover.
→ Find which resolvers are still serving stale data.
→ Verify propagation before decommissioning an old server.
→ See at a glance whether resolver answers agree or diverge.
It is bounded by the record’s previous TTL. If the old TTL was 3600, most resolvers will pick up the new value within an hour; the long tail can take up to 48 hours for resolvers that ignore TTL. Lower the TTL 24 hours before a cutover to make propagation near-instant.
They are serving a cached answer that has not yet expired. Each resolver caches independently for the TTL it saw when it last queried. Once that TTL expires they will fetch the new value.
You cannot flush other networks’ caches, but you can lower the TTL ahead of the change, and some public resolvers (Google 8.8.8.8, Cloudflare 1.1.1.1) offer cache-flush endpoints for their own caches.