The most repeated figure in DNS is that changes take 24 to 48 hours to propagate. For ordinary record edits this is a myth. The real upper bound on how long an old value can linger is the record's TTL — the time-to-live you set on it, in seconds. Understanding when the 24-48 hour figure applies, and when it does not, is the difference between a five-minute cutover and a day of needless anxiety.
TTL is the true upper bound
When a resolver fetches a record from your authoritative nameserver, it caches the answer for the length of the TTL and serves it from memory until that timer expires. It does not check back early. So if your A record has a TTL of 3600, a resolver that cached the old value one second before your change will keep serving it for up to 3600 seconds — one hour — and no longer.
This gives you a clean mental model. The worst case for any single resolver is one full TTL. The worst case across the whole internet is also roughly one TTL, because every resolver's cache was populated at some point within the last TTL window and will expire within the next one. A record with TTL 300 is effectively global within five minutes of the change; a record with TTL 86400 can show stale answers for a full day.
Record changes: A, AAAA, TXT, MX, CNAME
Edits to the records that live inside your own zone — the ones your nameserver is authoritative for — are bounded entirely by that record's TTL:
- A / AAAA (IPv4 / IPv6 addresses): bounded by the record TTL. Lower it to
300before a server move and the cutover is near-instant. - TXT (SPF, DKIM, domain verification): same rule. A verification
TXTwith a short TTL is visible to the checking service within minutes. - MX: bounded by TTL, but remember sending servers retry for hours or days, so mail is rarely lost even if some servers briefly use the old route.
- CNAME: bounded by TTL, though the resolver must then also resolve the target, which has its own TTL. See CNAME Studio for how aliases chain.
None of these touch the 24-48 hour figure unless you deliberately set a very long TTL. If you edited a record and it "still hasn't propagated", check what TTL was on the old value before you changed it — that is the number that governs how long stale answers survive, not the TTL of the new one.
Nameserver and registrar changes: the real 24-48 hours
The 24-48 hour rule is real, but only for delegation changes — repointing your domain to a different set of nameservers at the registrar. The record that says "ask these nameservers for this domain" does not live in your zone. It lives in the parent zone: the TLD's nameservers (for example the .com servers operated by Verisign). You do not control that NS record's TTL — the registry does.
TLD NS delegations commonly carry a TTL of 172800 seconds (48 hours), and the glue records that publish the nameservers' IP addresses often sit at 86400 (24 hours). When you switch nameservers, resolvers that cached the old delegation keep asking the old nameservers until the parent TTL expires. That is genuinely outside your control, which is exactly why nameserver migrations need days of headroom while a simple A record change needs minutes. Our companion article on nameserver change vs record change covers this in detail.
Why some locations lag behind others
During propagation you will see a mix of old and new answers depending on which resolver each location queries. This is not a fault — it is thousands of independent caches expiring on their own schedules. A resolver in one country may have cached your record 50 minutes ago while one in another cached it 5 minutes ago; with a one-hour TTL they will flip to the new value 45 minutes apart. Checking from multiple vantage points, as Propagation Studio and DNS Studio do, shows you this spread directly rather than guessing.
CDN, anycast and load-balanced nuances
Two things complicate the tidy TTL story:
- Very short TTLs from CDNs. Providers like Cloudflare, Fastly and AWS often serve records with TTLs of
30to60seconds so they can steer traffic. Propagation for these is almost immediate, but it also means the answer legitimately changes minute to minute — do not mistake normal geo-steering for a stale cache. - Anycast means one record, many machines. With anycast a single IP is announced from dozens of locations. The DNS record propagates on TTL as usual, but the actual server you reach depends on network routing (BGP), which can shift independently of DNS. So the record can be fully propagated while different users still land on different physical nodes.
- Ignored TTLs. A minority of resolvers clamp TTLs — enforcing a minimum (say 30 seconds) or a maximum (capping long TTLs). This is uncommon but explains occasional answers that update sooner or later than your TTL predicts.
A realistic timeline to expect
- Record edit with a low TTL (300 or less): global within a few minutes.
- Record edit with a default TTL (3600): most resolvers within an hour, essentially all within one TTL.
- Record edit where the old value had a long TTL (86400): up to a full day for the last stragglers.
- Nameserver / registrar delegation change: plan for 24-48 hours because the parent zone TTL governs it.
The practical takeaway: propagation time is something you largely choose in advance by setting your TTL. Lower it before a planned change, verify from several locations, and the wait shrinks from "a day or two" to "a coffee break".