DNS propagation is the period between making a DNS change and that change being visible everywhere on the internet. It can take anywhere from a few minutes to 48 hours, and different people in different locations may see different results during that window. Understanding why helps you predict timelines, reduce wait times, and diagnose situations where propagation seems stuck.
When you update a DNS record — say, changing an A record from 1.2.3.4 to 5.6.7.8 — the change is immediate at your authoritative nameserver. Your DNS provider updates its own servers right away. But the internet doesn't query your authoritative nameserver for every DNS lookup. Most queries are answered by recursive resolvers — DNS servers operated by ISPs, cloud providers, and public services like 8.8.8.8 (Google) and 1.1.1.1 (Cloudflare) — that cache answers to avoid querying authoritative servers on every request.
"DNS propagation" is really the process of those caches expiring and resolvers fetching fresh answers from your authoritative nameserver. Until a resolver's cached answer expires, it will return the old IP address regardless of what your authoritative nameserver says.
Every DNS record has a TTL (Time To Live) value, measured in seconds. It tells recursive resolvers how long to cache the answer before querying again. When the TTL expires, the resolver fetches a fresh answer. Until it expires, the resolver serves the cached value.
Common TTL values:
The practical implication: if your A record has a TTL of 86400 and you just updated it, some resolvers will serve the old IP for up to 24 more hours. If the TTL is 300, most resolvers will have the new value within 5–10 minutes.
# macOS / Linux — check current TTL on an A record
dig example.com A +noall +answer
# You'll see something like:
# example.com. 3600 IN A 1.2.3.4
# ^^^^ this is the TTL in secondsEven with a low TTL, you'll observe that DNS changes appear at different times for users in different locations. This is because there are thousands of recursive resolvers operating independently around the world, each with its own cache state.
When a resolver cached your old record, it reset its TTL counter from the current value at that moment. If a resolver cached your record 45 minutes into a 3600-second TTL, it will serve the old answer for only 15 more minutes after your change — but a resolver that cached it 5 seconds ago will serve the old answer for another 3595 seconds.
Some ISPs and enterprise DNS resolvers ignore or extend TTLs, caching records for longer than the TTL instructs. This is technically non-compliant but common in practice. Users behind such resolvers will see stale data longer than your TTL suggests. This is a known issue with certain large ISP resolvers in Asia, Eastern Europe, and Latin America.
Major DNS providers like Cloudflare and AWS Route 53 use anycast routing — the same IP address is announced from multiple data centers simultaneously, and BGP routes your query to the nearest one. When you make a DNS change, the provider propagates it to all their anycast nodes, which takes a small amount of time (typically seconds to minutes for major providers). During that window, users routed to different nodes may see different answers.
In practice, with a TTL of 300 seconds:
With a TTL of 3600 seconds:
With a TTL of 86400 seconds: up to 24–48 hours is realistic for global propagation. The "48 hours" number that's often cited represents the theoretical maximum for non-compliant resolvers with extended caching behavior.
Not all DNS record types behave the same way:
Standard address records. Propagation is governed by TTL. Changing an A record is the most common DNS change operation.
Alias records. CNAME changes propagate like A records (TTL-governed), but note that a CNAME lookup chains to the target's A record, which has its own TTL. The effective propagation time is the max of both TTLs.
Changing your domain's nameservers (e.g. migrating DNS providers) is slower. NS records are controlled by your domain registrar and cached by the root nameservers. Expect 24–48 hours for NS changes to propagate globally, regardless of TTL, because the parent zone (e.g. .com) has its own caching behavior that you don't control.
Mail exchanger records. Propagation is TTL-governed like A records, but email systems may also cache MX lookups independently. Keep old mail servers accepting email for 24–48 hours after an MX change to avoid lost mail during the transition.
The fastest way to check whether your DNS change has reached a given resolver is to query it directly:
# Query Google's resolver (8.8.8.8) specifically
dig @8.8.8.8 example.com A +short
# Query Cloudflare's resolver (1.1.1.1)
dig @1.1.1.1 example.com A +short
# Query your local resolver (whatever your machine uses by default)
dig example.com A +shortIf the first two return different values, the change has reached Google and Cloudflare but not everywhere yet. If all three match, propagation is well advanced.
To check propagation from multiple geographic locations simultaneously without running queries on servers around the world, use our free DNS checker tool — it queries from dozens of locations and shows you which ones have the new value and which are still cached on the old one.
If propagation appears stuck after the expected window, diagnose in this order:
dig @ns1.yourdnsprovider.com example.com A. If this still returns the old value, your DNS provider hasn't saved the change correctly.sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder. Windows: ipconfig /flushdns. Linux: varies by resolver (systemd-resolved: sudo systemd-resolve --flush-caches).Our free DNS checker queries from multiple global locations and shows you which resolvers have picked up your change and which are still cached — no login, no signup required.
Check DNS propagation → Get DNS change alerts