Cancelling Microsoft 365: What Happens to Your Email

The reason so many people lose email when they cancel Microsoft 365 is that they treat the cancel button like a Netflix unsubscribe. It is not. What happens to email when you cancel Microsoft 365 depends on two separate clocks running against each other: the subscription clock and the per-user licence clock. Neither one gives you very long, and the one that catches people out is almost always the shorter of the two.

This guide is the honest map of what actually moves, what gets deleted and when, how to export mail to PST before you cancel, and how to keep your custom-domain address alive if you are moving to a different host. It is a planning guide — the exact clicks in the Microsoft 365 admin center change on their own release schedule, so the walkthrough links back to Microsoft's own live pages for the current UI rather than restating one that will look different in six months.

What actually moves — and what doesn't#

The mental model that gets people into trouble is thinking of a Microsoft 365 subscription as a container that sits there quietly waiting after cancellation. It does not. When the subscription expires, the tenant walks through a defined sequence of states — Active, Expired, Disabled, then Deprovisioned — and each state removes something. Same for a single user: pull their licence and their mailbox starts a shorter countdown of its own.

The table below is the honest map of what survives cancellation, what needs an active export beforehand, and what leaves with the licence. Notice how many rows are "export before you cancel" — that is the whole reason the sequence in this guide matters.

The row people underestimate is the second one: the email address. When the MX record stops pointing at Microsoft, every mail server on the internet learns about it on its own schedule and starts trying the new destination — but only if a new destination is answering. Cancel Microsoft 365 without provisioning a new mail host first and every incoming message from that moment turns into a bounce, not a delay.

The two clocks: licence removal versus subscription cancellation#

Almost every "we lost mail after cancelling" story is a confusion between the two timers Microsoft runs in parallel. Understanding which one is ticking on which mailbox is what turns cancellation from a coin flip into a planned move.

The licence clock runs at the user level. The moment an admin removes a Microsoft 365 licence from a user, that user's mailbox becomes a soft-deleted mailbox. Microsoft publishes a 30-day soft-delete window during which an admin can reassign the licence and the mailbox reappears intact. After 30 days it is permanently deleted, unless the account had a litigation hold or retention policy that promoted it to an inactive mailbox — which itself requires an active Exchange Online Plan 2 licence on the tenant to preserve.

The subscription clock runs at the tenant level and is the longer of the two. When a subscription is cancelled or lapses, Microsoft moves it through Expired (users still have full access), then Disabled (admin-only access, users locked out), then Deprovisioned (data deleted). The published defaults add up to roughly 90 days for most Business and Enterprise plans, though Microsoft varies the numbers by region and by plan and updates them on its own schedule.

The practical implication is the point most guides skip. If you cancel the tenant subscription but leave every user licensed, you get the full ~90-day countdown to move the mail. If instead you strip licences off users first — a very common cost-saving impulse when you have already decided to move — you start the 30-day soft-delete clock on every mailbox before you have exported them. Miss the window and the mail is gone even though the subscription itself still shows Expired.

The safer sequence is to keep every mailbox licensed and active until the exports are complete and the destination is receiving mail. Verify current retention numbers on the Microsoft Learn commerce and Exchange Online pages before you rely on them, because these values change and are not the same in every region.

Pre-migration checklist#

Before you touch cancellation, work through this list end to end. Every item on it is a thing that has, in real migrations off Microsoft 365, turned into lost mail or a week of downtime when it was skipped.

• You have chosen and provisioned the destination mail host — Google Workspace, Fastmail, Zoho Mail, Proton, another Microsoft 365 tenant, or a self-hosted stack — and every yourcompany.com address exists there.
• Every user knows their new mailbox password (or SSO is configured), and can log in and send a test message from the new host through a temporary hostname before you touch MX.
• You have exported every mailbox to PST or MBOX — via eDiscovery Content Search export in the Microsoft Purview compliance portal, the classic Import/Export Wizard in Outlook desktop, or a live IMAP/Graph migration into the destination — and the exports open in a mail client you can read them with.
• You have exported calendars, contacts, and Teams chats where they matter, and confirmed each format imports into the destination.
• You have downloaded or migrated OneDrive and SharePoint content the business cannot afford to lose.
• You have documented the current MX record, SPF record, DKIM selectors (Microsoft rotates two), and DMARC policy for the domain, so you can restore them exactly if the cutover has to be rolled back.
• You have lowered the domain's MX TTL to 300 seconds at least 48 hours before the planned cutover, so the change propagates fast.
• You have a scheduled window — evening or weekend — for the actual cutover, with someone available to watch the mail queue on both sides for the first hour.
• You have kept every user licensed during the export and cutover, and only plan to remove licences after mail is confirmed flowing at the new host.

How to cancel Microsoft 365 without losing email — the steps#

Run this sequence in order. Every step assumes the previous one succeeded and was verified, not just clicked.

1. 1

   Provision the new mail host and every mailbox on it

   Create the tenant or account at the destination provider, add yourcompany.com as a verified domain, and create every user's mailbox there. Do not point MX at it yet — the new host should be reachable via its own hostname so you can send test mail to and from it without disturbing production.

2. 2

   Export every mailbox to PST or migrate live

   For admin-run exports, use eDiscovery Content Search in the Microsoft Purview compliance portal — it produces per-mailbox PST files for the whole tenant. For a live migration, Google Workspace, Fastmail, Zoho and most competitors ship a Microsoft 365 migration tool that connects over Graph or IMAP with an admin credential and preserves folder structure, read/unread state, and calendar. Round-tripping through PST works but sometimes loses categories and pinned states that a live migration keeps.

3. 3

   Verify every export opens before you touch anything else

   Open at least one PST from every user in a real Outlook client, or log into the destination mailbox and confirm the folder tree and message count match. A corrupt or truncated export you discover after cancellation is a data-loss event; the same export you discover before cancellation is a five-minute re-run.

4. 4

   Lower the MX TTL, then cut over

   Twenty-four to forty-eight hours before the cutover, drop your domain's MX TTL to 300 seconds. When you change the MX record to point at the new host, most of the internet's mail servers will pick it up within minutes rather than hours. Change MX, SPF, DKIM, and DMARC together, using the exact values your new host publishes.

5. 5

   Run a final delta sync

   In the window between when you last exported and when MX flips, some mail will have landed at Microsoft 365. Do a final migration-tool or IMAP sync for that delta immediately after the MX change, so the last hour of mail lands at the new host instead of only living in a tenant you are about to cancel.

6. 6

   Watch mail flow at the new host for at least 24 hours

   Send from an outside address to each critical mailbox, check spam scores on mail-tester.com, look at the destination's mail logs, and confirm that replies from your users land where you expect. Do not cancel yet. Keep Microsoft 365 paid and live during this observation period so any misconfiguration is a fix, not a disaster.

7. 7

   Cancel the Microsoft 365 subscription — last

   Once the new host has been receiving mail cleanly for a day or more and the exports are safely stored outside Microsoft, cancel the subscription in the Microsoft 365 admin center under Billing → Your products. Keep the archived PSTs for at least the length of your data-retention policy; the mail may be worth accessing years after the subscription is gone.

What breaks and when — the cutover matrix#

Most "we lost mail during the move" incidents are one specific breakage at one specific moment. Naming them makes them avoidable.

Rollback plan if something goes wrong#

The whole reason to leave Microsoft 365 live during the observation period is that rollback stays cheap. If the new host is misbehaving, revert MX to the original Microsoft values and mail flows back to Microsoft 365 within minutes. Rollback becomes expensive the moment you have cancelled — after that, the tenant has a countdown of its own, and you are racing the Disabled and Deprovisioned phases.

1. 1

   Revert MX to the documented Microsoft values

   The MX record you recorded during the pre-migration checklist — typically a single yourcompany-com.mail.protection.outlook.com host — goes back exactly as it was. Because you dropped the TTL to 300 seconds before the cutover, propagation is minutes, not hours.

2. 2

   Re-enable SPF and DKIM alignment for Microsoft

   Put the Microsoft SPF include back into your SPF record and re-enable the Microsoft DKIM selectors in the Exchange admin center. If you already published new SPF for the destination host, keep both includes temporarily rather than swap one for the other.

3. 3

   Replay any mail that arrived at the new host during the broken window

   Forward or import from the new host back into the corresponding Microsoft 365 mailboxes so the archive is complete on both sides. This is the reason to keep the new host live during rollback rather than deleting it.

4. 4

   Reassign any licences you have already removed

   If you stripped licences off users during the cutover to save cost, reassign them within the 30-day soft-delete window and confirm each mailbox is intact before doing anything else. Once that window closes on a mailbox, the rollback is a restore from PST, not a click.

5. 5

   Diagnose in daylight, cut over again on a fresh window

   Do not iterate on the destination during a live cutover. Roll back, fix the problem on the new host with test mailboxes and a subdomain, prove it works end to end, then schedule a new cutover window.

Doing it without downtime#

Zero downtime on a domain-level mail cutover off Microsoft 365 is possible, and it comes from three habits, not from any single tool. The first is timing — schedule the MX change for the lowest-traffic hour of your week, typically Friday evening or Saturday morning in your business's main timezone, so any propagation delay lands in a period where a slightly delayed mail is not a missed deal.

The second is dual delivery during the observation period. Microsoft 365 supports connectors and transport rules that copy incoming mail to a second host, and most destination platforms accept the same. A temporary Microsoft 365 rule that forwards a copy of every incoming message to the equivalent new-host address turns "we might miss mail" into "we will have every mail at both places and pick the better copy."

The third is not a technical trick: it is telling external contacts nothing. A quiet, well-executed cutover reads to the outside world as no change at all — the address is the same, the domain is the same, replies flow. It is only the customer-visible outages and "please email our new address" messages that turn a migration into a communications event, and none of those are necessary here because the domain does not move.

Where AI Emaily fits after the move#

Once the mail is off Microsoft 365 and living at a new host, the mailbox still has to be worked. That is where AI Emaily fits. It is an AI-native email client that connects over Gmail, Outlook / Microsoft Graph, and any IMAP account, so the archive you just rescued from Microsoft 365 — whether it now lives in Google Workspace, Fastmail, Zoho, Proton or another IMAP host — becomes a normal live mailbox: searchable, triaged, and worked by an assistant that files, drafts in your voice, and closes loops. Full disclosure — we build AI Emaily. There is no free plan, but a seven-day free trial on Pro or Autopilot is on the pricing page; the card is taken and nothing is charged if you cancel before day seven.

Here is the honest limit, because it is worth naming plainly: if your team also lived inside Microsoft Word, Excel, PowerPoint, Teams and SharePoint as much as Outlook, moving mail is only half the project — an equivalent suite is the right destination for the rest, and AI Emaily does not replace those tools. We are an email client, not a productivity suite. Where we help is the part after "mail is at the new host."

Putting it together#

The whole difference between a successful Microsoft 365 cancellation and a catastrophic one is the order of operations, and the awareness that two clocks — not one — are running. Provision the new host first. Export every mailbox to PST or migrate live while every user is still fully licensed. Cut the MX record only after the destination is verified end to end. Remove user licences and cancel the subscription last.

Larger tenants add SSO, conditional access and hybrid-Exchange checks. Regulated tenants add retention holds, inactive-mailbox exports, and legal sign-off. Teams that live in SharePoint and Teams add a suite-migration workstream that runs in parallel. But the mail side of the story is always the same: export before you cancel, move the domain before the users lose access, and never let the retention window be your safety net.