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.

Look up A records

Enter a domain name to lookup A records

View full DNS lookup tool with advanced options →

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 A

The TTL remaining in a cached record appears in the answer section — the number before IN A:

example.com.    3542    IN    A    203.0.113.10

Here 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 A

If 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_TYPE

If 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 A

The 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 NS

Have 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.

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.

Understanding DNS TTL
DNS Lookup Tool — check propagation across Google, Cloudflare, Quad9, and OpenDNS simultaneously
A Record
MX Record
TXT Record
NS Record