Migrating Email Accounts to a New Host Without Losing Mail

Moving your website to a new host is the easy part these days — copy the files, import the database, update DNS, done. Email is where things go wrong. Get the sequence wrong and you can lose two or three days of incoming mail while messages bounce or vanish into an inbox nobody's checking anymore. Here's how to move mailboxes to SkyServer (or any new host) without dropping a single message.

Why Email Migration Is Riskier Than a Website Move

A website has one canonical copy of its files and database at any given time. Email doesn't work that way during a migration — for a window of hours (sometimes days, depending on DNS TTL and how slow some ISPs are to refresh their resolvers), some senders will deliver to your old server and some will deliver to the new one. If you haven't set things up so both are catching mail correctly, messages sent to the "wrong" server during that window either bounce or sit in a mailbox nobody's checking.

The other risk is simpler: people just forget that mailboxes hold years of history. Moving the MX record is trivial. Moving the actual messages that were already sitting in those mailboxes is the part that takes planning.

Step 1: Set Up the New Mailboxes First — Before Touching DNS

Don't change any DNS record until the destination is ready to receive mail. In cPanel on the new server:

• Go to Email Accounts and recreate every mailbox with the same username (e.g. sales@yourdomain.com) and a fresh password.
• Set matching quotas so nothing gets rejected for being "full" the moment mail starts arriving.
• If you use forwarders or autoresponders, recreate those too — they don't come over automatically.

At this point the new mailboxes exist but are empty, and MX still points at the old server. Nothing is live yet — that's intentional.

Step 2: Copy the Existing Messages Over (imapsync)

The cleanest way to move message history between two IMAP servers is imapsync. It connects to both mailboxes at once and copies messages directly, skipping anything already present if you need to re-run it — which matters because you'll run it more than once.

From a machine with SSH access to either server (or a small VPS), run one sync per mailbox:

imapsync --host1 mail.oldhost.com --user1 'sales@yourdomain.com' --password1 'oldpass' \
         --host2 mail.newhost.com --user2 'sales@yourdomain.com' --password2 'newpass' \
         --ssl1 --ssl2

If imapsync isn't installed, most Debian/Ubuntu VPS boxes get it with apt install imapsync. On the old cPanel server, IMAP is usually on port 993 over SSL — confirm with your old host if the connection fails.

For a handful of mailboxes, a desktop client works too: add both accounts (old and new) in Thunderbird as IMAP, then drag-and-drop the folders from old to new. It's slower and more manual, but fine for 2-3 accounts.

Step 3: Lower the MX TTL Before You Touch Anything

A day or two before the actual cutover, log into DNS for the domain and drop the TTL on the MX record to something short — 300 seconds (5 minutes) is typical. This doesn't change where mail goes yet; it just tells every resolver on the internet "don't cache this answer for long," so when you do flip MX later, the change actually takes effect quickly instead of lingering at the old value for whatever the previous TTL was (often 3600 or 86400 seconds).

Skip this step and you can end up in a situation where the cutover looks instant on your end but some mail servers keep sending to the old host for the better part of a day.

Step 4: Run a Final Sync, Then Cut Over MX

Right before the cutover:

1. Run imapsync one more time per mailbox to grab anything that arrived since Step 2. This catch-up run is usually quick since most messages already match.
2. Update the MX record(s) to point at the new server.
3. Update SPF to include the new server's sending IP or hostname — if you skip this, legitimate mail sent from the new server can get flagged as spoofed by recipients checking SPF.
4. Update or regenerate DKIM for the new server, and make sure the DKIM public key published in DNS matches what the new mail server is actually signing with.
5. Leave DMARC alone if it's already set to a reporting policy — just confirm alignment still passes once SPF/DKIM are updated.

Because of the shortened TTL from Step 3, most resolvers pick up the new MX within minutes, though a small percentage of mail servers cache more aggressively than they should and may take a few hours regardless.

Step 5: Keep the Old Server Alive for a Grace Period

Don't cancel the old hosting account the moment DNS changes. For at least 5-7 days:

• Leave the old mailboxes active and reachable so any mail still trickling in via stale MX records isn't rejected outright.
• Run imapsync once more at the end of the grace period to pull in that trailing mail.
• Check the old server's mail queue (exim -bp on a cPanel/Exim box) for anything stuck, and check bounce logs for delivery failures during the transition window.

This is the step people skip because the new setup "looks fine," and it's the one that quietly loses the odd message from a slow-to-update recipient's DNS cache.

Common Mistakes That Cause Lost Mail

Prevention: Build the Runbook Once, Reuse It

If you manage several domains or expect to migrate hosts again down the line, write the steps above into a short runbook with your actual mailbox list, DNS provider login, and imapsync command template filled in. Migrations that go wrong are almost always ones done from memory under time pressure — a checklist turns a 3-hour anxious process into a 45-minute routine one.

Frequently Asked Questions

Will I lose emails during the MX cutover window?

Not if you follow the sequence above. The risk isn't the cutover moment itself — it's mail addressed to the old server after you've stopped checking it, or mail sent to the new server before mailboxes existed there. Keeping the old server alive for a grace period and syncing before and after cutover closes both gaps.

Do I need imapsync, or can I just forward mail from the old server?

Forwarding only moves new incoming mail — it does nothing for messages already sitting in old mailboxes. If mailbox history matters (it usually does), you need an actual sync tool like imapsync or a manual client-based copy.

How long should I wait before shutting down the old email server?

At least 5-7 days after the MX change, longer if you know some recipients or sending systems cache DNS aggressively. Check the old server's mail queue and logs before cancelling anything.

Do webmail bookmarks and mail client settings need to change?

Yes. Update webmail URLs, and update IMAP/SMTP server hostnames and ports in every desktop and mobile mail client once the new server is confirmed working, ideally after the grace period rather than immediately.

What if my domain uses Google Workspace or Microsoft 365 instead of hosting-based email?

This guide is specifically for cPanel/hosting-based mailboxes. If your mail runs on Workspace or 365, you're not migrating mailboxes at all when you move web hosting — just leave MX pointed at Google/Microsoft and only move the website's A/CNAME records.