How to Migrate Email to a New Host
Migrate email to a new host without losing messages: create mailboxes first, copy mail over IMAP, switch DNS last, and keep the old account live.
By Matthew Zhao · Editor, Hosted EZ
To migrate email to a new host safely, follow one rule: at every step, every message and every address must exist somewhere that is still receiving. Email fails silently — a wrong record does not show an error page, it just makes mail vanish — so the order of operations matters more here than in any other part of a hosting move. This guide gives you that order.
Email usually moves alongside a website. Read our migration guide for the web half, and how to choose a web host if the destination is still undecided.
The safe order to migrate email to a new host
Inventory before you copy anything: every mailbox, alias, forwarder, autoresponder, and mailing list on the old host, plus every app or form that sends mail through it. The list catches the small dependencies that a mailbox export cannot see.
Make a short note with account names, domains, and which service currently holds mail. Do not put passwords or recovery codes in the note. You want enough detail to retrace the work without creating a new security risk.
Create the new mailboxes and run the IMAP migration
Create every address on the new host first, exactly as it exists today — a missing alias becomes a bounced message the moment DNS moves. Then copy the messages across with an IMAP migration tool, which signs in to both servers and syncs each mailbox folder by folder. Most hosts offer one in the control panel.
Run the copy while the old host still receives mail. You can re-run the sync just before cutover to pick up whatever arrived in between, the same way a website move does a final file sync.
Switch DNS last and test like a recipient
Mail routing follows your MX records, so change them only after the mailboxes exist and the messages are copied. Then keep the old host running until DNS has settled — the old account is cheap insurance for the short period when mail routes disagree.
Test by sending real messages from an outside account to each address, and reply from the new webmail or mail client. A message that arrives, and a reply that lands, answers the question a dashboard cannot.
When to stop and ask for help
Stop when the next action could overwrite mailboxes, change production mail flow, or remove access to the account. Send support the domain, time in UTC, the exact address affected, and the changes you made. Include a bounce message when you have one, but never passwords or private keys.
ICANN's registrant FAQ has useful background on how domains and their records are controlled: ICANN's registrant FAQ. Use it to understand the terms, then return to the small, reversible next step.
A sensible maintenance habit
Put the final mail setup in a short, dated note: which service holds the mailboxes, which records point there, and which apps send through what. Email problems repeat because nobody remembers where a forwarder lives or why a record has an odd value. Our email migration checklist makes a good template for the note.
Keep the change auditable
Keep a before-and-after record: each DNS record you found, its old value, the exact time you changed it, and when you expect the new answer to be visible. Mail records carry TTLs like any other DNS entry, so write down when the old route should stop being used.
Do not confuse the dashboard with delivery. A control panel can show that it accepted a record; a sender's mail server still has to find the new route and hand the message over. Test from an outside account, not from a mailbox on the same host.
If someone else finishes the move, give them the record rather than a conclusion. "Email is broken" is hard to investigate. "Messages to this address bounce since this record changed at 14:00 UTC" gives the next person a useful starting point.
One last check
Before you call the move done, send a message to every migrated address from an outside account and confirm each lands in the new mailbox — not the old one, and not spam. Check that forms and apps on your site still deliver too, since they often authenticate against the old server. A quiet confirmation now is much easier than discovering lost mail a week later.
Leave a useful handoff
Save the final test results with the date and accounts involved. Anyone revisiting the mail setup should see what moved, when, and what was verified, without reconstructing the migration from inbox archaeology.
Bottom line
You migrate email to a new host in a strict order: create every address, copy messages while the old host still receives, switch DNS last, and test from outside. Keep the old account until mail has settled, because with email the failure mode is not downtime — it is messages that quietly never arrive.
Frequently asked questions
Can I move email hosting and the website at the same time?
You can, but do not change both sets of DNS records in one sitting. Move one service, test it, and keep the previous setup until you know the result is stable.
How long does it take to migrate email to a new host?
The IMAP copy for a small account often finishes within hours, but plan the safe window in days: both hosts stay live until DNS settles and every address has been tested from outside.
What should I give support if messages go missing during the move?
Give the domain, the exact address, UTC times, and any bounce text, plus the steps already tried. That is usually enough for support to find the relevant mail logs.
Should I keep a backup before an email migration?
Yes. Export mailboxes or verify the old host's backup before touching records or accounts. Until the IMAP migration is confirmed complete, the old mailboxes are the only full copy.
About the author
Matthew Zhao
Matthew has spent his career running production server fleets — tens of thousands of machines' worth. He writes about hosting the way he wishes someone had explained it to him: plainly.
About Hosted EZ →Get the next guide in your inbox
One email when we publish something worth your time. No spam, unsubscribe whenever.
