What is DNS propagation and why does it take time?
When you migrate your website to a new web host, update an A record, or configure a new email provider, you expect the changes to go live instantly. However, visitors in different cities or on different cellular networks often continue seeing the old server for hours—or even days.
This transition period is known as DNS propagation:
Authoritative Nameserver Update → TTL Expiration Countdown → Recursive ISP Caches Purged → End Users Receive New IP
DNS propagation is not a single synchronized global event. Rather, it is the gradual, decentralized expiration of cached DNS records across millions of independent recursive resolvers operated by internet service providers (ISPs like Comcast, AT&T, Vodafone), public DNS providers (Cloudflare 1.1.1.1, Google 8.8.8.8), and corporate networks worldwide.
The DNS caching hierarchy explained
To understand propagation delays, consider what happens when a browser queries your domain:
[Browser / Device]
│
▼
[ISP Recursive Resolver] (Caches response for TTL duration)
│ (Cache Miss)
▼
[Root DNS Server (.)] ──► [TLD Nameserver (.com)] ──► [Authoritative DNS (Cloudflare/Route 53)]
│ (Returns New IP + TTL)
▼
[ISP Resolver Caches Answer & Responds]
- Your Authoritative Nameserver (Instant): When you save a new IP in Cloudflare, AWS Route 53, or Namecheap, your authoritative nameservers update within seconds.
- Recursive Resolvers (Cached): Millions of ISP resolvers worldwide do not query your authoritative nameserver on every single website visit. Instead, they store the previous answer in their local cache for the duration of your TTL (Time to Live).
- The TTL Clock: As long as that TTL countdown has not reached zero on a specific ISP's resolver, that resolver continues returning the old IP address to its local subscribers.
The role of TTL (Time to Live)
TTL (Time to Live) is a setting measured in seconds attached to every DNS record. It dictates exactly how long resolvers are permitted to cache the answer before asking your nameservers for fresh data:
300 seconds (5 minutes)→ Fast propagation. Ideal for active migrations and cutovers.3600 seconds (1 hour)→ Standard balance between speed and server query load.86400 seconds (24 hours)→ Static records that rarely change (like apex nameservers).
The Pre-Migration Pro Tip:
If you plan to switch hosting servers next Tuesday:
- Lower your TTL to 300 seconds (5 minutes) at least 48 hours before your migration.
- Perform your server migration and update the
Arecord. - Your update will propagate worldwide in just 5 minutes rather than 24 hours.
- Once stable, raise the TTL back to
3600or86400to reduce DNS query load.
Why some users still see the old site (ISP caching traps)
Even when your TTL is set to 300 seconds, certain factors can prolong propagation:
1. ISP Resolver Overrides (Ignoring TTL)
Some budget or regional mobile network ISPs deliberately ignore low TTLs to save bandwidth and reduce upstream DNS traffic. They hard-code a minimum cache time of 12 to 24 hours regardless of what your DNS record specifies.
2. Local Operating System & Browser DNS Caches
Client operating systems (Windows, macOS) and web browsers (Google Chrome) maintain their own internal DNS caches:
- Flush Windows DNS:
ipconfig /flushdns - Flush macOS DNS:
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder - Flush Chrome DNS: Navigate to
chrome://net-internals/#dnsand click "Clear host cache".
3. Stale Negative Caching (SOA Minimum TTL)
If a user attempted to visit a subdomain before you created the DNS record, recursive resolvers cache that "NXDOMAIN (Non-Existent Domain)" error for the duration specified in your SOA (Start of Authority) record's minimum TTL field.
How to test global propagation in real time
Never ask your coworkers or friends if they can see the site yet—their local ISPs provide an unreliable sample.
Use our free DNS Lookup & Propagation Checker to query authoritative records across all essential record types:
A&AAAA(IPv4 and IPv6 web server routing)CNAME(Aliases and CDN routing)MX(Mail exchangers for email delivery)TXT(SPF, DMARC, and site verification tokens)CAA(Certificate Authority Authorization)
You can also test propagation directly from your terminal using dig against specific global resolvers:
# Query Google Public DNS (8.8.8.8)
dig @8.8.8.8 yourdomain.com +short
# Query Cloudflare DNS (1.1.1.1)
dig @1.1.1.1 yourdomain.com +short
# Query Quad9 (9.9.9.9)
dig @9.9.9.9 yourdomain.com +short
If all three global resolvers return your new IP, your DNS has propagated across major international internet backbones.
