How to switch email providers without losing mail

Why moves lose mail, and how to avoid it

Mail goes wherever the domain's MX record points. When you change it, other servers don't all notice at the same moment: they cache DNS answers for as long as the record's TTL says, and a server that cached the old answer keeps delivering to the old provider for a while. Mail gets lost when the old mailbox is closed too early, when nobody copies the archive, or when the new provider wasn't ready to accept mail at the moment MX changed. Each of those has a simple fix, and they are all in the steps below.

Step 1: take inventory

• Every address: personal mailboxes, role addresses (office@, invoices@), aliases and forwarding rules. Aliases and forwards are easy to forget because nobody logs into them.
• Every sender: services that send mail as your domain - invoicing, web shop, CRM, newsletter tool. They don't move, but your SPF record must keep allowing them.
• Where your DNS is managed - see how to add DNS records.
• How you'll read the old mailboxes: you need IMAP access to the old provider, which may have to be switched on, and the right kind of sign-in. Some providers require an app password, and some only allow modern (OAuth) sign-in - Microsoft 365, for example, no longer accepts basic authentication for IMAP, so you need an app or tool that supports OAuth there.
• How much mail there is, per mailbox - it decides whether dragging folders in a mail app is enough or whether a tool is worth it.

Step 2: lower the MX record's TTL in advance

The TTL (time to live) is how long other servers may cache a DNS record, in seconds. It's often an hour or more. At least one full old-TTL period before the switch - in practice a day or two ahead - lower it on the MX record to something short, such as 300 seconds:

example.com.  300  IN  MX  10 mx.old-provider.example.

Then the switch takes effect within minutes instead of hours. Some DNS panels don't let you set the TTL, or set a minimum; in that case plan for the switch to take as long as the panel's TTL. After the move you can raise it again.

Step 3: set up the new provider first

Everything except MX can be prepared while mail still flows to the old provider. Add the domain at the new provider and publish the records that don't redirect mail:

• Ownership verification (usually a TXT record) - harmless, it only proves you control the domain.
• DKIM for the new provider. It lives under its own selector name, so it doesn't interfere with the old provider's DKIM key - just make sure the selector names differ.
• SPF: for the transition, your single SPF record has to allow both providers. Add the new provider's include to the existing record rather than creating a second record.
• DMARC: keep it. If you are tightening the policy at the same time, do that after the move, once the reports show every sender passing.

example.com.  TXT  "v=spf1 include:old-provider.example include:new-provider.example ~all"

Then create the same inboxes at the new provider, with the same addresses, and set up app passwords for the copying step.

On AnyMail, once the ownership TXT record checks out you can create inboxes and app passwords and copy mail into them, even though MX still points elsewhere. Sending from AnyMail starts once all checks pass, MX included - so until the switch, keep sending from the old provider.

Step 4: copy the old mail

Option A: drag and drop in a mail app

For a handful of mailboxes this is the simplest way. Add both accounts - old and new - to a desktop mail app such as Thunderbird, Outlook or Apple Mail over IMAP, wait until the old account has downloaded its folders, then select the messages and copy them (drag with the copy modifier, or use "Copy to") into the matching folder of the new account. Do one folder at a time and compare message counts afterwards.

Option B: imapsync

For many mailboxes, or large ones, imapsync copies mail directly from one IMAP server to another, folder by folder, and can be run again later to copy only what is new. Start with --dry, which shows what would happen without copying anything:

imapsync \
  --host1 imap.old-provider.example \
  --ssl1 \
  --user1 anna@example.com \
  --passfile1 old.txt \
  --host2 imap.new-provider.example \
  --ssl2 \
  --user2 anna@example.com \
  --passfile2 new.txt \
  --dry

imapsync is free, open software (its author also sells support and an online service). Delete the password files when you're done.

Option C: an export file

Some providers offer an export of the whole mailbox as an mbox file (Google Takeout, for example). That is a good archive copy, but most mail hosts can't import it directly: you open it in a desktop mail app (in Thunderbird, for example with the ImportExportTools NG add-on) and copy it into the new account over IMAP as in option A.

Copying into AnyMail

AnyMail accepts copied mail over IMAP, with a few rules worth knowing before you start:

• Mail can be copied into Inbox, Sent, Drafts and your own folders, including nested ones such as Clients/Acme. imapsync creates the folders it needs on its own; a folder copied into Trash or the old provider's own name for Inbox, Sent or Drafts should be mapped with --f1f2 or --automap. Trash and Junk don't accept uploads - exclude them. Folder names can't contain "/", "*" or "%", and top-level folders can't reuse a built-in name (Inbox, Sent, Drafts, Trash, Junk, Spam).
• Copied messages keep their original date, and they are never re-sent or run through filter rules.
• Imported mail, attachments included, counts towards your plan's storage (5 GB on Starter and Subdomain, 25 GB on Pro and Business) and is kept for as long as you keep the message. Check the size of your old mailbox first: if it is larger than your allowance, copy only what you need and keep the rest in an archive - the export from option C is a good one. Once storage is full, further uploads are refused.
• AnyMail stores messages in a parsed form, so some original headers (such as Received or Reply-To) are not reproduced when you read the message back.

Step 5: switch the MX record

1. Replace the old provider's MX records with the new provider's. Remove every old MX record - don't leave one with a lower priority "just in case".
2. Wait for the TTL you set and send test messages from an outside account (for example Gmail) to a few addresses.
3. Check the new provider's DNS status page, or the whole domain with the email authentication checker.
4. Reconfigure mail apps on computers and phones to the new server - or, cleaner, remove the old account and add the new one.

Step 6: keep the old account for a while

Don't cancel the old service on the day of the switch. For a week or two, check the old mailboxes for messages that still arrive there (from servers with stale DNS caches, or because a forwarding rule somewhere points at the old provider). Then run a final copy - with imapsync, the same command again copies only messages that aren't there yet - and only then close the old account.

Step 7: clean up DNS

• SPF: remove the old provider's include once you no longer send through it (see SPF - the 10-lookup limit is easier to keep with fewer includes).
• DKIM: remove the old provider's DKIM record a few days after its last message went out, so mail still in transit can be verified.
• DMARC: read the reports for a couple of weeks; every legitimate source should now pass via the new provider - see DMARC.
• TTL: raise the MX record's TTL back to a normal value.

Migration checklist

1. List all addresses, aliases, forwards and services that send as the domain.
2. Confirm IMAP access to the old provider and the sign-in method it requires.
3. Lower the MX record's TTL at least a day before the switch.
4. Add the domain at the new provider: verification, DKIM, one SPF record covering both providers, DMARC.
5. Create the inboxes and app passwords at the new provider.
6. Copy old mail (mail app, imapsync or export) and compare counts per folder.
7. Switch MX, removing all old MX records; test from an outside account.
8. Move mail apps on every device to the new account.
9. Keep the old account one to two weeks, then run a final copy.
10. Clean up SPF and DKIM, check DMARC reports, raise the TTL, cancel the old service.