Email Migration Checklist: How to Switch Email Providers Without Losing a Single Message

Moving your business email from one provider to another sounds simple until you're in the middle of it. Messages not appearing in the new system. Users locked out during cutover. A misconfigured MX record that sends new mail to the old server for three days. An important email that was in flight when you switched and never arrived anywhere.

A careful email migration checklist prevents most of these problems. This guide walks through every phase — from pre-migration planning through post-cutover verification — so nothing falls through the cracks.

Phase 1: Planning and Inventory

Before touching any settings, you need a complete picture of what you're moving.

Inventory every email account

List every mailbox, alias, distribution group, and shared mailbox in your current environment. For each one, record:

• The full email address
• Current mailbox size (you'll need this for provisioning storage at the new host)
• Whether the account is actively used or dormant
• Special configurations: forwarding rules, auto-replies, vacation messages, filters

Identify all dependencies

Email rarely exists in isolation. Before migrating, check for:

• Applications that authenticate and send via SMTP — billing systems, CRMs, automated notifications
• Email-to-ticket or email-to-CRM integrations that pull from specific inboxes
• Outbound relays used by internal servers or line-of-business applications
• Email clients configured with hardcoded server hostnames

Each dependency needs to be updated during or after migration. Missing one typically results in silent failures — the application keeps appearing to send but nothing arrives.

Phase 2: Prepare the New Environment

Set up your new environment completely before starting to move anything.

Provision all accounts

Create every mailbox at the new host before migration begins. Migrating to a destination that doesn't exist yet is a common cause of messages bouncing or being lost during cutover.

Configure DNS authentication records

Set up SPF, DKIM, and DMARC for your domain at the new provider before changing MX records. Test that the new provider's DKIM key is signing outbound messages correctly. Your new host will give you the specific DNS records to add — don't assume records from your old provider carry over automatically.

Test inbound and outbound mail flow

Send test messages to the new mailboxes and reply from them. Confirm messages arrive in the correct inbox, sent messages show the correct From address, and IMAP sync works correctly in your email clients. Fix any problems here before the cutover.

Phase 3: Migrate Historical Email

Users expect their existing email to be available in the new system. The right method depends on your volume and technical setup.

IMAP-to-IMAP migration

The most common approach for migrations between standard email providers. Tools like imapsync, or migration utilities built into platforms like Google Workspace and Microsoft 365, connect to both servers simultaneously and copy messages folder by folder. This works well for mailboxes under a few gigabytes. For larger archives, budget significantly more time.

Run an initial full migration before the cutover date, then run a delta sync during the cutover window to capture messages received after the initial copy. This minimizes the chance of messages being missed during the transition. For more on how IMAP handles synchronization compared to older protocols, see our guide to IMAP vs POP3.

PST or mbox export/import

If IMAP-to-IMAP migration isn't available — for example, migrating from a legacy system that only supports POP3 or file export — you can export mailboxes to PST (Outlook) or mbox format and import at the destination. This is slower and more manual but covers systems that don't support direct server-to-server transfer.

Phase 4: DNS Cutover

Changing your MX record is the moment new mail starts flowing to the new provider. Plan this carefully.

Lower your TTL in advance

At least 48 hours before your planned cutover, lower your MX record's TTL to 300 seconds (5 minutes). When you make the change, DNS propagates quickly rather than waiting hours for a cached TTL to expire. After migration is confirmed stable, you can raise the TTL again.

Choose a low-traffic cutover window

Cut over during your quietest period — late evening or early morning works well for most businesses. Keep both the old and new servers accepting mail for at least 24 hours after the MX change, in case any senders are still using cached old DNS values.

Verify propagation from multiple locations

Use a DNS lookup tool to confirm the new MX records are resolving correctly from multiple geographic locations before telling users to update their email clients. Your own machine's local DNS cache can mislead you — check from an external tool.

Phase 5: Reconfigure Clients and Applications

After DNS cutover, update every email client and application with hardcoded server settings:

• Update IMAP and SMTP server settings in Outlook, Apple Mail, Thunderbird, and mobile clients
• Update SMTP credentials in any application that sends email programmatically
• If you use an SMTP relay, update the relay hostname and credentials in your application configuration
• Reconfigure email-to-CRM or email-to-ticket integrations with the new mailbox credentials

Phase 6: Post-Migration Verification

Don't declare the migration complete until you've verified each of the following:

1. Inbound mail to all migrated addresses is arriving at the new host
2. Outbound mail is delivering correctly and not landing in spam
3. Historical email is accessible to users in their new email client
4. SPF, DKIM, and DMARC are passing — confirm with a mail testing tool
5. Shared mailboxes, aliases, and distribution groups are routing correctly
6. All application integrations are sending and receiving as expected

Run a quiet monitoring period of 48–72 hours watching the old server's logs for any mail still being delivered there. Any late-arriving messages can be manually forwarded to the new system.

Email migration doesn't need to be chaotic if you plan each phase carefully. If you're evaluating a new home for your business email, MailDog's email hosting offers reliable IMAP access, solid infrastructure, and straightforward migration support. Check our pricing page to find a plan that fits your team size.