To verify DNS propagation worldwide, query the same record from resolvers in multiple regions at once and compare their answers against your authoritative nameserver. When every location returns the new value and the TTL countdown confirms the record is fresh rather than cached, propagation is complete. When some regions still show the old value, those resolvers are serving a cached copy that has not yet expired. This guide shows how to run that global check, how to read the TTL so a stale cache cannot fool you, and when the result is safe to trust.
What DNS propagation really is
Propagation is a slightly misleading word. Your change takes effect at your authoritative nameservers immediately. What takes time is the expiry of older copies that recursive resolvers around the world cached before you made the change. Each resolver keeps a record until its TTL (time to live) runs out, then fetches the fresh value. So verifying propagation is really about confirming that cached copies everywhere have expired and been replaced.
Because resolvers cache independently, a record can be updated in one country and still stale in another for minutes or hours. That is normal, not a fault. For the broader troubleshooting picture, the DNS propagation troubleshooting guide covers what to do when a change seems stuck.
Why resolvers disagree by location
Different regions use different recursive resolvers, and each cached your record at a different moment. A resolver that fetched your record one hour before your change still has most of the TTL left to run, while a resolver that happened to query just after your change already shows the new value. This is exactly why a global propagation checker shows a patchwork of old and new answers. The guide on why a DNS checker shows different IPs by location explains the mechanics in full.
Authoritative versus cached answers
| Signal | Authoritative answer | Cached answer |
|---|---|---|
| Source | Your own nameserver | A recursive resolver |
| TTL value shown | The full configured TTL | A countdown below the full TTL |
| Reflects latest change | Always | Only after the cached copy expires |
| Use it to | Confirm the correct target value | Judge how far propagation has spread |
The practical takeaway: first query your authoritative nameserver to learn the correct answer and the full TTL, then query public resolvers worldwide to see how many of them have caught up. A resolver showing a TTL well below the configured value is counting down a cached copy.
How to verify propagation step by step
- Note your record's TTL. Before or just after the change, record the TTL. It tells you the maximum time cached copies can survive.
- Query your authoritative nameserver. Confirm the new value is actually live at the source. If it is not here, nothing downstream will ever update.
- Query public resolvers in several regions. Check answers from multiple continents, not just your own network, which may itself be caching.
- Compare values and TTLs. Regions returning the new value are done. Regions still showing the old value are serving a cache that will expire within the remaining TTL.
- Re-check after the TTL elapses. Wait at least the full TTL from the moment of your change, then re-run. Any region still stale after that points to a longer upstream TTL or a configuration issue.
The Valla DNS lookup tool queries authoritative servers directly so you can confirm the source value, and the propagation check compares resolvers across multiple regions in one view.
When you can trust the result
You can trust that propagation is complete when two conditions hold. First, every region you checked returns the new value. Second, enough time has passed since your change to exceed the old record's TTL everywhere, so no resolver can still be holding a valid cached copy. If you only just made the change, a clean-looking check may simply mean those resolvers had not cached the record at all; it is not proof the old value is gone from resolvers that did cache it.
A useful habit is to lower the TTL a day before a planned change. A short TTL means cached copies expire quickly, so the actual switch propagates in minutes rather than hours. Raise it again once the change is confirmed stable.
What slows propagation down
The biggest factor is the TTL that was in effect before your change, because that governs how long old copies live. Registrar-level changes such as nameserver updates propagate more slowly than ordinary record edits, since delegation records often carry one to two day TTLs. Finally, some networks and devices cache beyond the stated TTL or hardcode resolvers, which is why your own machine may lag behind the global picture even when most of the world has updated.
Frequently asked questions
How do I verify DNS propagation across the whole world?
Query the record from resolvers on multiple continents and compare them to your authoritative nameserver. The Valla propagation check does this in one view, so you can see at a glance which regions show the new value and which are still cached.
How long should I wait before trusting a propagation check?
Wait at least as long as the record's old TTL, measured from the moment you made the change. Until that time passes, resolvers that cached the previous value may still be serving it legitimately, so an early check can look misleadingly complete.
Why does the checker show the new value everywhere except on my computer?
Your device or local network is almost certainly caching the record itself, independently of public resolvers. Flushing your local DNS cache usually resolves the discrepancy once the global check already shows the new value.
Does lowering the TTL speed up propagation?
Lowering the TTL before a change speeds up the next change, because cached copies expire sooner. It cannot retroactively speed up a change already in progress, since resolvers are still bound by whatever TTL was in effect when they cached the old value.
Is propagation the same for A records and nameserver changes?
No. Ordinary record edits are governed by that record's TTL, often minutes to an hour. Nameserver and delegation changes involve registry-level records that commonly carry one to two day TTLs, so they typically take noticeably longer to settle everywhere.
Making a change now? Confirm the source value with the Valla DNS lookup tool, then watch it roll out region by region.