You updated a DNS record, waited an hour, checked your browser, and everything looks fine. So you close the ticket. Two hours later, half your users in Australia are still hitting the old server. Your DNS change propagated to your local resolver immediately but hasn't reached nameservers in other regions yet.
This is the core problem with DNS propagation: it's not a single event. It's a rolling cascade that happens at different speeds across hundreds of thousands of resolvers worldwide. Checking from your laptop confirms one data point. It says nothing about the other 99% of your users.
When you change a DNS record, the change is immediately visible on your authoritative nameserver. But most users don't query your authoritative nameserver directly. They query a recursive resolver — typically provided by their ISP, their office network, or a public DNS service like Google (8.8.8.8) or Cloudflare (1.1.1.1).
Recursive resolvers cache DNS results based on the TTL (Time to Live) value set on the record. If your A record has a TTL of 3600 seconds (1 hour), every resolver that has cached the old value will continue serving it for up to 1 hour after your change — regardless of when you made the update.
The cascade works like this:
"Propagation complete" means all major resolvers have expired their old cache and are now serving the new record. With a 1-hour TTL, propagation is typically complete within 1–2 hours for most users. With a 24-hour TTL, it can take 24–48 hours.
The most reliable way to verify propagation is to query multiple DNS resolvers in different regions and compare results. If all of them return the new record, propagation is effectively complete for the vast majority of users.
The fastest way to check this is with a free DNS checker tool that queries resolvers across multiple regions simultaneously:
If you're comfortable with the terminal, dig is the standard tool for DNS queries. To check a record against a specific resolver:
# Check your A record against Google's resolver
dig @8.8.8.8 example.com A
# Check against Cloudflare's resolver
dig @1.1.1.1 example.com A
# Check against your local resolver (what you'd see in a browser)
dig example.com ACompare the answer section across all three. If they're returning different values, propagation is still in progress.
To confirm your change is correct on the authoritative server (regardless of cache state), query it directly:
# Find your nameservers first
dig example.com NS
# Then query one directly
dig @ns1.yourdns.com example.com A +norecurseThe +norecurse flag tells dig not to follow referrals — you'll get the authoritative answer directly. If this shows the old record, your DNS provider hasn't processed the change yet. If it shows the new record, the change is correct and you're waiting for cache expiry elsewhere.
| TTL setting | Typical propagation time | Notes |
|---|---|---|
| 60 seconds | 1–5 minutes | Best for migrations and rollbacks |
| 300 seconds (5 min) | 5–15 minutes | Good for active development |
| 3600 seconds (1 hour) | 1–3 hours | Common default — acceptable for stable zones |
| 86400 seconds (24 hours) | 24–48 hours | Avoid for records you may need to change quickly |
These are typical ranges. Some ISPs use resolver implementations that ignore TTL and cache aggressively for longer. Enterprise networks sometimes override TTL at the proxy level. Practically speaking, 95% of users update within 2× the TTL value; a small tail can take longer.
Your browser, your terminal, and your DNS checker all use the resolver configured on the machine or network you're testing from. If you're on a corporate network with a caching DNS proxy, you might see the old record long after public resolvers have updated. Always test from multiple resolvers — especially Google (8.8.8.8), Cloudflare (1.1.1.1), and OpenDNS (208.67.222.222).
If your previous TTL was 86400 (24 hours) and you didn't lower it before making the change, resolvers that cached the record just before your update have up to 24 hours before they re-query. Nothing you do will speed this up for those resolvers — they'll update when their cache expires. Plan ahead by lowering TTL well before any planned change.
If the record you're adding didn't exist before, resolvers may have cached a negative result (NXDOMAIN) from before you created it. Negative cache TTL is typically set in your SOA record's "minimum TTL" field. This can delay visibility of new records even when they're correctly configured on the authoritative server.
Double-check your authoritative nameserver directly (using the +norecurse technique above) before blaming propagation. A surprising number of "propagation issues" are actually save errors at the DNS provider — the change looked successful in the UI but didn't actually commit.
Propagation is a one-time event, but DNS records can change again at any time — intentionally or accidentally. The same risks that apply during migrations apply continuously: unauthorized changes, misconfigured records after deployments, provider-side issues.
A DNS monitoring tool watches your records continuously and alerts you the moment any value changes — so you catch issues before users do, not after.
DNSWatch monitors your A, AAAA, MX, TXT, CNAME, and NS records and sends an alert the moment any value changes unexpectedly. Catch unauthorized changes, deployment errors, and provider incidents before they become outages.
Join the DNSWatch Waitlist Check Your DNS Records Now