Email DNS cutover during a migration

Migrating email to a new host is more fragile than migrating a website, because the mail path depends on DNS records that resolving and receiving servers interpret asynchronously. If you change the MX record before the new host is ready to accept mail, or drop SPF and DKIM before the new host is sending, mail silently routes the wrong way or bounces. The safe method is a deliberate DNS cutover: prepare records on the new host, then flip MX, SPF, and DKIM in a sequence that never leaves the domain mid-air.

Sequence the changes

Mail-flow DNS has three moving parts. The MX record decides where inbound mail goes. SPF, DKIM and DMARC authenticate outbound mail so receivers trust it. The sequence that avoids the worst outcomes is:

1. Provision the new mailboxes and server first. Create the accounts and test them internally before you touch public DNS. Confirm the new host is accepting connections on its own address.
2. Publish SPF and add DKIM on the new host, but keep the old sending path working. Both the old and new SPF entries can coexist in one SPF field while you test, and DKIM selectors are per-acceptor, so you can add the new DKIM key without touching the old.
3. Flip the MX record to the new host at the start of a low-load window, with the TTL you set earlier already short enough to be quick.
4. Verify inbound mail lands on the new host before you disable the old one. Only after inbound is proven do you retire old records so you do not lose catching mail.

NEVER flip the MX record toward a server you cannot log into and test. That is the single most common cause of a domain that "goes down" during a mail migration yet whose website looks fine.

SPF and DKIM first

Outbound authentication is where new-host mail gets rejected. When you move, the new host needs its own records in place well before you send from it. SPF authorises a list of sending IPs and hosts; because SPF uses a flat include list, list the new host alongside the old while there is any overlap, then tighten later. For example:

v=spf1 include:newhost.example include:oldhost.example ~all

DKIM is per-selector and rarely shared between hosts. Generate a fresh DKIM key on the new host, publish it under a distinct selector, and confirm the new host signs with that selector. As soon as the new host signs and receivers verify it, you can retire the old selector. DMARC (p=quarantine or p=reject, plus rua) stays the same across the move; it is the policy that tells receivers what to do when alignment fails, so keep it set and review it after the cutover. The SPF, DKIM and DMARC records article has the full syntax and the alignment rules.

Watch the cutover

After the flip, observe three surfaces rather than assuming success:

• Inbound: send a test message to the new server and confirm it lands in the new mailbox, then check a mail from the old host continues and is not being dropped.
• Outbound: send from the new server and check spam headers for DKIM pass and SPF pass; a fail or neutral means a record is still missing or the host is using the wrong selector.
• Sender score: watch the DMARC aggregate report (rua) over the following days for a jump in failures, which usually points to a sending host that still authenticates against an old record.

Keep the old host's mail routes live for a grace period equal to your longest MX / SPF TTL so mail queued before the switch still reaches its destination. Once the new host verifies at pass for DKIM and SPF and inbound delivery is confirmed on the new server, remove the old SPF include and old MX, and the migration is clean. The email migration overview ties this DNS step to the mailbox transfer, backup and cutover testing that complete the move.