How do I move business email to a new provider without losing mail or breaking delivery?

Business Tech & Tools

How do I move business email to a new provider without losing mail or breaking delivery?

The short answer

Build the new system before you reroute incoming mail. Inventory every address and sender, create and secure the new accounts, copy historical data, test one mailbox, change the DNS records during a monitored window, and keep the old provider active until you have completed a final reconciliation.

Changing MX records changes where new incoming mail goes. It does not automatically move old messages, calendars, contacts, aliases, website forms, or services that send using your domain.

Create a migration inventory

Do not begin with DNS. Begin with this list:

  • named mailboxes.
  • aliases and forwarding addresses.
  • shared mailboxes, groups, and distribution lists.
  • calendars, contacts, tasks, and archives.
  • delegated access.
  • mobile phones and desktop apps.
  • website forms and WordPress mail.
  • store, booking, invoice, scanner, and CRM senders.
  • newsletter and transactional-email platforms.
  • SPF, DKIM, DMARC, MX, and Autodiscover records.
  • retention, legal hold, backup, and compliance requirements.

For every item, name an owner and decide whether it will be migrated, rebuilt, replaced, archived, or retired. An address that “probably is not used” still deserves a test before you delete it.

Separate the five jobs

An email move contains several migrations:

Job What changes What can be missed
Account migration Users and administrator access Licenses, recovery, delegation
Data migration Messages, folders, calendars, contacts Archives, labels, permissions, local files
Routing migration MX and related DNS Mail sent to the old provider during transition
Sending migration SPF, DKIM, DMARC, apps, forms Unauthenticated website and software mail
User migration Phones, computers, signatures, habits Old profiles continuing to send or store mail

Do not call the project finished because historical mail appeared in the new inbox. Routing and sending may still be wrong.

Use this order

1. Protect both systems

Confirm business ownership, billing, administrator access, recovery details, and multifactor authentication at the old provider, new provider, domain registrar, and DNS host. Do not cancel anything.

2. Prepare the new provider

Verify the domain without changing MX if the provider permits it. Create every required mailbox, alias, group, and shared address. Apply licenses and permissions. Configure the provider’s DKIM or other authentication setup so it will be ready at cutover.

Microsoft’s domain instructions specifically advise administrators to create users and mailboxes before updating the MX record. That principle applies regardless of destination: do not route mail to an address that has not been built.

3. Pilot one representative mailbox

Choose a mailbox with folders, contacts, calendar entries, sent mail, and perhaps delegation. Copy it using the new provider’s supported migration method.

Compare:

  • total message counts where available.
  • oldest and newest messages.
  • several folders or labels.
  • messages with attachments.
  • Sent, Drafts, and custom folders.
  • contacts and calendar events.
  • recurring meetings and shared calendars.

Different systems do not map every label, folder, permission, or calendar feature perfectly. Record what needs manual repair before moving everyone.

4. Complete the main data copy

Run the main migration while the old system remains active. Document start time, end time, errors, and skipped items. Export especially important records separately when the business cannot afford to lose them.

The destination provider’s official tool should be the starting point. Microsoft describes a cutover process in which mailboxes are migrated and verified before routing changes, followed by post-migration work and user setup. Your exact process may differ when moving from a hosted IMAP service or between cloud providers.

5. Update routing and authentication

At the planned time:

  • change MX to the new provider.
  • update SPF without creating a second SPF record.
  • publish and enable the new DKIM records.
  • preserve or adjust DMARC based on all legitimate senders.
  • update Autodiscover or provider-specific records if required.
  • update forms, devices, apps, and automations.

Lowering DNS time-to-live in advance can shorten caching for a planned change. But it does not guarantee instant universal switching and does not move any data. Record the old and new values before editing.

6. Test from outside

Test every public address from Gmail and Microsoft accounts. Reply in both directions. Check headers, aliases, shared addresses, forms, receipts, invoices, password resets, scanners, and scheduled campaigns.

Use a cutover sheet:

Test Owner Gmail result Microsoft result Fixed?
Owner mailbox inbound Owner Pass/Fail Pass/Fail
Owner mailbox outbound Owner Pass/Fail Pass/Fail
hello@ alias Owner Pass/Fail Pass/Fail
Website form Site owner Pass/Fail Pass/Fail
Receipt or invoice Operations Pass/Fail Pass/Fail

7. Run a final data pass

After routing changes, repeat the migration or reconciliation method supported by the providers to capture messages that arrived at the old system during the transition. Check both inboxes manually for stragglers.

Keep the old provider until the evidence says you are done

Do not cancel on the same day as the MX change. Keep the old service available through the overlap period permitted by your plan and risk tolerance. Before cancellation:

  • complete the final data comparison.
  • export records you must retain.
  • verify every address and application.
  • confirm users can work on all devices.
  • remove old forwarding loops.
  • document the new administrator and recovery process.
  • save final invoices and cancellation confirmation.

If the old provider immediately deletes data at cancellation, make sure your independent export can be opened before you rely on it.

Prepare a rollback decision

A rollback is not “change everything back if anyone complains.” Decide in advance which failures justify it, who can approve it, which DNS values will be restored, and how mail received in both systems will be reconciled.

Examples of serious triggers include widespread inbound failure, missing required mailboxes, an authentication rejection affecting most recipients, or migration corruption with no recoverable source. A single phone that needs its account re-added is a support issue, not a domain rollback.

Sources and further reading

If subscriber email is part of the move

The Email Marketing System can help you inventory forms, permission records, sending domains, automations, and campaign operations that ordinary mailbox migrations often miss.

For regulated records, legal holds, or large and complex migrations, use qualified IT and legal help.

A free next step

You don't have to build this alone

Bring your questions, share what you're working on, and meet other women building businesses from home. It is free to join.

Join Our Community Free

Related Questions

← All questions