Network & DNS › Network & DNS Tools

DNS Propagation Checker

dns-propagation-checker

Launch a global propagation check workflow and verify DNS updates across many regions.

Enter a target and run the tool.

About DNS Propagation Checker

DNS propagation describes the period after you change a DNS record during which different resolvers around the world still serve the old cached value. Until every resolver's cache for that name expires (governed by the previous record's TTL), users in different regions or on different ISPs can see different results — leading to mysterious "it works for me" support tickets and partial outages during cutovers. A DNS propagation checker resolves the same name from many resolvers in many geographic regions simultaneously, giving you an instant snapshot of how rolled-out a change is. Our DNS propagation workflow opens a multi-location query against the domain you enter so you can see at a glance whether all major resolvers (Google 8.8.8.8, Cloudflare 1.1.1.1, OpenDNS, regional ISPs) have picked up the new record, or whether some are still serving stale data. This is essential before announcing an email migration, a hosting move, an SSL re-validation, or any change that depends on DNS being globally consistent. Free, opens in a new tab, no signup.

Common use cases

  • Verify a hosting migration has propagated worldwide before announcing it.
  • Check email cutover propagation before retiring an old mail server.
  • Diagnose region-specific reports of incorrect DNS results.
  • Confirm a TTL reduction took effect ahead of a planned change window.
  • Validate global propagation of a DNSSEC update.

How to use this tool

  1. Enter the domain name whose propagation you want to verify.
  2. Click "Open Propagation Checker" to launch a multi-region query.
  3. Review which resolvers return the new value vs. the old.
  4. Wait for the previous TTL to elapse if any resolvers are still serving stale data.

Frequently asked questions

How long does DNS propagation take?

Most propagation completes within the previous record's TTL — often 1 to 4 hours. Some ISP and corporate resolvers cache longer than the published TTL.

Why do some regions show old results?

Resolvers cache independently, and some override low TTLs with their own minimum. Wait for the previous TTL to fully expire across all resolvers.

Can I speed up propagation?

Lower the TTL well in advance of a planned change (e.g., to 300 seconds) so caches expire quickly during the cutover.

Should I check more than one record type?

Yes — for full cutovers verify A, AAAA, MX, CNAME, and TXT separately, since each is cached independently.