Email Hosting Migration Checklist: Move Providers Without Losing Mail

Migrating email hosting is one of those tasks that looks straightforward until you're in the middle of it. Get the sequence wrong and you end up with mail routed to the wrong server, missing messages in the transition window, or staff unable to send or receive for hours while DNS propagates. The good news: a well-planned migration is entirely predictable. Work through this checklist and you'll move cleanly with minimal disruption.

Phase 1: Preparation (1–2 Weeks Before)

Inventory your current setup

Before touching anything, document exactly what you have:

• All email addresses and aliases hosted on the current provider
• All distribution lists and shared mailboxes
• Current MX, SPF, DKIM, and DMARC records (copy the exact values)
• Email clients in use across your team and how they're configured (IMAP/POP3 settings)
• Any external services connected to your email — CRM integrations, autoresponders, helpdesk tools, payment notifications

This inventory becomes your post-migration verification checklist. Every item on it needs to be confirmed working after cutover.

Provision accounts on the new provider

Set up all mailboxes, aliases, and shared accounts on the new platform before you cut over DNS. Log in and verify each account. Confirm you can receive a test message through the new infrastructure by sending from an external address.

Lower your MX TTL

Your current MX record likely has a TTL of 3600 or 86400 seconds. Change it to 300 (5 minutes) at least 24–48 hours before your planned cutover. This ensures the existing cached DNS records have time to expire, so that when you update the MX values, the change propagates globally in minutes rather than hours.

Phase 2: Data Migration

Export historical mail

Depending on mailbox sizes, this step can take anywhere from a few minutes to a full day. Common methods:

• IMAP-to-IMAP via a desktop client: Add both old and new accounts to Thunderbird, then drag folders from old to new. Reliable for small mailboxes. Slow for large ones.
• Provider migration tool: Many email hosts offer a built-in import tool that pulls mail directly from your old IMAP server. Check whether your new provider offers this.
• imapsync or similar: A command-line tool that synchronizes IMAP folders between two servers. Handles large mailboxes efficiently and can run across multiple accounts in parallel.

Start the data migration before the DNS cutover. By the time you flip MX records, historical email should already be in place on the new server.

Migrate contacts and calendars

If your current setup includes synced contacts or shared calendars, export these separately. Most providers support vCard (.vcf) for contacts and iCal (.ics) for calendars. Import them into the new platform before cutover.

Phase 3: Cutover

Update DNS records

This is the moment that shifts live mail flow. Replace your old MX records with the new provider's MX values. Remove the old records completely — don't leave both sets active, or incoming mail will split between two servers.

At the same time:

• Update your SPF record to authorize the new provider's sending servers
• Add the new provider's DKIM selector to your DNS
• Review your DMARC record — the policy itself usually doesn't change, but confirm the reporting address is still valid

Verify DNS propagation

After making changes, run dig MX yourdomain.com from multiple locations (or use an online propagation checker) to confirm the new MX records are visible globally. Don't assume the change is live everywhere just because it resolves from your office network.

Reconfigure email clients

Update every email client — Outlook, Apple Mail, Thunderbird, iOS, Android — with the new IMAP and SMTP server settings. If you have a team spread across multiple devices, push settings via MDM or send a clear configuration guide with step-by-step instructions. Plan to be available for support questions in the first few hours after cutover.

Phase 4: Post-Migration Verification

Send test emails from external sources

Send a test message to each migrated mailbox from an external Gmail or personal account. Confirm delivery. Then reply from each mailbox and verify the outgoing message leaves via the new SMTP server. Check the message headers to confirm it routed through the correct infrastructure.

Audit email-connected services

Work through your inventory list. Any system that sends email on your behalf — CRM, e-commerce platform, support desk, custom application — likely has SMTP credentials hard-coded somewhere. Update each one with the new server details.

Monitor for the first week

After cutover, watch delivery logs, bounce rates, and spam complaint rates closely for 5–7 days. Authentication issues often don't surface until the first few mail cycles. A spike in bounces or failed authentication results from a service you missed in your inventory is easier to catch and fix in week one than after it's been silently failing for a month.

The Most Common Things That Go Wrong

• Old MX records left in DNS: Causes mail to split between old and new servers; remove them completely during cutover
• SPF not updated: Outbound mail from the new server fails authentication because SPF still only lists the old provider
• DKIM selector not added: New provider's signing key isn't in DNS, so signed messages fail DKIM validation
• Staff not reconfigured: Some team members keep using old client settings and don't notice until sent mail bounces
• Third-party services missed: A notification system or CRM keeps trying to send through old credentials

If you're moving to MailDog for email hosting, the documentation includes specific DNS records and migration steps. Not sure which plan fits your setup? Review the pricing page or get in touch before you start — a short conversation can save hours during the actual migration.