DNS TTL Before a Domain Move: A Simple Plan

Moving a domain, switching hosts or changing nameservers requires both correct configuration and a plan for cached answers. The panel change can take seconds. Caches on the public internet can still serve the old answer until TTL (time to live) expires. Plan the TTL first; then make the move.

This is a cutover checklist — not a full explainer of what propagation is. For the cache model, see what is DNS propagation. To decode A/MX/NS lines during checks, use how to read DNS lookup results.

Check public record values with FindMyIP’s DNS Lookup. It queries through the site’s server resolver and does not display ordinary record TTLs or compare the resolvers used by different visitors. If you are unsure which DNS host is in charge, confirm NS and cross-check registration with WHOIS Lookup.

What you are actually planning

A domain move usually means one or more of:

New A / AAAA targets (new host or CDN)
New MX (mail provider change)
New NS (moving DNS from registrar to Cloudflare, Route 53, etc.)
Or a registrar transfer while DNS stays put (TTL still matters for any record you change afterward)

TTL is the dial that decides how long resolvers may keep the old answer after you save the new one. High TTL (for example 86400) is fine for a quiet week. It is painful on move day.

The timeline that usually works

Treat this as a working default for a planned cutover — not a law.

48–72 hours before

Confirm the right panel. Look up NS for the apex. Edit records only where those nameservers live. Wrong panel = “nothing propagates.”
Snapshot current values. Note current A/AAAA, MX, NS, and key TXT (SPF/DKIM/DMARC). Screenshot or copy them. You want a rollback map.
Lower TTL on records you will change. Common targets: apex and www A/AAAA; MX if mail moves; sometimes related CNAME. For a nameserver move, check the registrar and registry’s delegation behavior: lowering an NS TTL inside the old zone does not necessarily lower the parent delegation TTL.
Aim for something like 300 seconds (5 minutes) for the change window — unless your DNS host forces a higher minimum.
Save and wait. You need the old high TTL to expire once before cutover. If yesterday’s A still had TTL 86400, lowering to 300 today does not help until that day-long cache dies. That is why you lower early.

Move day

Recheck TTL with the right method. Confirm the configured TTL in your DNS provider’s panel and use a query tool that returns TTL from explicitly selected resolvers. FindMyIP’s DNS Lookup does not display ordinary record TTLs. An SOA negative-cache field is not the TTL of the A or MX record being moved.
Prepare the destination before switching. Validate the new host, certificate plan and mail configuration. For a DNS-host move, populate the new zone and check its authoritative answers before changing delegation; coordinate any DNSSEC changes with the providers.
Make the authoritative change in the correct panel (or switch NS at the registrar when that is the move).
Verify record values and the service. Query the authoritative server and selected recursive resolvers, recording which answered and when. Visiting FindMyIP from a phone hotspot still uses the site’s server-side lookup; it does not reliably compare the phone’s resolver with your home resolver. Then test the website or mail delivery itself.
Hold the low TTL until the new answers look stable everywhere you care about.

After the dust settles (often 24–48 hours)

Raise TTL again on stable records (for example 3600 or 86400) so everyday DNS is quieter. Leaving everything at 300 forever is fine for tiny sites; it is noisier at scale.

Which records to lower (and which to leave alone)

Lower when you will change them soon:

A / AAAA for the hostnames users hit (example.com, www, app subdomains)
MX (and plan TXT/SPF updates in the same window if mail moves)
CNAME that point traffic at the old stack

Be careful with:

NS — parent delegation and child-zone records have separate caching. Prepare the new zone first and consult the registrar’s nameserver process; lowering a child-zone NS TTL alone cannot control all delegation caches. Cloudflare’s nameserver troubleshooting illustrates the distinction and DNSSEC pitfalls.
TXT proofs — do not delete ownership tokens until the new side is validated.
Unrelated subdomains — if shop. is not moving, do not thrash its TTL “just because.”

You do not need to lower every record in the zone. Lower the ones that will point somewhere new.

Domain move vs “only hosting” vs “only mail”

Hosting / CDN IP change: focus on A/AAAA (and CDN CNAMEs). Mail can stay put.

Mail provider change: MX + SPF/DKIM/DMARC TXT. Web A records can stay. Lower MX TTL ahead the same way.

DNS host change (new NS): two-step thinking — (1) get records correct at the new DNS host before you flip NS, (2) flip NS at the registrar, (3) wait out old NS caches. WHOIS/registrar NS and live DNS NS should eventually agree; use WHOIS for the registration side and DNS Lookup for what resolvers see.

Registrar transfer only: TTL planning matters less until you change records. Still confirm NS so you know which panel is live after the transfer completes.

Verification checklist (use it twice)

Query apex and www separately if both matter.
Confirm NS still matches the host you edited (or the new host after an NS move).
Confirm A/AAAA match the new targets.
Confirm MX if mail was in scope.
Explicitly query a second recursive resolver and note its identity; a different device can use the same resolver, and a web lookup may run remotely.
If answers look alien, decode types with the DNS record guide — then re-read propagation timing if only some networks updated.

Do not treat a browser HTTPS error as proof DNS failed. Certificates can break after DNS already points at the new IP. Get the address right first; fix TLS second.

Common cutover mistakes

Lowering TTL the morning of the move. Too late if the previous TTL was a day.
Editing registrar DNS while NS points at Cloudflare (or the reverse).
Changing only www and forgetting the apex (or the opposite).
Moving web and mail in the same panicked minute without separate checks.
No rollback snapshot — when something breaks, you need the old values instantly.
Raising TTL again before the new answers are widespread — you just glued a bad or mixed state into long caches.

Privacy note (short)

Planning TTL is operational hygiene for a domain you control. Public lookups show how that domain is configured, not your personal browsing history. Use DNS Lookup for its record values, your provider for configured TTLs, and a tool that selects resolvers and returns TTLs for cache comparisons. Cloudflare’s TTL reference explains provider-specific limits; RFC 2308 defines negative caching.

Keep a record of the change

Before a domain or host move: confirm the real DNS panel, snapshot current records, lower TTL early enough for the previous TTL to expire, wait out the old high TTL, cut over, verify with repeated lookups, then raise TTL when the new map is stable. Timing beats hope. Pair this plan with DNS propagation basics when caches disagree, and with the record-by-record guide when a line looks wrong.

How we research and correct articles