See how far your change has spread right now
Free, no sign-up — results in seconds.
Typical timings
| Change | Typical wait | What controls it |
|---|---|---|
| Edit an existing A, AAAA, CNAME, MX or TXT record | Minutes up to the old TTL | The TTL on the record before you changed it |
| Add a brand-new record or subdomain | Usually minutes | Negative-caching time in the SOA record, if anyone looked it up before it existed |
| Change nameservers at the registrar | Several hours, occasionally up to 48 hours | The TTL of the delegation NS records at the registry, plus registrar processing time |
| Register a new domain | Minutes to a few hours | Registry publishing schedule and registrar processing |
The often-quoted “24 to 48 hours” is a safe upper bound that covers slow nameserver changes and resolvers that ignore short TTLs. Most record edits are visible to most people much sooner.
Why it sometimes takes longer
- A long TTL on the old record. A TTL of 86,400 means a resolver that refreshed just before your change may keep the old value for a full day.
- Resolvers with minimum cache times. Some ISPs cache for longer than your TTL.
- Local caching. Your operating system, browser and home router all keep their own small caches.
- The records weren't recreated after a nameserver change. This isn't slow propagation — the new provider simply has no record to give out. Always copy your full zone before switching. Our All DNS Records lookup lets you export the existing records first.
- DNSSEC mismatch. If DNSSEC was enabled at the old provider and the DS record wasn't removed or updated, validating resolvers will fail to resolve the domain entirely after the move. That looks like “still propagating” but never fixes itself.
How to check how long you still have to wait
Look up the record at a resolver that still has the old value and note the TTL in the answer — that's the number of seconds left before that resolver's copy expires. With dig:
dig @8.8.8.8 example.co.za A +noall +answerThe second column of the answer is the remaining TTL in seconds.
Making the next change faster
Lower the TTL to 300 seconds a day or two before a planned change, wait for the old TTL to expire, make the change, then raise the TTL again once everything is confirmed. See what is DNS propagation for the reasoning behind this.
Frequently asked questions
Is 48 hours always the maximum?
It's a practical upper bound, not a rule. A record with a very long TTL, or a resolver that ignores TTLs, can hold an old answer longer, but that is rare.
Why did my nameserver change take longer than a record change?
Nameserver changes go through your registrar and the registry, and the delegation NS records carry their own TTL, often a day or more. Record changes only depend on your own record's TTL.
Does a low TTL slow my website down?
Barely. It means resolvers ask your nameservers more often, which adds a few milliseconds for some visitors. A TTL of 300 to 3,600 seconds is a sensible balance.