DNS propagation is not a broadcast. Nothing is being pushed out to the world and there is no queue to watch. What actually happens is that resolvers all over the internet hold cached copies of your old record, and each one releases it when its own copy expires.
That single fact explains everything people find confusing about it: why some visitors see the new site and others do not, why it cannot be forced, and why the delay was decided before you made the change.
The TTL that mattered was the old one
Every record carries a TTL, how long a resolver may keep it before asking again. A typical value is 14400 seconds, four hours.
When you change a record, resolvers that already cached the old value keep serving it for the remainder of that period. The old TTL governs how long the change takes, not the new one.
This is why lowering the TTL at the same moment as the change does nothing. The resolvers you are waiting for cached the old record with the old TTL and have not asked again yet.
Lower it a day early, and this stops being a problem
Before a planned change. A migration, a nameserver switch, a mail move: lower the TTL to 300 seconds a day in advance.
Resolvers pick up the short TTL over the following hours. Then when you make the real change, it spreads in five minutes rather than four hours, and if you got it wrong, the correction is equally fast.
Raise the TTL back afterwards. A permanently short TTL means more queries against your nameservers for no benefit once the change has settled.
This costs nothing and it is the single most useful DNS habit there is.
How long it actually takes
For a record change with a normal TTL: most resolvers within a few hours, effectively everyone within 24.
For a nameserver change: longer, because it involves the registry rather than only your zone, and those records carry their own long TTLs. Allow 24 to 48 hours.
The old figure of "up to 72 hours" is conservative and dates from a period of longer default TTLs. It is still the safe thing to tell a client, because promising four hours and taking twelve generates a support conversation.
Checking progress honestly
Compare two public resolvers:
dig @8.8.8.8 example.com dig @1.1.1.1 example.com
If they agree on the new value, propagation is largely done. If they disagree, it is still in progress and there is nothing to fix.
Do not use your browser to judge this. Browser cache, operating system cache and your network's resolver all sit between you and the truth, which is why the person doing the migration is usually the last to see it working.
Flush your own caches before concluding anything:
# macOS sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder # Windows ipconfig /flushdns
Or simply check from a phone on mobile data, which uses a completely different resolver.
What you cannot do
You cannot force propagation. There is no button, and services claiming to accelerate it cannot affect caches they do not control.
Flushing your own cache only affects you. Clearing a public resolver's cache, some offer a form for this, affects that one resolver and nobody else.
The only real control you have is the TTL, and it has to be set in advance.
Working through the window
During propagation, some visitors reach the old server and some the new one. Plan for that rather than hoping it is brief.
Keep the old server running for at least a week after a migration. Orders and form submissions arriving during the window may land there, and you want to be able to retrieve them.
Avoid changes on both sides. If content is being edited on the old site while some visitors are on the new one, you end up with two divergent copies and no clean way to merge them.
Expect mail to split. Messages may be delivered to either server. Check the old mailboxes before shutting anything down. This is where mail genuinely gets lost.
Moving an existing WordPress site walks through testing the new server with a hosts file entry before DNS is touched at all, which removes most of this risk.
When it is not propagation
After 48 hours, stop calling it propagation and check the change actually exists.
dig NS example.com
If the nameservers are not yours, the change was never made at the registrar, or it was made on a domain you were not looking at. Editing records on a server the domain does not point at is the most common wasted hour in DNS work.
If the nameservers are right but the record is wrong, look at the whole zone. A leftover duplicate record for the same name produces unpredictable answers that look like propagation and are not. The DNS troubleshooting guide explains the rest.
The number that actually governs how long this takes has to be changed before the change, not during it. Understanding TTL and When to Lower It walks through the sequence.
Cached records are also what keeps a domain alive if its DNS provider stops answering. Secondary DNS and What Happens When DNS Fails goes into that failure and what redundancy actually requires.