The single most effective thing you can do before moving a server, mailbox or CDN origin is to lower the TTL on the records you are about to change — and to do it well in advance. TTL (time to live) is the number of seconds a resolver is allowed to cache your record. Shrink it beforehand and, when you finally flip the record, every cache in the world expires within a few minutes instead of an hour or a day.
Why "in advance" is the whole trick
Here is the point people miss: lowering the TTL only helps if you do it before the cutover, because the value that governs how long the old answer survives is the TTL that was already cached with it. Resolvers hold your record for the TTL they received at fetch time. If you drop the TTL from 3600 to 300 and change the address in the same minute, resolvers that cached the record earlier are still holding the old 3600-second copy — the new low TTL only takes effect after they refetch. You must let the old, high TTL fully drain first.
So the low TTL needs to have propagated everywhere before the change. That means lowering it at least one full old-TTL in advance, and in practice 24-48 hours to be comfortable.
Step 1 — Lower the TTL, 24 to 48 hours ahead
Find every record you plan to touch and reduce its TTL. A typical move is 3600 (one hour) down to 300 (five minutes); for a high-stakes cutover you might go to 60.
- Change the TTL only at this stage — leave the record's value exactly as it is.
- Do this for the specific records involved: the
A/AAAAfor a server move, theMXand related records for a mail move, theCNAMEfor a CDN switch. - Wait for the old TTL to elapse. If the record was at
3600, wait at least an hour; giving it a day removes all doubt and covers any resolver that clamped a longer value.
Worked example: a record currently at example.com. 3600 IN A 203.0.113.10. You edit it to example.com. 300 IN A 203.0.113.10 — same IP, shorter TTL. After roughly an hour, resolvers everywhere are caching it for only five minutes at a time.
Step 2 — Make the actual change
Once the low TTL has settled, perform the real edit. Continuing the example, you point the record at the new host: example.com. 300 IN A 198.51.100.20. Because every resolver is now on a five-minute leash, the old address can only be served for up to five more minutes anywhere in the world.
Keep the old server running during this window. A record change is bounded by TTL, but you want the previous host answering until you have confirmed the new one is receiving all traffic.
Step 3 — Verify from multiple locations
Do not trust a single lookup — your own resolver may have cached either value. Check from several vantage points:
- Use Propagation Studio to see the answer from resolvers around the world at once, and watch them converge on the new value.
- Query specific public resolvers directly. On any platform:
nslookup example.com 8.8.8.8(Google) andnslookup example.com 1.1.1.1(Cloudflare). - On macOS or Linux,
dig +short example.com @9.9.9.9(Quad9) shows just the answer; adddig example.comand read the TTL countdown in the output to confirm the new low TTL is in force. - For a single authoritative sanity check, look the record up directly against your nameserver with DNS Studio, which bypasses intermediate caches.
You will typically see most resolvers flip within a few minutes and the last few within one low-TTL window. If a location is stuck, its resolver is simply mid-cache; give it one more TTL before assuming something is wrong.
Step 4 — Raise the TTL again
Once you have confirmed the new value everywhere and the old host is drained of traffic, put the TTL back up. Running permanently at 300 multiplies the query load on your nameservers and, on some managed DNS plans, the bill. Return it to a sensible steady-state value — 3600 is a common choice, or 86400 for records that almost never change, such as a stable MX or a domain-verification TXT.
Restore the example to example.com. 3600 IN A 198.51.100.20. There is no downside to raising it now: the migration is complete and you want the caching benefit back.
A quick checklist
- T-48h to T-24h: lower TTL to
300on the target records (values unchanged). - T-0: make the real change; keep the old host live.
- T-0 to T+15m: verify convergence from multiple resolvers.
- After confirmation: raise TTL back to
3600or higher; decommission the old host.
What this does not cover
Lowering a record's TTL controls records you are authoritative for. It does not speed up a nameserver change, because the delegation's TTL lives in the parent (TLD) zone and is set by the registry, often at 24-48 hours — you cannot lower it. If your migration involves switching nameservers rather than editing records, read nameserver change vs record change and plan for the parent TTL instead. Likewise, if you are also enabling or rolling DNSSEC, factor in the DS record's own propagation at the registrar.