Blog · Deliverability
How to Fully Decommission Exchange Server After Your Microsoft 365 Migration
You've moved all mailboxes to Microsoft 365. Outlook connects to Exchange Online. Active Directory is synced. Everything works.
And yet your on-premises Exchange Server is still sitting there, running, taking updates, consuming licensing and hardware costs. You know you should remove it. You are not sure you are done.
This post covers what "fully decommissioned" actually means, how to check whether you are ready, the correct removal sequence, and what tends to break when people remove Exchange too early.
When You Are Actually Done with Exchange
Most migrations end in a state that Microsoft calls "hybrid" - mail flows through both Exchange Online and your on-premises server. That is by design during migration. It is not the end state.
You are ready to decommission Exchange when all of the following are true:
- All mailboxes are in Exchange Online. No mailboxes remain on any on-premises Exchange server, including shared mailboxes, room mailboxes, and archive mailboxes.
- All shared mailboxes are licensed or converted. Shared mailboxes in Exchange Online must either have an Exchange Online Plan 1 or Plan 2 license attached, or be converted to Microsoft 365 Groups.
- No hybrid connectors are still routing mail. Both the inbound internet mail connector (pointing to EXO) and any on-premises relay connectors are confirmed unnecessary.
- Your accepted domains in Exchange Online match your needs. All domains that receive email are listed in Microsoft 365 admin center → Settings → Domains, verified and set to Authoritative.
- No mobile device policies, retention policies, or transport rules depend on Exchange admin center. These must be migrated to Microsoft Purview compliance center.
- No service accounts or applications authenticate to Exchange on-premises. This includes any third-party email gateways, archiving products, or ITSM integrations that were pointed at on-premises EWS or Autodiscover.
If any of those items are unresolved, removing Exchange will cause service interruptions. Not might - will.
Pre-Checks Before You Remove Anything
Run these before touching the first server.
1. Export your Exchange hybrid configuration
In Exchange Management Shell on any surviving Exchange server:
Get-HybridApplication | Export-Csv -Path .\hybrid-config.csv
This exports your hybrid application registration. If you ever need to reconnect Exchange Online to on-premises for any reason, this file makes re-establishing the relationship faster. Keep it.
2. Check for remaining shared mailboxes
In Exchange Online PowerShell:
Get-EXOMailbox -ResultSize Unlimited | Where-Object { $_.RecipientTypeDetails -eq 'SharedMailbox' } | Select-Object Name, RecipientTypeDetails, ExchangeLocation
Every shared mailbox should appear with an Exchange Online location. If any show an on-premises location, move those mailboxes first.
3. Verify mail flow is fully cloud-native
Send a test message from an external account (Gmail, for example) to an internal address and trace the headers. The receiving server should be protection.outlook.com or a variant. If the headers show your on-premises Exchange IP as the receiving server, mail is still being delivered there first.
4. Document your accepted domains
In Microsoft 365 admin center → Settings → Domains, take a screenshot or export the domain list. This is your source of truth after Exchange is gone. If a domain is missing from this list, Microsoft 365 will reject mail for it.
5. Check what your Autodiscover record points to
Your Autodiscover DNS record is what Outlook uses to find a user's mailbox server. After full decommission, this record must point to autodiscover.outlook.com, not your on-premises Exchange server.
Run this in a command prompt or PowerShell:
nslookup -type=SRV _autodiscover._tcp.yourdomain.com
If the result points to an on-premises Exchange hostname or IP, update the SRV record before decommission.
The Decommission Sequence
Remove things in this order. Skipping steps causes problems.
Step 1: Disable directory synchronization (optional but recommended)
If you are using Microsoft 365 exclusively and no longer need to manage users from on-premises Active Directory:
In Microsoft Entra admin center → Entra Connect → select your connector → Disable directory synchronization.
Do this only after confirming all user accounts exist as cloud-only users in Entra ID. If any accounts are still synced from on-premises, disabling sync converts them to cloud-only - which is fine, but the account must exist in the cloud first.
Step 2: Remove the hybrid Exchange server registration
In Microsoft 365 admin center → Exchange admin center → servers. Remove the on-premises Exchange server from the hybrid server list before uninstalling Exchange.
This prevents the Azure AD application registrations for hybrid from lingering and causing authentication confusion later.
Step 3: Uninstall Exchange on-premises
Run the Exchange Server setup from the original media:
Setup.exe /Mode:Uninstall /IAcceptExchangeServerLicenseTerms
On the last Exchange server in your organization, uninstall the Mailbox and Edge Transport roles in sequence, then the Client Access role.
Do not simply shut down the虚拟机. The uninstall process deregisters the server from Azure AD and removes the hybrid application registration. A powered-off server still counts as present from Microsoft's perspective.
Step 4: Remove DNS records pointing to on-premises
After uninstall, update these DNS records:
| --- | --- | --- |
|---|---|---|
| Record type | Old value (on-prem) | New value |
| MX | mail.yourdomain.com → on-prem IP | `yourdomain-com.mail.protection.outlook.com` |
| Autodiscover SRV | On-prem Exchange FQDN | `autodiscover.outlook.com` |
| SPF (if includes on-prem) | Remove on-premises include | Update to include only cloud senders |
| SPF (TXT) | `v=spf1 include:on-prem-mailserver ~all` | `v=spf1 include:spf.protection.outlook.com ~all` |
Your SPF record is the most commonly missed update at this stage. If it still includes your on-premises mail server IP range, emails sent from on-premises systems may fail SPF checks post-decommission.
Step 5: Validate all email sending sources
Once on-premises Exchange is gone, you should have a clean picture of everything that sends email on your behalf. This is the right time to audit your SPF record:
- Marketing platform (Salesforce, HubSpot, Mailchimp)
- Transactional email services (SendGrid, Postmark)
- Internal applications that send email directly
- Any SaaS tool that sends on behalf of your domain
Add each of these to your SPF record or move to include-based mechanisms. Any IP not on this list should not be sending from your domain - and you want DMARC reports to confirm that.
This is also where DMARC reporting becomes practical. With a complete picture of your sending sources, you can set meaningful DMARC policies. DMARCFlow processes your aggregate reports and flags any unauthorized sending IPs before you move to p=reject.
What Breaks If You Remove Exchange Too Early
These are the most common problems people hit.
Autodiscover breaks. Outlook on deployed clients cannot find the mailbox. Users see repeated credential prompts. Fix: update the Autodiscover SRV record before removing Exchange.
Mobile devices lose access to mail. ActiveSync policies applied by on-premises Exchange are no longer enforced, and some third-party mail apps lose their on-premises endpoint. Fix: ensure all ActiveSync app credentials are updated to use Exchange Online endpoints before decommission.
Shared mailboxes stop accepting permissions changes. If a shared mailbox was migrated but still has permissions granted via on-premises Exchange RBAC (not Entra ID roles), those permissions stop working. Fix: reassign shared mailbox permissions through the Exchange Online admin center or Entra ID after migration.
Distribution groups stop allowing external mail. Groups that were mail-enabled in on-premises Exchange lose their ability to receive external email if the migration of the group object was incomplete. Fix: recreate the groups in Exchange Online if the on-premises objects were not properly migrated.
Legacy third-party integrations stop sending. Any product that was sending email via on-premises Exchange SMTP or EWS (archiving tools, ITSM platforms, custom applications) will fail. The fix is application-specific: point those integrations at Exchange Online SMTP endpoints.
How to Verify M365 Is Fully Self-Sufficient
After decommission, run these checks:
- Send from three different internal accounts to three external providers (Gmail, Yahoo, Outlook.com). Confirm all six deliveries arrive in inbox.
- Send from an external account to three internal addresses. Confirm delivery.
- Check the Exchange admin center health dashboard. It should show all services as healthy with no warnings about on-premises connectivity.
- Review your DMARC aggregate reports within 48 hours. You should see only known, expected sending IPs. Any unknown IP is worth investigating before you consider moving to
p=reject.- Test on a roaming client - a laptop not on the corporate network, using only O365 endpoints. This confirms Autodiscover is fully cloud-only.
- Review your DMARC aggregate reports within 48 hours. You should see only known, expected sending IPs. Any unknown IP is worth investigating before you consider moving to
- Check the Exchange admin center health dashboard. It should show all services as healthy with no warnings about on-premises connectivity.
- Send from an external account to three internal addresses. Confirm delivery.