DNS Change Impact Checklist

Check risks before changing NS, MX or TXT records.

Changing DNS records is sensitive — it can affect site access, mail delivery and certificates all at once. A wrong NS or MX change can lose mail or take the site down for hours. This checklist walks through what to verify beforehand, grouped by area, and scores your readiness.

Run it before any DNS change: server migration, mail host change, nameserver swap, or adding a CDN.

Why lower TTL first?

TTL is how long resolvers cache a record. With a high default, stale data lingers after a change. Lowering it to 300s a day or two ahead speeds propagation and rollback. Raise it back once things are stable.

A safe cutover order

Fully set up the new server/mail and confirm direct access and send/receive.
Lower the TTL of the records you'll change.
Cut over during a low-traffic window.
Immediately test site, mail and certificate, and track the rollout with DNS Propagation Check.
Once stable, restore the original TTL.

Records to verify before and after a migration

Snapshot every record below before you move a server or nameserver, then re-verify the same items one by one after the cutover. Miss one and you get a partial outage — the site loads fine but mail dies, or only certificate issuance fails.

Record	Role	Why check it	How to check
`NS`	Delegation (which nameservers are authoritative)	Swapping nameservers changes the source of every record. The same zone must exist on old and new NS for a zero-downtime switch.	Compare the registrar NS against the authoritative answer
`A` / `AAAA`	Web server IPv4 / IPv6 address	Core of site access. Cover both `www` and the root (`@`); if you run IPv6, move `AAAA` too.	Hit the new IP directly, then track propagation
`MX`	Mail receiving host and priority	Mail often lives on a separate host, so deleting MX while moving the server silently kills all incoming mail.	Record existing MX host/priority, then test send/receive
`TXT` (SPF / DKIM / DMARC)	Mail authentication (sender trust)	Changing mail hosts changes the SPF sending IPs and DKIM selector. Miss these and mail gets spam-foldered or rejected.	Update to the new host's SPF/DKIM/DMARC values, confirm auth passes
`CNAME`	Aliases and ownership-verification records	CDN/mail-host domain verification and `www` aliases live here. Drop one and verification breaks, taking the service down.	Confirm verification CNAMEs still point at the right target
`CAA`	Restricts which CAs may issue certificates	If the new host uses a different CA but the old CAA blocks it, HTTPS certificate issuance fails.	Confirm the new issuer is in the allowed-CA list

Worked example — a server migration timeline

Here's a step-by-step run for moving example.com to a new server on a Friday evening.

D-2 (Wednesday): Lower the TTL of the A, AAAA and MX records from 86400 (24h) to 300 (5 min) and let it propagate. The TTL change itself takes the old TTL to spread, so do it early.
D-1 (Thursday): Snapshot the whole zone — A 203.0.113.10, MX 10 mail.example.com, TXT "v=spf1 include:_spf.old.com ~all", plus NS, CNAME and CAA. This is your rollback baseline.
D-Day 02:00 (low traffic): In the registrar/DNS console, change A to 198.51.100.20 and, if needed, update MX, SPF and DKIM to the new host's values.
Immediately after: Load the site on the new IP, send/receive a test mail, and check the HTTPS certificate. Use DNS Propagation Check to track the new values across resolvers.
D+1 (once stable): When everything checks out, restore the TTL to 3600–86400 to bring back normal caching efficiency.

As symptom → cause → fix: site only is down → missing A/AAAA or stale cache → hit the new IP directly and re-check propagation / mail only is down → missing MX, SPF or DKIM → update to the new host's values / certificate issuance fails → CAA blocking → add the allowed CA.

Frequently asked questions

How long does DNS propagation take?

It depends on the record's prior TTL. If you didn't lower it ahead of time, stale data can persist up to the old TTL (often 1–24h).

What order for moving mail and web together?

Fully set up the new server and mail, verify direct access and send/receive, then switch A/MX — ideally in stages.

Why check CAA records?

CAA limits which certificate authorities may issue for your domain. If you switch CA but CAA blocks it, issuance fails.

How do I back up current records before changing them?

Record every A, AAAA, MX, TXT, NS and CNAME value before the cutover. The DNS Record Lookup tool shows them all at once so you can capture a snapshot and roll back quickly if something breaks.

How do I confirm the cutover worked?

Right after switching you should compare answers across resolvers. Use the DNS Propagation Check tool to see whether the new values have spread, and verify once more against the authoritative nameserver.

Related guides

Why DNS Propagation Is Slow and How to Check ItWhy DNS changes aren't instant (TTL, caching) and how to check and speed up propagation.
DNS Record Types Explained: A, AAAA, CNAME, MX, TXT, NSWhat each DNS record type does, real value examples, and rules like CNAME restrictions — beginner-friendly.
Domain Expiry and Transfers: Process, Timelines and GotchasWhat happens when a domain expires (grace and redemption), how registrar transfers work, and staying online during one.