KoltrixMoving Off Microsoft 365: An Email Migration Plan
A step-by-step plan for moving a domain's email off Microsoft 365: inventory, exporting mailboxes, DNS records to change, coexistence, and what to check after.
On this page(7 sections)
Leaving Microsoft 365 is less about email and more about everything that grew around it: shared mailboxes, distribution lists, Teams, OneDrive links in old threads, and an Outlook profile on every laptop. A clean move starts by listing all of it.
This plan covers moving a domain's mail from Exchange Online to another provider. It's written for small teams who manage their own DNS and don't have a dedicated IT department. Microsoft's admin tools change their names and menus from time to time, so check current Microsoft documentation for exact steps; the order of operations below is what matters.
Phase 1: Inventory everything
Before you export a single message, write down what exists. Microsoft 365 tenants accumulate more than people expect.
| Item | Where to find it | Decision to make |
|---|---|---|
| User mailboxes | Admin center, active users | Move, archive, or close |
| Shared mailboxes | Admin center, shared mailboxes | Recreate as shared mailboxes or aliases |
| Distribution lists and Microsoft 365 Groups | Admin center, groups | Recreate, merge, or retire |
| Aliases on each mailbox | Each user's email addresses | Recreate on the new provider |
| Mail flow rules | Exchange admin center | Rebuild what's still needed |
| Apps sending as your domain | SPF record, DMARC reports, app settings | Reconfigure for the new provider |
| Teams, OneDrive, SharePoint | Their own admin areas | Keep, replace, or export separately |
That last row deserves a pause. If your team relies on Teams for chat and SharePoint for files, moving email alone means keeping a Microsoft subscription for those services anyway. That may still be the right call, but price it in before committing.
Also read our guide to inventorying everything that sends as your domain. Invoicing tools, CRMs and scanners that relay through Exchange are the most common things to break silently.
Phase 2: Decide what happens to old mail
You have three realistic options for existing mailboxes:
- Import into the new provider. Many providers offer an importer that connects to Exchange or reads exported files.
- Export and archive. Keep PST files somewhere safe and searchable, and start fresh in the new system.
- Keep the old tenant read-only for a period, on the smallest license that preserves access, then export before cancelling.
Exporting to PST is the common route for small teams. Outlook for Windows has an export function for mailbox data, and administrators can use Microsoft Purview's content search and export tools to pull mailboxes without logging in as each user. Do this while your licenses are still active; once a subscription lapses, access to data is time-limited.
If you're moving to Koltrix specifically, know this up front: there's no mailbox importer in v1. Pulling old mail across over IMAP is planned for the release after launch. Until then, plan on option 2 or 3, and keep the archive somewhere your team can search when they need an old thread. Our post on what to do with the old mailbox after you migrate covers the options.
Phase 3: Prepare the new provider
With Microsoft still receiving mail, set up the destination:
- Add and verify your domain on the new provider.
- Create every mailbox, shared mailbox and alias from your inventory.
- Publish DKIM for the new provider. DKIM records use their own selectors, so they can live alongside Microsoft's
selector1andselector2records without conflict. - Update SPF to include both providers during the transition. Microsoft's include is
spf.protection.outlook.com; add the new provider's mechanism next to it, and watch the ten-lookup limit. - Send test messages from the new provider to Gmail, Outlook.com and a colleague's account, and check that SPF, DKIM and DMARC pass in the headers. A header analyzer makes that quicker.
Phase 4: Cut over
Pick a quiet morning, not a Friday afternoon.
- A day or more ahead, lower the MX record's TTL to something short like 300 seconds.
- Change the MX records from Microsoft's (they typically end in
mail.protection.outlook.com) to the new provider's. - Update or remove the Autodiscover record. Microsoft 365 setups usually have an
autodiscoverCNAME pointing at Microsoft. Left in place, it can make Outlook keep trying to connect to the old tenant. Point it where the new provider says, or remove it if they don't use one. - Leave the Microsoft mailboxes active so mail delivered by servers with cached DNS still lands somewhere you can read.
- Watch both inboxes for the next day or two. Mail will taper off on the Microsoft side as caches expire.
The order of steps is very close to what we describe in the Google Workspace cut-over checklist, which is worth reading even if Google isn't involved.
Phase 5: The client question
This is where Microsoft migrations differ most from others. Many Microsoft 365 users live in desktop Outlook, and their habits, folders, rules and signatures are part of the experience.
- If your new provider supports IMAP or Exchange-compatible protocols, people can keep using Outlook with a new account profile.
- If it's web-only, they'll be learning a new interface. Koltrix, for instance, is a web app that installs to your phone's home screen, with no IMAP access in v1. For a team that depends on desktop Outlook, that's a reason to wait or choose a provider with IMAP support today.
Either way, set expectations before cut-over day. Recreate signatures, explain where rules and folders went, and remove old Outlook profiles once people are settled so nobody keeps reading a stale cache.
Phase 6: Clean up
A week or two after cut-over:
- Remove Microsoft's SPF include once no mail is sent through Exchange
- Remove Microsoft's DKIM CNAMEs after you've disabled DKIM signing in the tenant
- Check DMARC aggregate reports for any source still failing authentication
- Confirm every shared address on your inventory receives mail
- Export remaining mailboxes and confirm the archive opens
- Reduce or cancel licenses, keeping in mind any Teams or SharePoint dependencies
- Raise the MX TTL back to a normal value
Key takeaways
- Inventory mailboxes, shared mailboxes, groups, aliases and every app that sends as you before touching DNS.
- Export or archive old mail while licenses are active, and confirm your new provider's import options rather than assuming.
- Run both providers side by side: dual SPF, separate DKIM selectors, short MX TTL.
- Handle Autodiscover, and plan for Outlook users explicitly.
- Clean up Microsoft's DNS records only once DMARC reports show nothing still depends on them.
Start with Koltrix
Your domain, one inbox, and an API that sends.
A team inbox where AI sorts and drafts (nothing is sent without your click), plus the transactional API and SMTP relay your product sends with. 7 days free, no card.
