Typical timelines by change type
Editing an existing record with a low TTL, such as pointing an A record at a new server, often propagates in a few minutes to an hour. Records with longer TTLs take proportionally longer, up to the TTL value you configured. Adding a brand new record usually appears fast because there was no old answer cached to expire.
Changing your name servers (NS records) is the slow case. That delegation is cached at the top-level domain level, frequently for 24 to 48 hours, so a registrar-level DNS host migration is the one change where the old 'up to two days' warning still genuinely applies.
How to make it faster and verify it
The single most effective trick is to lower the TTL well ahead of a planned change so resolvers hold the old value for a shorter time. Do this a day in advance, make the change, confirm it, then raise the TTL back up. During a name server migration, keep identical records on both the old and new hosts so visitors get a correct answer no matter which one they reach.
Rather than guessing whether you have waited long enough, check the record from many places at once. If nearly every location returns the new value, you are essentially done; if the results are still split, you are inside the TTL window and should wait a little longer.
A quick TTL reference with concrete examples
TTL is the ceiling on how long a change can lag, so it maps directly to timelines. A 300-second (5-minute) TTL means the slowest resolver serves the old value for at most five minutes after you edit. A 3600-second (1-hour) TTL stretches that to an hour, and a 86400-second (24-hour) TTL, common on records people rarely touch, can hold the old answer for a full day.
A practical migration schedule looks like this: 24 hours before the cutover, drop the record's TTL to 300 seconds and let that low value itself propagate. At cutover, change the record; most locations pick it up within five to ten minutes. Once you have confirmed the new value worldwide, raise the TTL back to an hour or more to reduce load on your name servers.
Why a change sometimes outlasts its TTL
Occasionally a resolver keeps serving an old answer well past the TTL you set. The usual cause is that the resolver only saw the low TTL after it had already cached the record at the old, higher value; caches honor the TTL that was in effect when they fetched, not the one you set afterward. This is exactly why lowering TTL must happen before the change, with enough lead time for the old high-TTL copies to expire first.
Other culprits include forwarders that ignore or clamp TTLs, corporate resolvers with minimum caching floors, and a stale copy of the record still sitting on a secondary name server whose SOA serial never advanced. If most of the world has updated but one network is stuck, it is almost always a caching quirk on that network, not something you can fix from your zone.
Timelines record by record
A and AAAA records: usually minutes to an hour with a low TTL, since browsers request them constantly and caches turn over quickly. CNAME records behave the same way. MX records for an email cutover typically settle within a few hours, though a few slow senders may use the old servers until their cache expires.
TXT records such as SPF, DKIM, and DMARC propagate on their TTL like any other record, but verification services sometimes cache a failed or empty lookup, so allow extra time before retrying. NS records are the outlier: because the delegation is cached at the TLD, a name server change can realistically take 24 to 48 hours to be visible everywhere.