Moving Business Email to a New Provider Without Losing Mail

Whether you are leaving shared hosting mailboxes for Google Workspace, consolidating onto Microsoft 365, or moving the other way, an email migration worries people for good reason: email is where contracts, invoices and customer conversations live, and nobody wants a gap in it. The reassuring part is that email is built to tolerate change. Sending servers queue and retry, and DNS lets you switch over in a controlled way. With a plan, you can move without losing a single message.

Understand the three things that move

1. Mail flow: where new incoming mail is delivered. Controlled by your MX records.
2. Mailbox data: existing emails, folders, contacts and calendars, copied from old to new.
3. Sending authentication: SPF, DKIM and DMARC, which must authorise the new provider's servers.

Treating these as separate tasks, each with its own check, is what keeps the migration under control.

Phase 1: Plan and inventory

• List every mailbox, alias, group and shared mailbox, plus any forwarding rules. Aliases and distribution lists are the most commonly forgotten items.
• Note mailbox sizes. Large mailboxes take longer to copy, and some old servers throttle connections.
• List everything that sends mail through your current provider: copiers, website forms, accounting systems, applications using SMTP credentials. Each will need new settings.
• Record your current DNS. Look up your MX, SPF, DKIM and DMARC records with the DNS lookup tool and save the results.
• Pick a cutover time, ideally the start of a quiet period, with someone available for the following day or two.

Phase 2: Prepare the new provider

1. Add and verify your domain with the new provider. Verification is usually a TXT record and does not affect mail flow.
2. Create every user, alias, group and shared mailbox exactly as in your inventory.
3. Lower the TTL of your MX records to 300 seconds at least a day before cutover, so the switch takes effect quickly and can be reversed quickly if needed.
4. Add the new provider to SPF now, alongside the old one, for example v=spf1 include:old-host.example include:_spf.google.com ~all. Both can send during the transition.
5. Publish the new provider's DKIM record using its own selector. It will not clash with the old provider's, because each uses a different selector name.
6. Update MTA-STS first, if your domain publishes it: add the new provider's MX hosts to the policy file and change the id, so senders with a cached enforce policy will accept the new servers.

Phase 3: Copy existing mail

The usual approach is a pre-stage and delta migration: copy the bulk of each mailbox before cutover, then run a final incremental pass afterwards to pick up anything that arrived late.

• Built-in migration tools. Google Workspace and Microsoft 365 both provide tools to import mail from IMAP servers and from each other. These are the first choice for most businesses.
• IMAP synchronisation tools. Open-source tools such as imapsync copy mail between any two IMAP servers, preserving folders and read status, and can be re-run to copy only new messages.
• Export and import (PST or MBOX). A last resort for a few mailboxes, because it is manual and error-prone.

Contacts and calendars often need a separate export and import step, depending on the old system. Check this per user rather than assuming the mail tool copies them.

Phase 4: Switch the MX records

At your chosen time, replace the old MX records with the new provider's values exactly as documented. Remove the old ones entirely; leaving them in place splits incoming mail between the two systems.

Before:  example.com.  MX  10 mx.old-host.example.
After:   example.com.  MX  1  smtp.google.com.

Because you lowered the TTL, most senders will use the new records within minutes. Some will take longer, depending on how their resolvers cache, which is why the next phase matters. Watch the change spread with the DNS propagation checker.

Phase 5: The overlap period

• Keep the old mailboxes running for at least several days after cutover. Any server that still has the old MX cached will deliver there.
• Run the final delta sync a day or two after cutover, and again before closing the old service, to bring across anything that arrived at the old system.
• Reconfigure devices. Set up phones and desktop mail apps for the new provider, and update copiers, applications and website forms with new SMTP settings, typically port 587 or 465 with authentication.
• Test in both directions from external accounts, including attachments and shared mailboxes.

Phase 6: Finish the authentication changes

1. Enable DKIM signing at the new provider once its record is live, and confirm dkim=pass with your domain in a sent message's headers.
2. Remove the old provider from SPF once nothing sends through it any more.
3. Remove the old DKIM record after a week or two.
4. Review DMARC reports for any system still sending through the old provider or failing alignment.
5. Remove the old MX hosts from your MTA-STS policy, if you publish one, and change its id.

The SPF, DKIM and DMARC checker confirms the final state.

Phase 7: Decommission

Once the final sync is complete and users confirm their mail, folders and contacts are present, close the old service. Before cancelling, download an archive of the old mailboxes if your retention policy requires it, and restore your MX TTL to a normal value such as 3600.

Common problems

• Mail split between old and new: old MX records left in place, or the TTL was not lowered and caches are still expiring.
• Outbound mail marked as spam after cutover: SPF or DKIM not updated for the new provider.
• Missing aliases: mail to an address that existed only as an alias on the old system bounces. Check your inventory.
• A device stops scanning to email: it still uses the old SMTP server and credentials.

Key takeaways

• Treat mail flow, mailbox data and sending authentication as three separate tasks.
• Prepare the new provider, lower the MX TTL and add it to SPF before cutover.
• Pre-stage mailbox copies, switch MX, then run a final delta sync while the old system stays online.
• Clean up SPF and DKIM only after nothing sends through the old provider.