"You have to wait for propagation, it can take up to 48 hours." It is the sentence you hear whenever a DNS change fails to produce the expected effect, and in the great majority of cases it does not describe what is happening. It describes a polite way of asking you to call back tomorrow.
DNS propagation is not a cloud slowly spreading across the world. It is something much simpler and much more predictable: it is a memory expiring.
What actually happens when you change a record
No server "receives" your change. There is no announcement and no distribution.
What there is, is this: when somebody asks where your site lives, their resolver — their provider's, or whichever they configured — asks your DNS, gets an answer, and keeps it in memory for as long as you specified. That length is the TTL, and you set it, record by record.
Until that memory expires, the resolver answers with the old value. Not because it does not know, but because it has had no reason to ask again.
So the duration of "propagation" is, for any individual user, at most the TTL you had set before the change. Not the one you set afterwards: afterwards is too late, the memory was already taken with the previous value.
The practical consequence, which is the whole story
If the TTL was 24 hours, somebody who asked a minute before your change will see the old value for nearly a full day. If it was five minutes, everybody is aligned within five minutes.
This is why, in a migration done properly, the TTLs are lowered the day before. It is not sophistication: it is the only lever you have. Lowering them after making the change achieves nothing, and it is the mistake that produces the sentence about 48 hours.
The rest of the procedure follows from this: lower the TTL, wait for the old value to expire everywhere, make the change, everybody aligns within minutes, and raise it again after a few days. It is the same reason a prepared move has no window of disruption.
The real exception: changing nameservers
There is one case in which the long wait is genuine, and it needs distinguishing.
Changing a record inside your zone — the website record, an MX, a TXT — obeys that record's TTL and nothing else.
Changing the nameservers, that is, moving the whole zone to a different operator, is another matter: that fact does not live in your zone, it lives in the extension's registry, and it has a TTL of its own, decided by the registry, typically longer and not under your control.
That is why moving to a new DNS operator happens in two steps: first rebuild the zone elsewhere identical to the current one, then change the nameservers. If the two zones are identical, it does not matter which of them answers during the wait — the answer is the same, and nobody notices anything.
How to check, instead of waiting
You do not have to take anybody's word: you look. Three things tell you everything.
The record's current TTL, visible by querying DNS, which tells you how long until the memory expires.
The authoritative answer, the one your DNS server gives directly without passing through any cache. If the value there is already the new one, the change is done: what remains is only waiting, and you know its exact length.
The answers from the large public resolvers, checkable from any DNS lookup service. If the new value shows up there, it is showing up everywhere.
With those three facts there is nothing left to guess: you know whether you changed it correctly and you know how long is left.
When "it's propagation" is the wrong answer
It is worth recognising the cases where the explanation does not hold, because they are common:
- the authoritative value is still the old one. That is not propagation: the change was not saved, or it was made in a zone that is not the active one — which happens when the domain's nameservers are different from the panel you are working in;
- the site comes back intermittently. Not propagation: that is your browser's or operating system's cache, or two records pointing at different places;
- you can see it but customers cannot, or the reverse. That is local cache: check from a different network rather than reloading fifty times;
- weeks have passed. No TTL lasts weeks. There is a configuration error there, and waiting longer will not resolve it.
In short
Propagation lasts as long as the TTL you had set before the change. That number is not a mystery: it is a value you can read at any moment, and one you could have decided the day before.
When somebody says "wait 48 hours" without having asked what your TTL was, they are not giving you a diagnosis. They are giving you a postponement.