Global DNS Propagation Checker

Instantly check your domain's DNS records across major public root servers globally. Track exactly where your recent IP or MX changes have taken effect.

Domain Name

Record Type

Queries Google, Cloudflare, Quad9, OpenDNS, and 6 other major global resolvers. This takes about 3-5 seconds.

Our DNS Propagation Checker queries public resolvers around the world and compares their answers for your domain. Use it after a DNS change to see exactly which regions have picked up the new value and which are still serving the cached old one.

What is DNS Propagation?

DNS propagation is the period after you change a DNS record during which different resolvers around the world return different answers. Some already serve the new value while others still hold the old one in cache.

Strictly speaking nothing propagates. When you edit a record, your authoritative nameservers change immediately. What takes time is cache expiry: every resolver that previously looked up your record keeps the answer until its TTL counts down to zero, then fetches a fresh copy.

That is why the TTL you set before a change controls how long the transition lasts. A record with a TTL of 86400 seconds can be served from cache for a full day after you edit it.

Nothing physically propagates — resolver caches simply expire at different times
The previous TTL determines how long the old value survives
Authoritative nameservers update the instant you save a change
Different regions and ISPs complete the transition at different times
Some resolvers ignore short TTLs and impose their own minimum

Why Checking DNS Propagation Matters

During a migration, propagation is the window in which your service exists in two places at once. Users on updated resolvers reach the new server while users on stale caches reach the old one — and if you have already shut the old server down, those users see an outage.

Checking propagation from multiple vantage points tells you when it is genuinely safe to decommission the old infrastructure. It also catches the case where a change did not save correctly at the authoritative server, which otherwise looks identical to slow propagation.

Shows when it is safe to shut down old servers after a migration
Distinguishes a slow cache from a change that never saved
Reveals resolvers that override your TTL with their own minimum
Confirms that all your authoritative nameservers agree
Prevents the split-brain state where users see two different sites

How This DNS Propagation Checker Works

The tool queries the same record from multiple public resolvers in different networks and regions, then compares their answers.

Validates the domain input against format and SSRF safety checks
Queries the chosen record type from several geographically distributed resolvers
Records the value and remaining TTL each resolver returns
Compares answers to identify which resolvers still hold the old value
Summarises how far the change has spread

How to Use the DNS Propagation Checker

Enter your domain name in the input field
Choose the record type you changed, such as A, MX or TXT
Run the check to query resolvers worldwide
Compare the answers — matching values mean propagation is complete
Re-run periodically until every resolver returns the new value

Understanding Your Propagation Results

Each resolver returns a value and a remaining cache lifetime. Here is how to interpret them:

Field / Value	Meaning
`All resolvers agree`	Propagation is complete for the resolvers tested. It is now reasonably safe to decommission the old endpoint, though giving it an extra day of grace is prudent.
`Mixed answers`	Some resolvers hold the old value in cache. This is normal immediately after a change. Wait for the previous TTL to elapse and check again.
`Remaining TTL`	How many seconds until that resolver discards its cached copy. It counts down towards zero, at which point the resolver fetches the current value.
`No answer`	The resolver returned nothing. Either the record does not exist, or a previous NXDOMAIN is cached — negative caching is governed by the SOA minimum field.
`Old value everywhere`	If no resolver shows the new value long after the TTL expired, the change probably never saved. Query your authoritative nameserver directly to confirm.

Common Problems & How to Fix Them

This is usually not a propagation problem at all — the record was probably never saved, or was saved in the wrong zone.

Query your authoritative nameserver directly rather than a public resolver. If the authoritative server still returns the old value, re-apply the change in your DNS provider control panel and confirm you are editing the zone that your NS records actually delegate to.

Some ISP resolvers enforce their own minimum cache time and ignore short TTLs, commonly rounding anything below 30 minutes up.

There is nothing you can do to force those caches to expire. Plan migrations so that the old endpoint keeps serving for at least 48 hours after the change, regardless of your configured TTL.

This is a zone replication failure, not propagation. Secondary nameservers have not pulled the updated zone from the primary.

Check the SOA serial on each nameserver. If they differ, the serial was probably not incremented after the edit, so secondaries never noticed a change. Increment it and confirm the serials converge.

This is the expected split-brain state during propagation: some users reach the new server while others still reach the old one.

Keep both endpoints serving identical content until propagation finishes. Never shut down the old server the moment you change DNS — that is what turns a smooth migration into an outage.

Best Practices

Lower the TTL to 300 seconds at least 24 hours before a planned change
Keep the old endpoint running for at least 48 hours after switching
Verify the change on your authoritative nameserver before checking public resolvers
Restore a longer TTL once the migration is complete and stable
Confirm every authoritative nameserver returns the same SOA serial
Schedule DNS changes for low-traffic periods where possible
Never change nameservers and records at the same time — do one, then the other

Security Recommendations

Treat a record you did not change appearing with a new value as a possible DNS hijack — verify at the authoritative server immediately
Enable DNSSEC so resolvers can detect forged answers injected during propagation
Monitor your critical records continuously rather than only during planned changes
Be aware that long TTLs extend the window in which a poisoned cache entry persists
After any suspected compromise, check propagation from multiple regions, since targeted hijacks may affect only some networks
Keep registrar and DNS provider accounts protected with multi-factor authentication

Frequently Asked Questions

It depends on the TTL of the previous record. Most resolvers pick up a change within the old TTL window — commonly 5 minutes to an hour — but some ISPs enforce longer minimums, so allow up to 48 hours for full worldwide propagation.

Not after the fact. The only effective step is preparation: lower the TTL to 300 seconds at least a day before the change, so caches hold the old value for a much shorter period. Once a record is cached with a long TTL, you cannot force it to expire.

Each resolver caches independently and started caching at a different moment, so their TTLs expire at different times. Mixed answers immediately after a change are normal. Persistent disagreement long after the TTL expired points at a replication failure between your nameservers.

For stable records, 3600 seconds (one hour) balances cache efficiency against flexibility. Lower it to 300 seconds a day before any planned change, then restore the longer value once the migration is complete and verified.

It helps only on your own machine. It has no effect on the resolvers your users rely on. Flushing locally is useful for testing your own view, not for accelerating propagation for anyone else.

Probably not. If no resolver shows the new value well after the TTL expired, the record likely was not saved or was saved in a zone that is not the one your NS records delegate to. Query your authoritative nameserver directly to find out.

Once every resolver you can test returns the new value, and preferably 24 to 48 hours beyond that. Some caches are slower than any test can reveal, so a grace period is cheap insurance against a self-inflicted outage.