How to Check DNS Propagation: A Developer's Guide
Learn what DNS propagation is, why it takes time, how to check whether your DNS changes have propagated across resolvers, and what to do when propagation stalls.
How to Check DNS Propagation: A Developer's Guide
TL;DR DNS propagation is the time it takes for a DNS change to be visible across all resolvers worldwide. It's not instantaneous — caching resolvers serve the old record until the TTL expires. To check propagation, query multiple resolvers simultaneously and compare results. If different resolvers return different answers, propagation is still in progress.
What Is DNS Propagation?
When you change a DNS record — update an A record to point to a new server, change your MX records to a new mail provider, add a TXT record for domain verification — that change doesn't appear everywhere at once.
DNS is a distributed system. Your authoritative nameserver holds the source-of-truth record, but the internet doesn't query your nameserver directly for every lookup. Instead, caching resolvers (operated by ISPs, cloud providers, enterprises, and public DNS services like Google and Cloudflare) store copies of DNS records locally. These cached copies are served for subsequent queries until the cache entry expires.
Propagation is the process of those cached entries expiring and resolvers fetching fresh records from your authoritative nameserver.
Why this matters
The practical consequence: immediately after a DNS change, different users see different results depending on which resolver their device uses and when that resolver last cached your record. A user whose ISP resolver cached your old IP an hour ago will get the old answer. A user whose resolver has an empty cache will get the new answer.
This isn't a bug — it's how DNS is designed. The caching model is what makes DNS fast and scalable at internet scale. But it means you need to verify propagation rather than assume it.
Why Propagation Takes Time: The TTL
Every DNS record has a TTL (Time To Live) value, measured in seconds. When a caching resolver receives a record, it stores it for exactly that many seconds. After the TTL expires, the next query for that name causes the resolver to fetch a fresh copy from your authoritative nameserver.
Common TTL values and what they mean for propagation:
| TTL | Duration | Propagation window |
|---|---|---|
| 300 | 5 minutes | Most resolvers see changes within ~5–10 minutes |
| 3600 | 1 hour | Full propagation can take 1–2 hours |
| 86400 | 24 hours | Full propagation can take up to 48 hours |
The math: if your record has a TTL of 3,600 seconds and a resolver cached it 45 minutes ago, that resolver will serve the old answer for another 15 minutes before fetching fresh data. Globally, resolvers cached your record at different times, so the propagation window is spread across the full TTL duration.
TTL doesn't mean propagation will take that long
TTL is the upper bound, not a guarantee. Resolvers that haven't cached your record yet will fetch the new record immediately. Resolvers whose cache entry is about to expire will get the new record as soon as their TTL runs out. In practice, propagation for a 3,600-second TTL often completes within 30–60 minutes for most users, even if the theoretical window is up to an hour.
How to Check DNS Propagation
Method 1: Query multiple resolvers simultaneously
The most effective way to check propagation is to query several geographically and operationally diverse resolvers and compare their answers. If they all return the same result, propagation is likely complete for those locations. If they disagree, propagation is still in progress.
DNS Buddy's DNS lookup tool queries four major public resolvers — Google (8.8.8.8), Cloudflare (1.1.1.1), Quad9 (9.9.9.9), and OpenDNS (208.67.222.222) — simultaneously and displays the results side by side. Resolver disagreement (different answers from different resolvers) is immediately visible.
Use it at: DNS Lookup
What to look for:
- All resolvers return the new record → propagation is complete for these resolvers
- Some resolvers return the old record → those resolvers still have the old entry cached
- All resolvers return the old record → propagation hasn't started at these resolvers, or your change hasn't been applied
Method 2: dig from the command line
dig is the standard command-line DNS query tool. Available on Linux and macOS; on Windows, use WSL or the nslookup command.
Query a specific resolver with the @ flag:
# Query Google's resolver
dig @8.8.8.8 example.com A
# Query Cloudflare's resolver
dig @1.1.1.1 example.com A
# Query the authoritative nameserver directly (bypasses caching)
dig @ns1.example.com example.com AThe TTL remaining in a cached record appears in the answer section — the number before IN A:
example.com. 3542 IN A 203.0.113.10Here 3542 is the remaining TTL in seconds — meaning this resolver cached the record 58 seconds ago (3600 - 3542 = 58).
Method 3: Query your authoritative nameserver directly
Querying your authoritative nameserver bypasses caching entirely and shows what the source-of-truth record currently is. This lets you confirm your change was actually applied before checking propagation.
# First, find your authoritative nameserver
dig example.com NS
# Then query it directly
dig @ns1.your-registrar.com example.com AIf your authoritative nameserver is returning the old record, the problem is in your DNS provider configuration, not propagation. Fix the record first, then check propagation.
Method 4: Check from multiple geographic locations
Public resolver results reflect the resolver's location and cache state, not the querying user's location. To simulate what users in different regions see, you want to check from resolvers in different regions — or use a propagation checker that tests from nodes worldwide.
DNS Buddy queries from US-based resolver infrastructure. For geographic spot checks, consider combining DNS Buddy results with command-line queries against regional resolver IPs.
Reading Propagation Results
Resolver agreement: what it means
When all resolvers you query return the same answer, propagation is complete for those resolvers. This doesn't mean every resolver in the world has the new record — resolvers you didn't query might still be serving the old answer. But the four major public resolvers (Google, Cloudflare, Quad9, OpenDNS) cover a large fraction of DNS traffic, especially for developer and technical audiences.
Resolver disagreement: what to do
If different resolvers return different answers, propagation is in progress. The old answer is being served by resolvers whose cache entry hasn't yet expired. Wait for the TTL window to close and re-check.
Don't make additional changes to the record during propagation — each change restarts the TTL on newly cached entries, potentially extending the propagation window.
The authoritative nameserver returns the wrong record
If your authoritative nameserver itself returns the old record, the change wasn't applied. Log into your DNS provider and verify:
- The record was saved (some providers require explicit confirmation)
- You edited the correct record (check the name/subdomain field —
@means the apex domain, not a subdomain) - You saved to the correct zone (verify the domain name)
NXDOMAIN when you expect a record
NXDOMAIN (no such domain) means the resolver has no record for that name. This can happen legitimately for a new record that hasn't propagated yet, or indicate the record doesn't exist in your zone. Query your authoritative nameserver first to confirm the record exists.
What to Do When Propagation Is Stuck
Confirm the change is actually in the zone
dig @ns1.your-authoritative-ns.com example.com RECORD_TYPEIf this returns the old record, your change wasn't applied. If it returns the new record, the authoritative source is correct and you're waiting for cache expiry.
Check the TTL of the cached record
dig @8.8.8.8 example.com AThe TTL in the answer tells you the maximum remaining wait. If it says 3540, you have up to 3540 more seconds (about 59 minutes) before that resolver fetches fresh data.
Consider resolver-level caching quirks
Some ISP resolvers don't strictly honor TTL — they may cache records longer than specified, especially if they're under load or misconfigured. This is uncommon with major public resolvers (Google, Cloudflare) but does happen with some enterprise and ISP resolvers.
If a record appears to be stuck well past its TTL on a specific resolver, it may be a resolver issue rather than a propagation issue. Verify against Google (8.8.8.8) and Cloudflare (1.1.1.1) as they're most likely to honor TTL precisely.
Negative caching (NXDOMAIN propagation)
If you're adding a new record where none existed before, resolvers may have cached a negative response (NXDOMAIN or NODATA). Negative caches are governed by the SOA MINIMUM TTL of your zone, which is often set to 3,600 seconds independently of individual record TTLs. A resolver that cached NXDOMAIN for your record will continue returning NXDOMAIN until that cache entry expires.
Record-Type Specific Notes
A and AAAA records
Propagation follows the record TTL directly. If you're migrating a server (changing the IP in your A record), keep the old server running until propagation is complete — users still being served the old IP need it to be reachable.
MX records
Email delivery depends on MX records. During propagation, some senders will use the old MX and some will use the new MX. If you're migrating mail providers, keep the old mail server accepting mail until propagation is complete and you're confident all senders have the new record.
TXT records (domain verification, SPF)
TXT records used for domain verification (Google, Microsoft 365, etc.) usually require propagation before verification succeeds. If a verification check fails immediately after you add the record, wait a few minutes and retry — the verification service may be seeing the old (empty) cache.
For SPF records specifically, keep your old SPF record in place until the new one has propagated. Running with no SPF record during the transition causes mail authentication failures.
CNAME records
CNAMEs propagate the same way as A records. One common gotcha: if you're replacing an A record with a CNAME (or vice versa), some resolvers may briefly return the wrong record type if they cached the old type. Both records should propagate within the TTL window.
NS records (nameserver changes)
Changing nameservers is the slowest DNS change. NS records at the registry (the .com, .net, etc. TLD zone) have their own TTL, typically 172,800 seconds (48 hours). The registrar must also update the delegation at the registry. Plan for a full 48-hour propagation window for nameserver changes.
Prepare Before Making DNS Changes
Lower your TTL before a planned change
If you know you're making a DNS change in advance, lower the TTL to 300 seconds (5 minutes) 24–48 hours beforehand. Once all resolvers have fetched the low-TTL record, future changes will propagate in minutes rather than hours.
After the change is confirmed and stable, raise the TTL back to your normal value (3,600 or higher).
Document your current records
Before any change, record the current values. If you need to roll back, you want to know exactly what to restore:
# Capture current records
dig example.com A
dig example.com MX
dig example.com TXT
dig example.com NSHave a rollback plan
For critical records (A records for production services, MX records for email), know what you'll change the record back to if something goes wrong. The rollback itself is another DNS change and will take as long to propagate as the original change.
If the change is bigger than one record, use the DNS migration checklist to capture zone inventory, TTLs, registrar state, DNSSEC, and rollback values before the cutover.
Frequently Asked Questions
How long does DNS propagation take?
Propagation time equals the TTL of the record being changed. A record with a 3,600-second (1 hour) TTL will fully propagate within 1 hour of the change — often sooner for resolvers that cached the record recently. A record with an 86,400-second (24 hour) TTL can take up to 24–48 hours.
Why do different people see different DNS results?
Because they use different DNS resolvers, each with their own cache. Your ISP's resolver, your office's internal resolver, and public resolvers like 8.8.8.8 all cache DNS records independently. During propagation, resolvers that cached the old record before your change are still serving the old answer.
Can I force DNS propagation to happen faster?
Not directly — you can't flush other people's resolvers. You can lower your TTL before a planned change (giving resolvers a shorter cache window) and use a low TTL during a migration. Some resolvers support cache flushing for their own cache, but you can't control other resolvers.
What does it mean when my DNS lookup tool shows different results from different locations?
It means propagation is still in progress. Resolvers in different locations cached your record at different times, so they expire at different times. The difference will resolve itself as each resolver's cache entry expires and it fetches the new record.
Why does my authoritative nameserver show the right record but public resolvers still show the old one?
This is normal during propagation. Caching resolvers serve the old record until their cache entry expires (at the TTL). Your authoritative nameserver is the source of truth, but resolvers don't check it on every query — they serve from cache to reduce load and latency.
Does DNS propagation affect all record types the same way?
The propagation mechanism is the same for all record types, but nameserver (NS) changes take longer because the NS delegation is held at the TLD registry (e.g., the .com zone), which has its own TTL — usually 48 hours. All other record changes propagate based on the individual record TTL.
Propagation maps vs multi-resolver lookup
Visual propagation checkers (DNSChecker, WhatsMyDNS) sample probes worldwide and are useful for stakeholder updates during marketing cutovers. For engineering evidence, query named public resolvers directly — Google, Cloudflare, Quad9, and OpenDNS cover most developer and API traffic. See our DNSChecker alternatives and WhatsMyDNS alternatives comparisons for when each approach fits.
Related Topics
- Understanding DNS TTL
- DNS Lookup Tool — check propagation across Google, Cloudflare, Quad9, and OpenDNS simultaneously
- A Record
- MX Record
- TXT Record
- NS Record