How to Switch Email Providers Without Losing a Single Message

Moving a domain's email to a new provider looks like an afternoon of work. The trouble usually shows up nine or ten days later, when a client mentions that an invoice bounced, or someone opens their archive and finds the folder from 2019 empty. By then the old account is closed and nobody remembers which step was skipped.

In my notes from roughly two dozen of these moves for small offices, lost mail almost always traced back to one of three things: an MX record still carrying a one day TTL on switch day, mailboxes copied once instead of twice, and an SPF record that kept pointing at the old provider long after the users had left it. None of these are hard to avoid. They just need to happen in the right order.

Why mail goes missing during a switch

When you change your MX record, the rest of the internet does not hear about it at once. Every resolver that looked up your domain recently keeps the old answer until the TTL on that record runs out. Plenty of registrars ship MX records with a TTL of 86400 seconds, which is a full day. For that day, some senders deliver to the old provider and some deliver to the new one, and both are correct from their own point of view.

That split is fine as long as the old mailbox still exists and you copy from it afterwards. The damage happens when the old account gets deleted too early. A sending server that reaches a provider where your account no longer exists gets a hard 550 rejection, and a 550 is final. The sender sees a bounce, and you never see anything at all.

There is a second, quieter cause. Mail servers that cannot connect at all will queue and retry, and RFC 5321 suggests they keep trying for at least four to five days before giving up. So a message from a badly configured server can land at your old provider almost a week after the switch, long after you stopped checking.

The one-pass import is the advice I would ignore

Most new providers offer an import tool and describe the move as a single job: enter the old server, enter a password, wait. Google Workspace calls its version the data migration service, and Microsoft 365 runs IMAP migration batches. Both work. The problem is the word single.

An import that runs once captures the mailbox as it looked when the job started. Anything that arrives at the old server during DNS propagation, or during the job itself, gets left behind. On a 9 GB mailbox the first copy took a little over six hours in my last migration, and that office received about 140 messages during that window.

What has worked better for me is two passes with imapsync, an open source tool that copies between any two IMAP servers. The first pass does the heavy lifting before cutover. The second pass, run after the MX change has settled, picks up only what is new, because imapsync skips messages it has already copied. It keeps the original dates and read flags by default, which matters more than people expect: a mailbox where every old message shows today's date is close to useless for searching.

Folder names also differ between providers. Gmail keeps sent mail in "[Gmail]/Sent Mail" while Exchange style servers use "Sent Items". The automap switch in imapsync maps the common special folders for you, so sent mail does not end up as a stray folder nobody opens.

A cutover timeline that has held up

Here is the order I follow now. The days are relative to switch day, and the gaps are there for DNS caches, not for me.

1. Day minus 3: lower the MX record TTL to 300 seconds. If the old TTL was 86400, you need at least a full day before the shorter value is what resolvers actually hold.
2. Day minus 2: create every mailbox, alias and shared address at the new provider, and add the TXT record it uses to verify domain ownership. Write down each alias, because aliases are the thing people forget exist until mail to "accounts@" disappears.
3. Day minus 1: run the first imapsync pass overnight for each mailbox. Check the log for errors on oversized messages; some providers reject single messages above 25 or 35 MB.
4. Day 0, morning: change the MX records. Update SPF to include the new provider while keeping the old include in place. Publish the new DKIM record and turn on signing.
5. Day 0, evening, and again on day 2: run the second and third imapsync passes to catch stragglers.
6. Day 7: remove the old include from SPF and raise the MX TTL back to 3600. Keep the old account open, but stop using it.
7. Day 10 or later: one last sync, then cancel the old service.

If that looks slow, compare it to the cost of explaining to a customer why their purchase order vanished.

The records and data people forget

Authentication records

DKIM uses a selector name that is specific to each provider. Google Workspace defaults to the selector google, so the record lives at google._domainkey. Microsoft 365 uses two CNAME records, selector1 and selector2. You can publish the new selector before switch day without touching the old one, since both can exist side by side.

DMARC is where a careful setup can bite you. If your domain already publishes a policy of p=reject and users start sending from the new provider before its DKIM signing is live, receiving servers will do exactly what your policy tells them and refuse the mail. Turn on signing first, send a test to an outside address, and read the headers for "dkim=pass" before anyone sends real mail. I wrote more about how these three records fit together in why email authentication records still confuse website owners.

Things IMAP does not carry

IMAP moves messages and folders. It does not move contacts, calendars, mail filters, signatures or auto replies. Export contacts as a .vcf file and calendars as .ics before you lose access, and screenshot the filter rules, because there is no standard format for those. Outlook users also need an autodiscover CNAME pointing at the new provider, or their client will keep offering the old server settings for weeks.

Phones are the last loose end. An old account profile left on a phone keeps polling a server that is about to vanish, and the user sees sync errors and assumes the new system is broken.

When the move is to your own server

Everything above applies if the destination is a server you run yourself, with one addition: you also take over the parts a provider handled quietly, such as reverse DNS, IP reputation and spam filtering. If that is the plan, read what self hosting your own email really takes before choosing the date, not after.

For the deliverability side of the switch, there is more in the email infrastructure section.

One thing to do this week

Even if the move is a month away, look up your current MX TTL today. On a Mac or Linux machine, run dig +noall +answer yourdomain.com MX and read the number in the second column. If it says 86400 or 3600, lower it to 300 now. It costs nothing, it changes nothing for your current mail, and it removes the single most common reason a provider switch drops messages.