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
- Microsoft: Connect a domain by adding DNS records
- Microsoft: What to know about a cutover email migration
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.
Related Questions
- Why can I send business email but not receive it, or receive it but not send it?
- Why are ordinary messages from my business email going to spam?
- Which business email provider should I choose: Google Workspace, Microsoft 365, or another option?
- How do I create a professional business email address on my own domain?
