A DNS migration checklist that goes beyond propagation maps

Inventory more than the website address

A DNS move can leave the homepage working while breaking mail or a verification flow. Before changing nameservers, export the current zone and identify the records used by the website, mail, certificate issuance and third-party services. Keep a timestamped copy and a rollback plan. Do not publish the full zone export if it reveals private operational names.

List the apex and www records, MX records, SPF policy, DKIM selectors, DMARC policy, CAA restrictions and any TXT verification records. Some provider features, such as proxying or flattened records, are not represented identically by every DNS host. Understand the destination provider's treatment before recreating the records.

Separate authoritative data from cached answers

An authoritative nameserver describes the zone it serves. A recursive resolver may still return a previously cached answer until that entry expires. Comparing the two can explain a mismatch without guessing that the whole internet has changed at once. Reducing TTL shortly before a move does not retroactively shorten an answer already cached with a longer TTL.

Use the DNS lookup tool to inspect record types and the DNS resolver comparison to compare the tested resolvers with authoritative answers. That comparison reports the resolvers actually queried. It is not a survey of every country, ISP or customer network.

Validate the destination before the cutover

Install the correct virtual host and TLS configuration first. Test the new origin using an authorized method that preserves the intended hostname and TLS server name. Confirm that the application has the right canonical URL, can connect to its database and accepts authentication callbacks on the new hostname.

For a domain behind a reverse proxy, distinguish the publicly presented address from the origin address. Check that the origin's firewall policy allows the intended proxy traffic. Keep administrative services private, and avoid leaving a temporary debug endpoint publicly exposed after testing.

Verify mail separately

Re-run the email DNS checker after the move. It can review published DNS signals, but it does not prove that a message reaches an inbox. DKIM also depends on the selector and sender's actual signing configuration. Send an authorized test message and inspect its authentication results through the receiving mailbox or provider delivery logs.

Do not create multiple independent SPF policy records at the same name. Preserve all authorized sending services in the applicable policy. A new website deployment should not overwrite mail records belonging to another service.

Observe the change through completion

Keep the old infrastructure available for a planned overlap when possible. Watch HTTP content, TLS validity and the DNS records rather than only an A-record value. Note the time of the cutover and compare errors with that timeline. If the intended answers are published but a customer still reports a failure, investigate their resolver, cached redirect, IPv6 path and local connection before repeating the migration.

The DNS problem guide explains common response states. A useful migration record ends with observed results and remaining uncertainty, not only “DNS updated.”