Migrate email when you change host

Plan the move before touching DNS

Email migration to a new host is a copy of mailboxes, a change in where MX records point, and a DNS change, and each has a failure mode. The classic mistake: delete the old mailbox, then import fails, and the domain bounces every message that arrives in the gap. The safe order is the same general rule as a host migration: copy the data first, move the routing second, and only decommission the old machine when the new one is proven.

Send a heads up to users before you start, know the mail server time zone and expected hours, and have the mailbox list written down outside the panels. Email lives in places that are easy to forget: shared mailboxes, distribution lists, aliases, autoresponders, forwarding rules, filters, and webmail signatures. Write them down during planning, as they do not transfer into a new host automatically.

What moves, and what changes

Step 1: export the mailboxes

Connect to the old mail system with an IMAP client and download everything: inbox, sent, archive, drafts, spam quarantine, and empty folders. The safest copy tool is an IMAP migration tool or a desktop client that can duplicate-inbox-to-folder, but the same effect works manually: log in with an IMAP client, copy each folder to a local folder, then upload to the new server. Most hosts provide a "mail migration" assistant that imports via IMAP; it is simpler and less error-prone than hand-copying.

The command-line form, using imapsync when the hosting allows it, syncs two IMAP servers and prefers the server's own copy:

imapsync --host1 old.example --user1 [email protected] \
         --host2 new.example --user2 [email protected]

Whatever tool you use, confirm the folder names are preserved, including the subfolder hierarchy, and that attachment sizes the host allows are within the new server's limits.

Step 2: import into the new host

Create the same mailbox names on the new host first, with the same storage allowance, then configure the IMAP client to connect to the new server and upload the rendezvous copy. Do not enable "download and delete" during the copy; you want a mirror, not a drain (an aggressive "remove after download" would kill the old copy before DNS moves).

Verify with one test mailbox before doing the batch: log into the new webmail, open the imported folders, and look for the sent, drafts, and archive folders from the old domain.

Step 3: the mail-routing change

For a domain you control, the MX record for the domain controls where incoming mail is delivered. Two important behaviours:

• MX priority orders the mail servers for the domain: lower number wins, and mail falls to the next only if the first is unreachable. For a normal migration you change the single MX record, which switches the whole domain's inbound routing at once.
• SPF, DKIM and DMARC travel in DNS as well: the sending authority. If you change MX but leave SPF and DKIM pointing at the old host, incoming mail lands at the new server while outgoing mail still validates against the old records, and deliveries from the new host fail the receivers' authentication checks (a receiving server accepts when SPF, DKIM, or often the DMARC-aligned pair passes; your p= policy decides what happens when neither does).

Set the MX record during a quiet window, and keep the SPF, DKIM and DMARC setup aligned: add the new host's SPF include, generate a new DKIM selector (or copy the private key if the host reuses the same selector), and keep the DMARC policy (p=none in early days while validating).

Step 4: DNS TTL for the cutover

The MX record has a TTL (time to live) like any DNS record. Lower it to 300 seconds a day before the cutover so the change propagates in minutes, exactly as a website cutover does. If the previous MX TTL was a day, cutover mail can land at the old server for up to a day after the change.

Step 5: test the new setup, then decommission

After DNS propagates:

• Inbound: send a message from an external account and a different domain, and check it arrives in the new mailbox, not the old one.
• Outbound: send from the new mailbox to another domain and check the message lands and that headers show SPF pass, DKIM pass, and DMARC pass.
• Autoconfig and autodiscover: configure a fresh client with only the domain example.com and check autodiscover/autoconfig resolves to the new server.

Keep the old host live (retaining mail archived) for one clear-cut TTL, ideally several days, so any postbox that still resolves to the old MX has somewhere to deliver while everyone finishes the switch. Only then delete the old accounts.

When to involve a professional

A migration of under ~50 mailboxes with a clear IMAP-syncing tool is manageable by following this order. Above that, or with an active Exchange/autodiscover environment or migration between different hosting types, a migration specialist saves the week of point-fixes. Whatever the size, do not point the MX at a new host you have not first proven inbound on one mailbox.