How long does DNS propagation take?

What sets the wait

Three things, in the order they usually bite:

1. The old record's TTL. A resolver that cached the previous answer keeps serving it for as long as the TTL it received. That is the number that bounds an ordinary record edit.
2. Whether the nameservers changed. A delegation change is resolved through the TLD zone, whose TTLs run to days, which is where the folklore figure of 24 to 48 hours comes from.
3. Resolver behaviour. Some resolvers clamp very short TTLs upward, so a 60-second TTL does not guarantee a 60-second wait everywhere.

None of these are visible from a provider panel, which is why a change can look finished to you and not to a customer.

How to plan a cutover around it

1. Lower the TTL on the records you are about to change, well before the change window.
2. Wait at least the old TTL, so resolvers have picked up the shorter one.
3. Record what named resolvers answer now — this is your before.
4. Make the change.
5. Record the same queries again, and compare. What is still unchanged is what is still cached.

Questions

How long does DNS propagation actually take?

There is no propagation event to wait for. An authoritative change is live the moment your DNS provider publishes it. What you are actually waiting on is every recursive resolver that already holds the old answer in cache, and each one keeps it until the TTL it was handed expires. So the honest upper bound is the TTL that was on the old record when a resolver last looked it up, not a fixed number of hours.

Why does everyone say 24 to 48 hours?

That figure comes from changing which nameservers a domain uses, not from editing a record. A delegation change has to be picked up through the TLD zone, whose TTLs are measured in days rather than minutes, and some resolvers hold a delegation longer still. Editing an A, MX or TXT record while the nameservers stay put is usually bounded by that record's own TTL instead, which is often an hour or less.

Can I make a change go faster once I have already made it?

No. Once resolvers have cached the old answer, nothing done at the authoritative side shortens the TTL they were already given. Speed has to be arranged beforehand: lower the TTL on the record, wait for the old TTL to expire so resolvers pick up the shorter one, and only then make the real change. After the fact the only options are waiting, and being able to show what has moved so far.

How do I know the change is actually done?

By asking named resolvers and writing down what they answered, rather than trusting a provider panel that shows intent rather than effect. Capture what a set of resolvers answer before the change, capture the same queries again afterwards, and compare the two. During the window different resolvers will legitimately disagree, and a per-resolver record shows that instead of averaging it away.

Does this tool show me the TTL?

No. It records the answers each resolver returned and compares them; it does not record the TTL attached to those answers. Read the TTL from your DNS provider's panel, or from a dig query, if you need to predict how long the wait will be. This tool is for establishing what changed, not for forecasting when it will.

Why does one online propagation checker say done and another say not yet?

Because they queried different resolvers, at different moments, from different places. That is the normal shape of a change still in flight, not a fault in either checker. It is also why a single global verdict is the least useful thing such a tool can report, and why this one keeps every resolver on its own row.