How to Move Email When Switching Hosts (Without Losing Mail)

Published October 19, 2026

Everyone plans the website migration. Almost nobody plans the email migration — until messages start vanishing. Email is the piece that breaks silently: no error page, no warning, just mail that never arrives.

How email routing works (the 30-second version)

When someone emails you@yourdomain.com, their mail server looks up your domain’s MX records — DNS entries that say “deliver mail for this domain to this server.” Change hosts, and those MX records need to point at the new server. During the switch, there’s a window where some mail goes to the old server and some to the new one. Your job is to make that window harmless.

One important exception: if your email runs through Google Workspace or Microsoft 365, your MX records already point to Google/Microsoft — not your web host. Moving web hosts doesn’t touch your email at all. Skip this guide and go enjoy your day.

The same applies to any third-party email provider (ProtonMail, Fastmail, Zoho): if your MX records point to them, a web host move changes nothing about email. The only thing to verify is that your SPF record still authorizes any sending services you use (contact forms via the web host, newsletters via Mailchimp, etc.) — those sending paths may change even when MX doesn’t.

Reconfiguring email clients after the move

After the cutover, every device and mail client needs the new server settings:

1. Update incoming (IMAP) and outgoing (SMTP) server hostnames to the new host’s values.
2. Confirm the ports and encryption: IMAP port 993 with SSL, SMTP port 465 (SSL) or 587 (STARTTLS).
3. Re-enter passwords — they don’t transfer between hosts.
4. On phones, delete and re-add the account rather than editing in place; edited accounts are the #1 source of “mail works on my laptop but not my phone” mysteries.

Do this for every device before you need it — discovering your phone can’t send mail during a client emergency is avoidable.

Forwarders and aliases: the hidden inventory

Beyond mailboxes, check for:

• Forwarders (sales@ → you@gmail.com): recreate each one on the new host, and verify the destination addresses are still correct — forwarders accumulate stale destinations over the years.
• Autoresponders (vacation replies, “we received your message” confirmations): these don’t transfer; note their text and recreate them.
• Mailing lists (rare on shared hosting, but check): list software configurations need manual migration.
• Catch-all addresses: if the old host had a catch-all (receiving mail to any address at the domain), decide deliberately whether to recreate it — catch-alls collect enormous spam volumes, and a migration is a good moment to drop one.

Document all of these in your Step 1 inventory. The mailbox list is the obvious part; forwarders and autoresponders are what people discover broken weeks later.

Step 1: Inventory every mailbox

List every email account on the old host: info@, support@, individual names, forwarders, aliases. Check the old control panel’s email section — there are always forgotten accounts (that jobs@ address from 2021 still getting resumes). Miss one and it stops working the day you cancel the old host.

Step 2: Create the accounts on the new host first

Before changing any DNS, recreate every mailbox on the new host with the same addresses and new passwords. Set the same quotas if you had custom ones. This way, when mail starts arriving at the new server, there’s somewhere for it to land.

Step 3: Copy old mail to the new server

Your old emails don’t move automatically. Options:

• IMAP drag-and-drop: connect both accounts in a mail client (Thunderbird works well), then drag folders from old to new. Slow but reliable, and you see exactly what transferred.
• Host migration tools: some hosts offer email migration — ask support before assuming.
• IMAP sync tools (imapsync and similar): faster for large mailboxes, slightly technical.

Do this before flipping MX records so the historical mail is already in place when new mail starts arriving.

Thunderbird walkthrough (the reliable manual method):

1. Install Thunderbird and add the old account (IMAP, with old server settings).
2. Add the new account (IMAP, with new server settings).
3. Let both fully sync — this can take a while for large mailboxes.
4. Select all folders in the old account, right-click → Copy To → the corresponding folder in the new account.
5. Verify message counts match on a few key folders before deleting anything.

For mailboxes over a few gigabytes, do it overnight. Don’t delete the old account from Thunderbird until you’ve confirmed the new one has everything.

Troubleshooting the usual problems

Mail goes to spam after the move. Your SPF record doesn’t authorize the new server, or DKIM isn’t set up. Check both DNS records character by character — one typo breaks authentication silently. Re-test with mail-tester.com after fixing.

Some mail still arrives at the old server days later. Normal during propagation. Some senders’ DNS caches are slow. This is why the old host stays alive for a week — check it daily and forward anything that lands there.

“I updated MX but mail bounces.” The new mailboxes don’t exist yet, or the MX values have a typo. Verify the mailboxes in the new control panel first, then re-check the MX records against the host’s documentation.

Sent mail works, received mail doesn’t (or vice versa). These are separate paths — MX controls incoming, SPF/DKIM and SMTP settings control outgoing. Debug them independently instead of assuming one fix covers both.

Step 4: Update MX records — and SPF, DKIM, DMARC

When you’re ready to cut over:

1. Point your MX records at the new host (get the exact values from the new host’s docs — they’re usually something like mx1.newhost.com).
2. Update your SPF record to authorize the new server to send mail for your domain. Skip this and your outgoing mail starts landing in spam folders.
3. Set up DKIM on the new host and publish the DKIM DNS record. Another anti-spam authentication layer — increasingly required.
4. Check your DMARC policy still aligns with the new setup.

SPF and DKIM are the steps everyone forgets. Your mail will arrive fine without them — it’ll just go straight to spam. Test by sending to a Gmail address and checking it doesn’t land in spam.

Step 5: Test sending and receiving

Send test emails both ways: from the new account to an external address, and from an external address to the new account. Check webmail and your mail client. Verify SPF/DKIM pass using a tool like mail-tester.com.

Step 6: Keep the old host alive for at least a week

DNS propagation means some senders will keep delivering to the old server for 24–48 hours. Keep the old mailboxes active and check them (or set up forwarding to the new addresses) for a full week after the switch. Then — and only then — cancel.

The propagation-gap trap

Here’s what actually loses mail: you cancel the old host on Monday, but a sender’s DNS cache still points at the old MX until Wednesday. Their mail bounces because the old server is gone. The fix is boring and effective — overlap. Two hosts running simultaneously for a week costs a few dollars and loses zero mail.

Email migration isn’t technically hard. It’s just a checklist that punishes skipping steps. Follow it in order and nobody loses a message.