Email Migration Checklist: The Cutover Day Runbook

An email migration checklist needs five phases: audit one week out, drop the TTL 24 hours out, change MX records and publish DKIM at cutover, verify delivery for 48 hours, then decommission the old server in week two. Skip the audit or rush the decommission and mail disappears silently. Usually it's the mail nobody notices is missing until a client rings up asking why they were never answered.

What should you check one week before cutover?

This is the phase everyone shortens, and it's the one that shouldn't be touched. I've had clients tell me their email migration took "an afternoon" and then spend the next three weeks fielding calls about missing invoices. The afternoon was the MX change. The three weeks were them discovering what they'd forgotten to inventory.

• List every mailbox on the current system, including ones assigned to people who've left
• List every alias and forwarder separately from mailboxes, they don't migrate automatically and they break silently
• List every distribution list and shared mailbox, plus who has send-as permission on each
• Pull the current full MX record set and save it somewhere outside the DNS panel, this is your rollback
• Check your current SPF lookup count before adding a new provider's include, ten lookups is the ceiling under RFC 7208 and it's easy to blow past it without noticing
• List every third-party service that sends mail as your domain: CRM, helpdesk, invoicing tool, marketing platform, transactional email service
• Confirm each of those services has its own SPF include and, where supported, its own DKIM selector

That last point trips up more migrations than anything else. People plan for the mail server and forget that Xero, HubSpot and the support desk all authenticate against your domain independently. Run your domain through the MX record lookup tool now so you have a clean baseline, and use the email migration checker to catch aliases and forwarders you might have missed on the audit. If any of this DNS terminology is new to you, the MX record and DNS glossary entries are worth five minutes.

Why does the TTL drop happen 24 hours out, not on the day?

This is the step people either skip or leave too late, and both mistakes cost the same thing: mailboxes going dark for however long the old TTL was cached.

The mechanism is simple. Every DNS record has a time-to-live value telling resolvers how long they can cache it before checking again. If your current MX record has a TTL of 24 hours or more, a resolver that queried it yesterday will keep serving that answer for up to 24 hours, whatever you change today. Lowering the TTL only helps once the previous, longer TTL has actually expired from the resolvers holding it. Drop the TTL, then wait out the old value before you touch the MX records themselves.

• Check the current TTL on your MX record using the MX record lookup tool
• Lower the TTL to something short, five minutes is common, at least 24 hours before the planned cutover
• Confirm the new low TTL has actually propagated before you proceed, don't assume it has
• Prepare the new MX values, new SPF include, and DKIM record in advance so you're pasting, not composing, on cutover hour

What actually happens during cutover hour?

Cutover hour is short on paper and long in practice. You're not just swapping a record, you're changing three things that all have to line up: where mail routes to, what proves it's authentic, and what the sending servers are allowed to claim.

• Publish the DKIM record for the new provider before you flip MX, not after, so signed mail validates from the first message
• Update SPF to include both the old and new provider's sending ranges, not just the new one, this covers mail still queued on the old server
• Change the MX records to point at the new provider
• Leave DMARC policy as-is for now, don't tighten it during cutover, that's a week-two job once you trust the alignment reports
• Note the exact timestamp of the change, you'll need it when reading bounce logs later

If you haven't set these up before, the SPF generator, DKIM generator and DMARC generator will build syntactically correct records, which matters more than it sounds. A single malformed SPF record can invalidate the whole check under RFC 7208, and DKIM signing that doesn't verify correctly, per RFC 6376, is worse than no signature at all as far as some spam filters are concerned.

How do you verify the migration in the first 48 hours?

You're not done when the MX record saves. You're done when you've watched mail flow correctly through a full propagation cycle, which is a different thing entirely.

• Check MX propagation across multiple resolvers using the DNS propagation checker, don't trust a single lookup from your own machine
• Send a test message from an external address (Gmail, Outlook.com, something outside your infrastructure) into the new mailbox
• Send a test message from the new mailbox out to an external address and confirm it arrives and passes SPF and DKIM checks on the receiving end
• Watch the new server's bounce and rejection logs for the first day, spikes usually mean a misconfigured SPF include or a missing forwarder
• Confirm the old server is still accepting mail, it will keep receiving messages from slow-to-update resolvers for a while yet
• Check that every alias and distribution list from your week-one audit actually resolves on the new system

The old server still accepting mail isn't a failure, it's expected. Some resolvers around the world will hold the previous MX answer for a period after cutover. That's exactly why the next phase waits.

When is it safe to decommission the old mail server?

This is the only irreversible step in the whole process, which is why it belongs in week two, not day two. Once you cancel the old mailbox service or delete the old server, any mail still routing there because of a stubborn cached MX record is gone. No rollback for that.

• Confirm at least a week has passed with zero mail arriving at the old server
• Check delivery logs on the new provider for consistent volume matching pre-migration patterns
• Remove the old provider's range from your SPF record once you're confident nothing is still sending from there
• Tighten your DMARC policy now that alignment reports look clean, moving from monitor-only to enforcement
• Cancel or downgrade the old mailbox subscription only after all of the above
• Archive a final export of the old system regardless, in case you need to reference something six months from now

I had one client cancel the old provider on day three because that's when the invoice renewal fell. Convenient timing, terrible decision. They lost about ten days of forwarded mail from a distribution list nobody had tested. Don't let a billing date set your cutover pace.

How do you migrate historic email into the new mailboxes?

This is a separate job from the cutover, and it gets confused with it constantly because people assume "email migration" means one continuous process. It doesn't. Archive migration copies old mail into new mailboxes. MX cutover redirects new mail. They don't depend on each other and they don't run on the same clock.

The important distinction: historic mail is copied, not moved. The old mailbox stays intact throughout, which means you can start the copy well before cutover day, since it doesn't touch live delivery at all. For a large mailbox with years of history and attachments, the copy can genuinely run for days. Start it early and let it run in the background while you're doing the DNS work in the phases above.

• Confirm the target platform's migration tool supports your source format (IMAP, PST, or a direct provider-to-provider migration)
• Start the archive copy for large or long-tenured mailboxes as early as a week before cutover, it doesn't affect live mail
• Spot-check folder structure and dates on a sample mailbox once the copy finishes, not just message counts
• Keep the source mailbox accessible read-only until you've confirmed the copy is complete and accurate
• Don't delete anything from the old system until the archive copy has been verified by someone other than the person who ran it

If you're moving between major platforms, Microsoft's own documentation on mailbox migration is worth reading even if you're not on Exchange. The batching and throttling concepts it describes apply broadly to any large-scale copy job.

Is this the same as a website migration?

No, and conflating the two is how projects go wrong. A website migration moves files, databases and DNS records for a domain's web presence, with its own risks around redirects, indexing and search rankings. Email migration is about mailboxes, MX records and authentication. They can happen at the same time if you're switching hosts entirely, but they're independent jobs with independent rollback plans, and they should be tracked separately, not as line items on the same checklist.

If you're doing both because you're leaving a host altogether, read Site Migration Without Losing SEO: The Host-Only Plan for the website side, and treat this checklist as the entirely separate email track running in parallel. If you're still fuzzy on how domain, hosting and email relate to each other in the first place, Domain, Hosting, Email: The Basics Explained covers that groundwork. For the wider planning picture beyond this checklist, our main email migration guide walks through the reasoning behind each phase.

What goes wrong most often on migration day?

From what I've seen across a lot of these, it's rarely the MX record itself. It's the things sitting next to it.

• An alias that only the previous IT contractor knew about, discovered when a client's payment confirmation bounces
• SPF breaking because a marketing tool's sending range wasn't included, so all its emails start landing in spam
• DKIM published under the wrong selector, so it exists in DNS but nothing actually validates against it
• The old TTL not being respected because someone changed the MX before the low TTL had actually taken effect
• Nobody assigned to watch the inbox and logs during the first 48 hours, so problems get found by customers instead of the team

None of these are exotic failures. They're all things this checklist directly addresses, provided you work through it in order rather than jumping straight to the MX change because that's the part that feels like "doing the migration".

Frequently asked questions

How long does an email migration checklist like this take from start to finish?

The active DNS work in cutover hour takes minutes. The full process, from the one-week audit through to safe decommissioning, spans roughly three weeks once you include the mandatory waiting periods for propagation and confirmed stability. Archive migration can run in parallel and doesn't extend this timeline unless the source mailboxes are unusually large.

Can I skip the 24-hour TTL drop if I'm migrating on a weekend with low traffic?

Low traffic doesn't change how DNS caching works. If your current MX record has a long TTL, resolvers around the world will hold that cached answer regardless of how quiet your inbox is. Skipping the TTL drop just gives you a longer, unpredictable window where some senders reach the new server and others still reach the old one.

Do I need to update SPF, DKIM and DMARC all at once during cutover?

SPF and DKIM need to be in place at cutover, SPF listing both providers and DKIM published for the new one. DMARC is different: leave the policy as it was (ideally already in monitor mode) through cutover and only tighten it in week two once you can see clean alignment reports from the new provider.

What's the difference between an alias, a forwarder and a distribution list for migration purposes?

An alias is an alternate address delivering to an existing mailbox, a forwarder redirects incoming mail to another address entirely (sometimes outside your domain), and a distribution list fans a single address out to multiple mailboxes. All three live in configuration that's separate from the mailboxes themselves, which is exactly why they're the things forgotten during an audit and missed silently after cutover.

Final thoughts

The technical part of an email migration is genuinely simple: change a record, publish a key, wait, verify, clean up. What makes it go wrong is treating it as a single event on cutover day instead of a sequence with mandatory waiting periods built in. Work through the phases in order, don't let a billing date rush the decommission, and run the archive copy early. It costs you nothing to start it before you're ready for anything else.