You update a DNS record, and it doesn't take effect everywhere at once. For a stretch of time — often minutes, sometimes up to a day or two — different people around the world can get different answers for the same domain, depending on which DNS resolver happens to answer their query. That in-between period is DNS propagation, and it's a real, structural part of how DNS works, not a bug or a delay someone forgot to fix.
Why it happens: caching, everywhere
DNS is built on caching at almost every layer, specifically so the system can handle enormous global query volume without hammering the authoritative servers for every single lookup. Your ISP's resolver caches answers. Public resolvers like Google and Cloudflare cache answers. Even your own operating system and browser cache answers. Every one of those caches holds onto the old record until its TTL (time to live) expires — and only then does it go ask the authoritative server again and pick up the new value.
TTL is why propagation time varies so much
TTL is a number, in seconds, attached to every DNS record, and it's set by whoever manages the domain. A record with a 300-second (5-minute) TTL will clear out of caches quickly. A record with a 24-hour TTL might still be serving the old answer a full day after the change, purely because a cache somewhere hasn't hit its expiry yet. This is exactly why experienced admins lower a record's TTL before a planned migration — a low TTL set a day in advance means the eventual real change propagates in minutes instead of hours, because by the time the actual change happens, every cache is already refreshing frequently.
Why “24–48 hours” is the number you'll see everywhere
It's not an arbitrary suggestion — it's a conservative upper bound that accounts for the highest TTLs still in common use, plus some slack for resolvers that don't perfectly respect TTL expiry. In practice, most changes propagate to the large majority of resolvers within a couple of hours when the previous TTL was reasonable (an hour or less). The 24–48 hour figure exists to cover the worst case, not the typical one.
What “still propagating” actually means
When a propagation check shows disagreement between resolvers, it means some of them have already picked up the new record and some are still serving a cached old one — both are “correct” from each resolver's own point of view, they're just at different points in their cache lifecycle. A resolver that's simply unreachable during the check (a timeout, not a wrong answer) is a different situation entirely — that's a network or resolver-availability issue, not evidence the change hasn't propagated, and shouldn't be read as a mismatch.
Practical advice
- Before a planned migration, lower the record's TTL a day or more ahead of time — this is the single biggest lever you have over propagation speed.
- After a change, check propagation across multiple independent resolvers rather than trusting a single lookup, since your own device or ISP resolver may simply have the old answer cached.
- If it's been well past the domain's TTL and resolvers still disagree, double-check the change was actually saved and published correctly at the authoritative nameserver — that's a more common cause of a “stuck” propagation than DNS caching itself.
- Don't panic over a single unreachable resolver in a check — confirm whether the reachable resolvers agree with each other first.
Once you've confirmed the record itself looks right with a DNS lookup, use propagation checking specifically to see how far that change has actually spread.
Check propagation status now with the DNS propagation checker — it queries 8 major public resolvers directly, in parallel.