The Email Migration Sequence That Prevents Lost Mail

Email migration means moving mailboxes, and the mail flow that feeds them, from one provider to another. Two separate things move, and mixing them up is where most migrations fall apart. The historic mail gets copied, usually over IMAP, from the old server to the new one. Delivery of new mail is a separate job entirely, switched over by changing your MX records. Different operations, different timelines. The gap between them is exactly where mail goes missing.

I've run this process for clients moving off cheap shared hosting mailboxes onto proper email hosting, and I've watched it done badly by agencies who treat it as "just change the DNS and hope". It isn't. It's a sequence. Skip a step, or do them in the wrong order, and someone's invoice from a supplier lands in a mailbox nobody checks any more.

What is email migration, exactly?

Strip away the jargon and an email migration plan is two workstreams running side by side. Workstream one: copy every mailbox's existing content, sent items, folders, calendars if you're doing cloud email migration properly, from the old system to the new one. Workstream two: redirect where new mail actually gets delivered, controlled entirely by MX records in DNS.

The mistake almost everyone makes is assuming these happen at the same moment. They don't, and they shouldn't. You want the historic mail fully synced and verified before you touch delivery, with enough overlap that nothing sent during the transition gets lost. Get the sequencing right and the whole thing is boring. Get it wrong and you're explaining to a client why a signed contract from a supplier sat unread on a server they'd already stopped monitoring.

What do you need to audit before you start?

Before you provision a single new mailbox, get a full inventory of what actually exists. It sounds obvious, and it's the step everyone rushes. You need:

• Every mailbox, alias, and distribution list currently in use, not just the ones people remember
• Storage size per mailbox, because "unlimited" plans on the old host sometimes hide mailboxes running into tens of gigabytes that will take real time to sync
• Current MX records and their TTL, which you can pull with a MX record lookup
• Existing SPF, DKIM, and DMARC records, since anything mid-migration has to include both old and new provider at once
• Any third-party services sending mail as your domain, invoicing tools, CRM systems, marketing platforms, all of which need including in SPF before cutover

Run this whole checklist through a proper email migration checker rather than doing it from memory. I've had clients swear they only had six mailboxes when the audit turned up eleven, including a shared support inbox nobody had thought about because it wasn't tied to a named employee.

Why does the MX record TTL matter more than any other setting?

This is the single most important number in the whole migration, and most guides bury it three paragraphs from the end or skip it entirely. The TTL, time to live, on your MX record determines how long a DNS resolver caches that record before checking again. If your current TTL is 24 hours, then after you change your MX records, servers out there that already cached the old value keep sending to your old mail server for up to a full day. That's not a rounding error. That's a day of invoices, client replies, and password resets landing on a server you may have already stopped watching. Here's the part people get backwards: lowering the TTL an hour before cutover does nothing. The old, longer TTL has to fully expire everywhere first before the new, shorter one takes effect. So the sequence is lower the TTL at least 24 hours ahead of the actual MX switch, wait for the old value to age out across the internet's resolvers, then make the real change. Do it the other way round and you've gained nothing.

Check your current TTL with a MX record lookup rather than guessing what it's set to. Once the migration is fully settled and the old server is decommissioned, raise the TTL back to something sensible, an hour or more. There's no benefit to running permanently on a five-minute TTL, and some resolvers treat unusually aggressive TTLs with suspicion.

How do you provision the new mailboxes and sync historic mail?

With the audit done and the TTL lowering already scheduled, create every mailbox on the new provider before you sync anything. Match usernames and aliases exactly to what's in the audit, because a typo here means mail gets accepted by the new server and delivered nowhere useful. Historic mail sync is almost always done over IMAP, connecting to the old mailbox and copying folder by folder into the new one. Depending on volume this can take anywhere from minutes to days, so start it well before your planned MX switch, not the morning of. Large mailboxes with years of attachments are the ones that catch people out. They look fine in a quick test, then take far longer than expected once the real sync starts on the full account.

Verify the sync properly rather than trusting a "completed" message. Spot check folder counts, check a handful of specific emails you know exist, and confirm calendars and contacts if those are part of the move. This is also the point to decide whether you're doing a straight lift and shift or using the opportunity to clean up old distribution lists and dead aliases while everything's already being touched.

When do you actually switch the MX records?

Only once the TTL has already been lowered and given time to propagate, and only once the historic sync is verified complete. Cutover itself is simple: update the MX records to point at the new provider's mail servers. Resisting the urge to do this on the same day you started the whole project is the hard part. Watch propagation with a DNS propagation checker so you can see, region by region, whether resolvers are picking up the new values yet. Because you lowered the TTL ahead of time, this should be quick, typically well under the old TTL's duration, but quick isn't instant, and some resolvers lag regardless of what TTL you set.

This is also where the parallels with a full site move are worth flagging. If you're changing hosting providers for your website at the same time as your mail, treat them as related but separate projects with their own sequencing, the same way I'd advise on a host-only migration that protects your SEO or a full WordPress migration. Bundling everything into one weekend because "it's all DNS anyway" is how migrations turn into incidents.

Why do SPF, DKIM and DMARC break during a migration?

Authentication records are where a technically clean email migration still manages to send mail straight to spam, and it's almost always one of three specific failures. SPF has a hard limit of ten DNS lookups. During a migration you need both your old provider and your new provider listed in the SPF record at once, because both are legitimately sending mail on your domain's behalf for the overlap period. Domains already sitting at seven or eight lookups from years of accumulated third-party senders tip straight over the limit and start returning a permerror, which many receiving servers treat as an outright SPF failure. Read the mechanics properly in RFC 7208 if you want the full detail, but in practice the fix is auditing what's actually in your SPF record and stripping dead entries before adding the new provider. Use a proper SPF generator rather than hand-editing a record that's already fragile.

DKIM keys are specific to both provider and selector. Your old host signs mail with its own key under its own selector, your new host signs with a completely different key under a different selector. Both need publishing in DNS during the overlap, and the old one only comes out once you're certain nothing is still signing with it, usually after the old server is fully decommissioned, not before. DKIM's signing mechanism is defined in RFC 6376 if you want to understand why mismatched selectors fail silently rather than throwing an obvious error. A DKIM generator saves you from getting the record syntax wrong at exactly the wrong moment.

DMARC set to reject is correct long-term and dangerous mid-migration. If your policy is p=reject and something in your SPF or DKIM setup is misaligned even briefly during cutover, legitimate mail gets bounced outright rather than just flagged. Dropping the policy to quarantine for the cutover window, then putting it back to reject once everything's settled and you've checked DMARC reports, is the pragmatic move. Build or adjust the record with a DMARC generator so you're not guessing at syntax under time pressure.

Will you lose mail during the switch?

Not if you do this properly, and specifically not if the old mailboxes stay accepting mail throughout the overlap period. Here's the mechanism: any sending server that still has your old MX record cached will keep delivering there, cache expiry doesn't happen instantly just because you changed a DNS record. Well-behaved mail servers also retry failed deliveries for several days if they hit a server that's rejecting connections, rather than dropping the message immediately. The real risk isn't the MX switch itself, it's decommissioning the old host too early. Shut down the old mail server the day after cutover because everything "looks fine", and you cut off delivery to anyone whose resolver hadn't yet picked up the new MX record, losing the retry window for anything that briefly failed. Keep the old server accepting mail for at least a week after cutover, longer if you're migrating a domain with high-value external senders, clients or suppliers, whose systems might have your old server cached somewhere unusual, like an old CRM integration.

When is it safe to decommission the old mail server?

Once MX propagation is confirmed complete via a DNS propagation checker, the old server has gone at least a week without receiving genuinely new mail rather than just retries, and you've confirmed the historic sync captured everything. At that point, remove the old DKIM selector from DNS, tidy the SPF record back down to just the entries you need, and raise your MX TTL back to a sensible standing value. Don't delete the old mailboxes the same day you decommission delivery. Keep read-only access for a month if the provider allows it. I've had more than one client come back three weeks after a migration asking for a specific email that turned out to still be sitting, perfectly intact, in a mailbox they thought was long gone.

Frequently asked questions

What is email domain migration versus mailbox migration?

Email domain migration is the broader move of your whole domain's mail handling from one provider to another, MX records, SPF, DKIM, DMARC, the lot. Mailbox migration is the narrower task of copying the actual mail content, folders and contacts from old mailboxes to new ones. A full email server migration involves both, done in the sequence outlined above.

How long does a typical email migration plan take?

It depends almost entirely on mailbox size and count, not on any fixed timeline. Historic mail sync for a handful of small mailboxes can finish in hours. A business with years of large attachments across dozens of accounts should plan for the sync itself to run over several days, in parallel with the pre-migration TTL lowering. Rushing the sync to hit an arbitrary deadline is the most common cause of incomplete migrations.

Can I do a cloud email migration without any downtime?

Yes, and downtime generally only happens when someone skips the TTL lowering step or switches MX before the historic sync is verified. Done properly, users keep sending and receiving throughout, since the old server keeps accepting mail right up until the overlap window closes and delivery has fully moved to the new provider.

Do I need to change my domain registrar to migrate email?

No. Email migration only involves changing DNS records, specifically MX, SPF, DKIM and DMARC, at whichever registrar or DNS provider currently hosts your domain's records. You don't need to transfer the domain itself, and doing so is a completely separate, unrelated process.

Final thoughts

Email migration isn't difficult, it's just unforgiving of the wrong order. Audit first, lower the TTL well ahead of time, sync before you switch, and keep the old server accepting mail for longer than feels necessary. Every horror story I've dealt with traces back to one of those steps being skipped or rushed, never to the technology itself being inadequate.