DNS change checklist

Why DNS changes need a checklist

A DNS change can take a website or an entire mail flow offline, and the effects can persist after you correct the mistake because resolvers cache answers for the time the record's TTL allows. Unlike a code deployment, there is rarely a single switch to flip back. A short checklist reduces the risk, and it is most valuable for changes to MX, SPF, DMARC, NS and DNSSEC records, where an error affects every user of the domain.

Before you change anything

Start by recording the current state, so that there is a known good state to return to.

1. Export or copy the whole zone, or at least the records you will touch, with their TTLs.
2. Note which provider hosts the zone, and confirm that the NS records at the registrar match it.
3. Write down what you intend to change, and what a correct result will look like.
4. Check who else depends on the record: mail services, verification records, third-party tools.
5. Pick a time with people available to react, and avoid changing right before a weekend or launch.

Lower the TTL first

The TTL (time to live) controls how long resolvers may keep an answer. If a record has a TTL of 86400 seconds and you change it, some resolvers may serve the old value for up to a day. To make a change that you may need to reverse, lower the TTL well before the change, at least as long as the old TTL, so that caches have already shrunk. After the change is proven, you can raise it again.

Be aware that this guide cannot tell you the exact delay: resolvers vary, and some hold answers longer than they should. Propagation is not a single global event, and a check against one resolver does not describe all of them.

Make one change at a time

Make a single logical change, verify it, then move on. Combining several changes makes it hard to know which one caused a problem. Some specific points apply to common record types.

• A and AAAA: confirm the new address serves the site before switching, including HTTPS for the hostname.
• MX: add the new mail host with a lower priority first, confirm it accepts mail, then move priority. Remember that removing the old host too early loses mail still being delivered.
• SPF: you may have only one SPF record per name, and it must stay within ten DNS lookups. Edit the existing record instead of adding a second.
• DMARC and DKIM: publish DKIM keys before you start signing with them, and move DMARC policy in steps from none to quarantine to reject.
• NS and DNSSEC: these are the highest risk. A mismatch between the DS record at the parent and the keys in your zone can make the domain fail for validating resolvers.

Verify after the change

Check against the authoritative nameservers first, since they show what you published without caching. Then check public resolvers, which show what users will see as caches expire.

1. Query the authoritative servers directly for the changed record.
2. Query at least two public resolvers and compare the answers and the remaining TTL.
3. Use the matching tool, such as the MX lookup, SPF checker or DMARC checker, to read the record as a receiver would.
4. Test the actual service: load the site, send a test message, run a mail-flow test.
5. Check again after the old TTL has fully elapsed, since late cache expiry can reveal a problem.

Know your rollback before you start

A rollback is simply restoring the record or records you saved at the start, with their original values. Decide in advance the signal that triggers it, such as failed test mail or errors from the site, and who decides. If the change involved lowering the TTL, the rollback will take effect in the shorter time you prepared for.

Some changes are not cleanly reversible. If you remove a DS record or change nameservers, partial caches may hold either state for a while. For those, plan an extra margin and avoid doing them without a tested plan.

After the change

Raise the TTL back to a sensible value once the change has been stable. Keep a note of what changed, when, and why, ideally with the before and after values. Remove temporary records you added for the change. Then run an assessment again so that you have a fresh baseline for the next time.

A worked example: moving a mail provider

Suppose you are moving inbound mail from an old provider to a new one. The risk is that mail sent during the transition lands on a server that no longer reads it. A careful sequence limits that risk.

First, lower the TTL on the MX records a day or more ahead. Second, confirm that the new provider is ready and configured to accept mail for the domain, and send a test message directly to its server. Third, add the new MX host with a priority number that makes it the second choice, so that the old host still takes the mail. Fourth, update SPF so that it includes the new provider's sending sources, keeping within the ten-lookup limit, and publish the DKIM key the new provider gives you.

Then switch the priorities so that the new host is preferred, test again, and leave the old host in place until a full cycle of the old TTL has passed and the old mailbox has stopped receiving new messages. Only then remove the old MX entry and tidy up the SPF include. Throughout, keep the saved copy of the original zone, so that the earlier state can be restored if something fails.

Common mistakes

A few errors account for a large share of DNS incidents.

• Editing a record in the wrong zone or on a provider that is no longer authoritative.
• Adding a second SPF record instead of editing the first.
• Forgetting a trailing dot in a fully qualified name, so the zone appends its own name.
• Pointing a CNAME at the zone apex, which is not permitted alongside other records.
• Removing the old mail host before mail in flight has been delivered.
• Declaring a change done after checking only one resolver.

Frequently asked questions

Written by DNS Tools editorial · Last updated 2026-10-09