How to Migrate Email Hosting Without Losing Messages

Migrating email hosting is one of those tasks that sounds simple but goes wrong regularly. Emails get lost between the old and new server, DNS changes cut off delivery mid-migration, or the migration completes but the new server is missing years of archived messages. Done correctly, a migration causes zero downtime and zero data loss. This guide explains exactly how to do it.

Before You Start: Plan the Migration Window

Email migrations should happen during low-traffic periods, evenings or weekends. The critical window is the time between updating your MX records and those changes propagating across the internet (typically 1–48 hours, though 4–8 hours is typical with a low TTL). During this window, some email will go to your old server and some to your new one.

Before starting, lower your MX record TTL to 300 seconds (5 minutes). Log into your DNS provider and change this at least 24–48 hours before the migration. This reduces propagation time from potentially 24 hours to 5–10 minutes when you make the final MX switch. Remember to set it back to a normal value (3600 or higher) after the migration completes.

Step 1: Set Up the New Email Hosting Account

Create your account on the new host and set up all mailboxes before touching DNS. Create the same email addresses that exist on your old host. Don't worry about passwords yet, you'll be changing them anyway. What matters is that the account structure mirrors your current setup.

Configure your new SPF, DKIM, and DMARC records in DNS, but do not change your MX records yet. You can add the DKIM TXT record and SPF record in parallel while your old MX records are still pointing to the old host, they won't conflict. Having these records ready before the switch means your email is authenticated from the first message delivered to the new server.

Step 2: Copy Existing Email via IMAP Sync

The safest way to copy existing mail from your old server to the new one is via IMAP synchronisation. IMAP sync connects to both accounts simultaneously and copies all messages, folders, and read/unread status. No messages are deleted from the source, it's a copy, not a move.

The best tool for this is imapsync (open source, runs on Linux/Mac/Windows via WSL). The command syntax is:
imapsync --host1 mail.oldhost.com --user1 you@domain.com --password1 oldpassword --host2 mail.newhost.com --user2 you@domain.com --password2 newpassword

For a GUI alternative, Thunderbird can do this: add both accounts, then drag folders from the old account to the new one. It's slower for large mailboxes but requires no command line. For Google Workspace migrations, Google provides a free migration tool under Admin > Data > Data Migration that handles this automatically.

Step 3: Update MX Records to the New Host

Once all existing mail is copied, update your MX records to point to the new host. Your new provider will give you the exact records to add. Remove the old MX records at the same time, having both old and new MX records simultaneously causes mail to route unpredictably between servers.

After updating MX records, verify propagation using our MX Checker or dig from the command line: dig MX yourdomain.com. When the new MX records appear, your new server is receiving mail. Keep your old email account active and accessible for another 48 hours to catch any mail delivered to the old server during the propagation window.

Step 4: Reconfigure Your Email Clients

Once MX records are updated, update your email client settings on all devices to point to the new server. Remove the old account configuration and add the new one. For IMAP clients (Outlook, Apple Mail, Thunderbird), you need the new incoming server (IMAP), outgoing server (SMTP), and credentials.

A common mistake is updating the client on your desktop but forgetting your phone, tablet, or a shared computer. Make a list of all devices that access business email and check each one. If a device keeps the old server configuration and the old account is eventually closed, it will throw authentication errors and stop syncing without warning.

Step 5: Run a Second IMAP Sync After MX Cutover

After your MX records have propagated and you've confirmed new mail is arriving on the new server, run imapsync (or your chosen tool) one more time. This catches any messages that arrived on the old server during the propagation window and copies them to the new server. Without this step, you could have a gap of a few hours of email that exists only on the old server.

After the second sync, send a test email from an external address and confirm it arrives on the new server. Reply from the new server and check that the reply is delivered correctly. At this point, the migration is complete.

Handling Migrations for Multiple Mailboxes

For businesses with 5+ mailboxes, coordinate the migration with all team members. Run the initial IMAP sync for all accounts before the MX cutover, then schedule the cutover during a period when staff aren't sending critical emails. Communicate the maintenance window in advance so nobody is confused when their email client prompts them to re-enter credentials.

Keep the old hosting account active for at least 30 days after the migration. Some email delivery systems (especially automated notifications from third-party services) have long retry cycles. Having the old server still accessible means nothing is lost if you missed updating a service's outbound email settings.