You changed a DNS record. Some people see the new site, some still see the old one, and every guide you find says to wait 24 to 48 hours.
That number is folklore. DNS propagation is not a fixed waiting period and never was. It is governed by a value published in the records themselves, and once you know how to read it you can say exactly how much longer you have to wait.
There is no propagation, only caching
Nothing is pushed anywhere when you change a DNS record. There is no network-wide update, no queue, no synchronisation job. The change happens instantly and in exactly one place: your authoritative nameservers.
What creates the delay is that almost nobody asks your nameservers directly. When someone visits your site, their computer asks a recursive resolver — their ISP's, or a public one like Google's 8.8.8.8 or Cloudflare's 1.1.1.1. That resolver asks your nameservers once, keeps the answer in memory, and serves that stored copy to everyone else who asks.
So a resolver that looked up your domain five minutes before you made the change is still holding the old answer. It will keep serving it until its copy expires. "Propagation" is just the wait for thousands of independent caches to expire on their own schedules.
This distinction matters because it tells you what you can and cannot influence. You cannot push a change out faster. You can only control how long the copies are allowed to live — and you have to do that before you make the change.
TTL is the number that actually matters
Every DNS record carries a time to live: the number of seconds a resolver is permitted to cache it. A record with a TTL of 3600 may be held for one hour. A record with a TTL of 86400 may be held for a full day.
When a resolver's copy expires, it asks your nameservers again and gets the new value. That is the entire mechanism.
So the honest answer to "how long will propagation take" is: at most the TTL that was on the old record when the resolver cached it. Not the TTL on the new record — the old one. The resolver made its decision about how long to hold the answer at the moment it stored it, and lowering the TTL afterwards has no effect on a copy that is already sitting in memory.
This is the single most common misunderstanding about DNS changes. Lowering the TTL after you have made the change does nothing for anyone already holding a stale copy.
How to read the time remaining
Run your domain through the DNS Checker and look at the TTL column in the transcript. Every resolver reports the seconds remaining on its own cached copy, counting down in real time.
A resolver showing A 240 203.0.113.10 has four minutes left before it discards that answer and asks again. One showing A 79112 has nearly a day.
That is not an estimate. It is the resolver telling you precisely how long it intends to keep serving what it has. Refresh the check a minute later and the number will have dropped by roughly sixty.
Because the tool queries four independent resolvers separately, you can also see the shape of the rollout: three resolvers on the new address and one on the old one means the change is most of the way through, and the remaining TTL tells you when the last one catches up.
The right way to plan a change
The preparation happens a day early, and it is the step that makes the difference between a migration nobody notices and one that drags on for two days.
Twenty-four to forty-eight hours before the change, lower the TTL on the records you are about to modify — to 300 seconds, or 60 if your provider allows it. Then wait. You are waiting for every resolver holding the old long TTL to expire and re-fetch, picking up the short TTL as it does. Until that has happened, the short value is not doing anything for you.
When you make the actual change, resolvers are now holding copies that expire in five minutes rather than a day. The change is visible almost everywhere within that window.
A day or two after, once you are confident the new configuration is correct, put the TTL back up. Long TTLs are good for normal operation: they reduce load on your nameservers, make lookups faster for repeat visitors, and give you a buffer if your DNS provider has an outage.
If you have already made the change without lowering the TTL first, there is nothing to be done except wait out the old value. You cannot flush a third-party resolver's cache, and no service that claims to "force propagation" can either.
Why some resolvers take longer than the TTL
Two behaviours can stretch the wait past what the TTL suggests.
Some ISPs override TTLs. A resolver is supposed to honour the value your nameservers publish, but some ISP resolvers clamp very short TTLs to a minimum of their own, or hold records well beyond expiry to reduce their own traffic. There is nothing you can do about this, and it is worth knowing when a single user insists the site is still broken hours after everyone else has moved on.
Then there is the local cache on the user's own machine. Operating systems and browsers keep their own DNS caches, independent of any resolver. Someone reporting a stale result may simply need to restart their browser. Chrome keeps a cache at chrome://net-internals/#dns that is separate from the operating system's, which is why a page can be stale in one browser and fine in another on the same computer.
When it is not propagation at all
Before assuming you are waiting on caches, rule out the changes that genuinely take longer or that never resolve on their own.
Nameserver changes are slower, because the delegation lives in the parent zone rather than yours. The TTL on .com nameserver records is 48 hours, and you do not control it. This is the one case where the traditional advice is roughly accurate — see how to change nameservers without downtime for the sequence that avoids an outage.
Editing DNS at the wrong provider produces a change that never propagates, because nothing is reading it. If the NS records in your DNS check do not match the provider whose control panel you have been editing, your edits are going nowhere. That is not a waiting problem.
Geographic and load-balanced DNS answers differently by design. If resolvers disagree permanently and you have not changed anything, the domain is probably behind a CDN that returns a nearby address to each querier. No amount of waiting will make those answers converge, because they are not supposed to.
The short version
Look up the TTL on the old record. That is your maximum wait, and it is counting down where you can see it. Lower TTLs a day before a planned change, not after. And if resolvers still disagree long after the TTL has expired, stop waiting and start checking whether you edited DNS in the place the internet is actually reading from.