Moving your email to a new provider without losing messages

Mail is more forgiving than people expect. A sending server that cannot deliver does not usually give up — it queues the message and retries, often for several days, before returning it to the sender. That retry behaviour is what makes this safe to do, and misunderstanding it is what makes people panic halfway through and change things back.

What is not forgiving is a domain whose MX records point at a server that accepts mail and then has nowhere to put it. That does not bounce and it does not queue. It accepts, and then the message exists nowhere. Nearly every genuine loss during a migration is some version of that.

Step one, days before: lower the TTL

Your MX records have a TTL telling other servers how long they may cache them — often 3600 seconds or more. While that cache is warm, some senders will keep delivering to your old provider no matter what you change.

So before anything else, set the TTL on the MX records to 300 and leave the values alone. Then wait for the old TTL to elapse — if it was an hour, wait an hour. After that, every resolver in the world is holding a copy that expires in five minutes, and the cutover later becomes near-instant instead of all-day.

The number before IN MX is the remaining TTL, counting down. Run it twice a few minutes apart and you will see it fall. When it stabilises at 300, step one is done.

Step two: build the destination completely, first

Before a single MX record changes, the new provider must be fully ready to receive. That means:

1. The domain is added and verified at the new provider.
2. Every mailbox and alias exists — including the ones you have forgotten, which is the whole problem.
3. A catch-all is enabled if the provider offers one, at least for the transition.
4. SPF and DKIM for the new provider are published, so mail you send from it is trusted on day one.

The forgotten addresses are the real risk. info@, hello@, accounts@, noreply@, the one on an old invoice template, the one a supplier has in their system, the one printed on a van. Before migrating, look in the old provider's logs or the last few months of received mail and list every address that actually got something. A catch-all covers the rest, which is the single cheapest piece of insurance in this whole process.

Do not delete anything at the old provider yet. For the next week it is the only copy of your mail history, and it is also where late-delivered messages will keep arriving.

Step three: copy the old mail across

Existing messages do not move with the domain. They sit in the old provider's storage, and getting them into the new mailbox is a separate job — usually an IMAP migration tool offered by the new provider, which logs into both and copies folder by folder.

Run this before the cutover, not after. It can take hours for a large mailbox, and running it while mail is still arriving at the old provider means you can run it again afterwards to pick up the stragglers. Most tools are incremental and will skip what they already copied.

If the old provider has already been cancelled and you cannot log in, this step is gone. That is the one genuinely unrecoverable mistake available here, and it is why the old account stays open and paid until the end.

Step four: the cutover

Now change the MX records. Replace them rather than adding to them — leaving the old provider's records alongside the new ones means mail arrives at whichever has the lower priority number, and some of it ends up in a mailbox nobody is reading.

Then update SPF in the same sitting. If SPF still names only the old provider, mail you send from the new one fails authentication from the first message, which is the worst possible first impression for a freshly migrated domain.

Send yourself a test from an outside address — a personal Gmail works — and confirm it arrives in the new mailbox. Then send one *from* the new mailbox to that Gmail, open it, and choose "Show original" to check that SPF and DKIM pass. Two minutes, and it catches almost everything.

The week afterwards

Keep the old account alive for a week or two. Mail will still trickle in, from senders whose own systems cached your old records or who were queueing and retrying. Check it every day or two and forward anything real.

Watch for one specific thing: a sender who reports a bounce you cannot explain. That usually means a mailbox you forgot, and a bounce is a gift — it means the message was refused rather than silently accepted and discarded.

Once a fortnight passes with nothing new arriving at the old provider, run the IMAP copy one final time, confirm the new mailbox has everything, and only then cancel. If you also published DMARC as part of the move, leave it at p=none through this period — tightening it while two providers are sending as you is how legitimate mail gets filtered. The upgrade path is in moving DMARC to quarantine.

If you are moving the domain too

Changing registrar and changing mail provider at the same time is the version of this that goes wrong. A transfer can change which nameservers are authoritative, which can reset your DNS records entirely — including the MX records you just carefully configured.

Do them separately, mail first, with at least a week between. And before transferring, record every DNS record you have, because "the registrar had a copy" is not a recovery plan.