DNS and mail cutover directs production traffic to a migrated account while preventing two independently writable copies from diverging. Prepare a record-by-record plan instead of assuming that changing one A record moves every service.
IN THIS ARTICLE
Information to have ready
Export authoritative DNS and record current TTLs, nameservers, DNSSEC settings and mail routing. Identify the final source-data cutoff and the owner of each external DNS or mail-provider account. Confirm the destination has valid certificates and tested application data.
01 Plan DNS and mail cutover after a WHM transfer
- Before the change window, lower relevant TTLs where appropriate and wait for the previous values to age out. This helps future changes but does not erase copies already cached.
- Test the destination with the real hostname and verify all important records: website A/AAAA, www, mail hostnames, MX, SPF, DKIM and service-specific entries.
- Pause application writes or complete an application-aware final synchronisation. Avoid running scheduled billing, order or notification jobs on both servers.
- Update the authoritative records or delegation according to the plan. If nameservers change, coordinate DNSSEC DS handling with the registrar and destination DNS provider.
- Set the destination’s correct local or remote mail routing. If mailboxes move, plan final message synchronisation and monitor both servers during the transition.
- Check authoritative answers and several ordinary resolver paths, then test website transactions, incoming and outgoing mail, webhooks and scheduled tasks.
- Keep the source available for the agreed period and inspect remaining requests or deliveries. Reconcile legitimate late-arriving data before removing old services.
Confirm the expected result
Traffic should converge on the destination, mail should reach the intended system and only the designated production instance should process writes. Record the final successful tests and remaining cleanup items.
Troubleshoot unexpected results
If a serious fault requires rollback, consider new writes already accepted on the destination before pointing traffic back. A DNS reversal alone does not merge databases or mail. Repair or reconcile data through the agreed application-aware procedure.
Why do some visitors still see the old server?
Resolvers, browsers and intermediary systems may retain earlier answers until their cache expires. Compare the authoritative answer and the visitor’s actual destination before making another conflicting DNS change.
Can mail keep arriving at the old server?
Yes, during a planned transition or because a sender uses cached routing. Maintain a deliberate forwarding or final-sync arrangement and verify it, rather than assuming all senders switch simultaneously.
.png)
 (1).jpg)
 (1) (1).png)
 (1).png)
.jpg)
.jpg)
 (1).jpg)
.jpg)
