How to migrate email hosting without losing mail

Email migrations fail when DNS is changed before mailboxes, aliases, and authentication records are ready. Treat email as a separate service from website hosting. The MX cutover is the last step, not the first.

Phase 1: Inventory current mail

Before moving anything, document what exists:

Collect DNS records

dig MX example.com +short
dig TXT example.com +short | grep -i spf
dig TXT _dmarc.example.com +short
dig TXT default._domainkey.example.com +short
dig TXT google._domainkey.example.com +short

Save the output. Different providers use different DKIM selector names (google, default, dkim1, k1, sg, etc.).

List all mail resources

• Mailboxes (including shared/delegated mailboxes)
• Aliases and distribution groups
• Forwarders
• Catch-all settings
• Shared mailboxes
• SMTP credentials used by websites
• Auto-responders and out-of-office rules
• Email signatures and filters

Export DNS zone

From your DNS provider, export the full zone file. Store it securely — you will need it during cutover and rollback.

Phase 2: Create and verify accounts

Every mailbox and alias must exist at the new provider before any DNS changes:

1. Create all mailboxes at the new provider
2. Create all aliases and groups
3. Create all forwarders
4. Configure catch-all settings (if used)
5. Send test mail internally between new accounts
6. Send test mail from the new provider to external addresses (Gmail, Outlook)
7. Users should be able to log in and view their mailboxes

Do not rely on users to verify their own accounts. Actively test each one.

Phase 3: Sync existing mail

IMAP sync

Use provider migration tools or imapsync:

imapsync \
  --host1 imap.old-provider.com --user1 user@example.com --password1 "oldpass" \
  --host2 imap.new-provider.com --user2 user@example.com --password2 "newpass" \
  --automap --syncinternaldates

For multiple accounts, use a CSV batch:

while IFS=, read -r email oldpass newpass; do
  imapsync --host1 imap.old-provider.com --user1 "$email" --password1 "$oldpass" \
           --host2 imap.new-provider.com --user2 "$email" --password2 "$newpass" \
           --automap --syncinternaldates
done < accounts.csv

Sync strategy

Mailbox size	Strategy
< 1 GB	Single sync near cutover
1–10 GB	Initial sync days before, delta sync near cutover
> 10 GB	Initial sync a week before, delta syncs daily, final sync at cutover
Very large (> 50 GB)	Provider-assisted migration, archive older mail separately

Start the initial sync early. Large mailboxes can take hours or days over IMAP.

Phase 4: Lower DNS TTLs

Lower TTLs for MX and authentication records at least 24 hours before cutover:

• MX records → 300 seconds (5 minutes)
• TXT (SPF) records → 300 seconds
• TXT (DKIM) records → 300 seconds
• TXT (DMARC) records → 300 seconds

If your DNS provider cannot set TTLs below 600, do it as low as they allow. The goal is fast propagation and equally fast rollback.

Verify TTLs are lowered:

dig MX example.com | grep -E '^[a-z].*[0-9]+$'

Phase 5: Prepare authentication records

SPF

Add the new provider’s sending infrastructure to the SPF record. Do not remove the old provider yet:

v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:spf.new-provider.com ~all

Use ~all (softfail) during migration until everything is confirmed working. Switch to -all (hardfail) afterwards if your sending is fully authenticated.

Common SPF includes:

Provider	SPF include
Google Workspace	include:_spf.google.com
Microsoft 365	include:spf.protection.outlook.com
Zoho	include:zoho.com
ProtonMail	include:_spf.protonmail.ch
SendGrid	include:sendgrid.net
Mailgun	include:mailgun.org
Amazon SES	include:amazonses.com

Also include any website transactional email service (FluentSMTP with SendGrid, Postmark, etc.) in the SPF record.

DKIM

Add the new provider’s DKIM records. Keep old DKIM records active during the overlap period. DKIM does not interfere with delivery when multiple selectors exist.

Verify DKIM:

dig TXT google._domainkey.example.com +short
dig TXT sg._domainkey.example.com +short

DMARC

Keep DMARC at p=none during migration:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-forensic@example.com

This lets you collect delivery reports without blocking mail. Switch to p=quarantine or p=reject only after confirming DMARC alignment.

Phase 6: MX cutover

1. Change MX records to point to the new provider
2. Leave old MX records active at a lower priority (higher number) as a safety net
3. Wait for TTL to expire
4. Verify across multiple resolvers:

dig @1.1.1.1 MX example.com +short
dig @8.8.8.8 MX example.com +short
dig @9.9.9.9 MX example.com +short

5. Send test mail from Gmail, Outlook, Yahoo, and a website form
6. Check that replies route correctly
7. Monitor DMARC reports for delivery failures

Keep the old mail service active for 72 hours minimum. Some senders cache MX records beyond the TTL.

Phase 7: Update website SMTP

WordPress, contact forms, and applications often continue using old SMTP credentials after migration:

1. Update SMTP plugin settings (FluentSMTP, Post SMTP, WP Mail SMTP)
2. Test password reset emails
3. Test contact form submissions
4. Test WooCommerce order emails (use test orders)
5. Test newsletter signup confirmation emails
6. Test any CRM or booking system integrations

Common SMTP plugins to check:

wp plugin list | grep -iE 'smtp|mail'

Phase 8: Post-migration tasks

After 24 hours

• Review DMARC aggregate reports
• Check for delivery failures to major providers
• Verify all users can send and receive

After 72 hours

• Run a final IMAP delta sync
• Check old mailboxes for straggling mail
• Remove old MX records
• Update SPF to remove old provider (if no longer needed)
• Remove old DKIM records

After one week

• Schedule decommissioning of old mail service
• Verify billing for old service is cancelled or will not auto-renew
• Document DNS records, credentials, and migration notes in client records
• Set DMARC to p=quarantine or p=reject if alignment is clean

Rollback plan

If mail stops working after cutover:

1. Revert MX records to old provider values
2. Lower TTLs again if raised
3. Wait for propagation (usually minutes if TTLs were lowered)
4. Test delivery
5. Investigate what broke before retrying

A DNS rollback is fast if TTLs were lowered before the migration. If TTLs were 3600 seconds, you are waiting an hour. Plan accordingly.

Email migration is detail-oriented work. Missing one alias, one DKIM selector, or one SMTP plugin update can mean missing mail for days. Go slow, test everything, and keep the old service running until you are confident.