How to check DNS propagation

Overview

"Check DNS propagation" means asking several resolvers spread around the internet whether they each see your newest record. Because each resolver caches for its own TTL, there is no single "is it propagated yet" switch. You check authoritative truth, then recursive visibility, then compare across regions.

What to expect in numbers

| Time after change | Typical picture |

| 0 to 5 minutes | Authoritative server already serves the new record; the largest public resolvers may still cache old |

| 5 minutes to TTL | Each resolver flips as its cache expires; this is the variable window |

| After the old TTL | Whole world converged, barring odd resolver quirks |

Step 1. Ask the authoritative source directly

The authoritative nameserver answers the source of truth immediately after the zone change. dig on Linux/macOS or nslookup on Windows:

• nslookup -type=NS example.com prints the nameservers.
• Then query one directly: nslookup -type=A www.example.com ns1.example.com (replace with the real nameserver), which skips every cache.

If the authoritative server answers older than the change, your zone update failed or has a delay. If it answers the new value, the problem is cache, not configuration. When working through a DNS host, use the host's own online DNS checker first; they resolve against the authoritative zone.

Step 2. Compare public resolvers

• nslookup example.com 8.8.8.8 (Google)
• nslookup example.com 1.1.1.1 (Cloudflare)

Getting different answers between Google, Cloudflare, your ISP, and another provider means you are inside the propagation window, not misconfigured. The same command against your ISP's resolver often shows the oldest when the migration recently reached other networks.

For other record types the same flag works:

• nslookup -type=MX example.com 8.8.8.8
• nslookup -type=CNAME www.example.com 8.8.8.8
• nslookup -type=TXT _dmarc.example.com 8.8.8.8

dig (when installed) shortens this to one command, for example dig +trace example.com A walks the whole delegation chain, and dig example.com A @8.8.8.8 targets one resolver.

Step 3. Use a public DNS checker

Web tools maintain resolved queries from several geographic locations:

• Whatdns, DNSChecker, and similar "DNS propagation checkers" show which countries/regions see which value.
• Search-result-based domains validators are also fine only for email DNS (SPF/DKIM/DMARC); use a dedicated propagation checker for A/NS.

Types supported vary, so pick a tool that lists the exact record types you changed: some only check A, others include MX, NS, TXT. Expect a row per resolver with the value and an "updated" time.

Step 4. Interpret anomalies

• One region stuck on the old value for long: check that regional ISP cache (some hold beyond TTL) or a misconfigured authoritative delegation specific to a region.
• SERVFAIL from a resolver: the recursive server tried and failed to reach the authoritative server, which is usually an network problem on the authoritative side or a truncated zone, not TTL.
• NXDOMAIN on a name that exists: the resolver holds a negative cache entry from when the record was absent; negative TTL is real and you wait it out.

Caveats

• Browser and OS have their own short DNS caches; flush them on the test machine (ipconfig /flushdns, dscacheutil -flushcache) to avoid reading a local artifact.
• Changing TTL after a change does not retroactively shorten answers already cached under the old TTL; the practical trick is lowering it before the change, as the TTL article explains.
• "Propagated" never means "every resolver on the internet", only that all resolvers your checker can reach return the new value. If a handful of regional ISPs still lag, re-check in a few hours while the old TTL burns out.

The propagation article explains why the wander is a cache heuristic; the TTL article explains the number you provision before you start.