How to Decommission Exchange Server After Migrating to Exchange Online Without Breaking Mail

Most Exchange Server 2019 or 2016 migrations stall after the last mailbox moves. The server is still running, the team has moved on, and nobody wants to be the person who broke email by touching something they were not sure about.

The real decommission work starts after the migration is technically complete. Here is how to do it without calling Microsoft support.

Is Your Migration Actually Done? A Pre-Decommission Checklist

Before you touch anything, confirm three things:

All mailboxes are in Exchange Online. Not just moved - fully batch-completed, with no on-premises mailboxes remaining in any state. If you see any mailboxes still in "soft deleted" or "provisioning" state, the migration is not done.

Hybrid mail flow is not still in use. If you have any on-premises mailboxes that still receive mail through Exchange Server, or any users whose Outlook clients are still connecting to the on-premises server, you are still in hybrid mode - not post-migration.

You have no third-party integrations that deliver mail through Exchange Server. This catches most sysadmins off guard. Things like:

• Fax servers that relay through the on-premises Exchange receive connector


• Building management or IoT systems that send alerts via Exchange authenticated relay


• Print-to-email services that use an Exchange SMTP relay credential


• Any internal application that sends email using an Exchange mailbox credential

If you are not sure, ask your application owners. Do not assume.

What Must Stay After the Migration

Hybrid Send Connector

This is the connector in Exchange Online that routes mail to on-premises recipients when you still have some mailboxes there. If you remove it before all recipients are cloud-only, mail to those recipients will hard bounce.

Keep the hybrid send connector if:

• Any mailboxes are still on-premises (including in soft-deleted state)


• You have public folders still hosted on-premises


• Any third-party system relays mail through Exchange Server

You can remove it when:

• All mailboxes are in Exchange Online and fully provisioned


• All public folder mail学问 are migrated


• No integrations depend on the on-premises SMTP relay

Accepted Domains

In Exchange Online, your accepted domains configuration tells the service which domains you accept mail for. This should already point to Exchange Online after the migration. If it still lists your on-premises domain as "Authoritative" rather than "Internal Relay," you have a configuration gap that needs fixing before decommission.

DNS Records

Your MX record must point to Exchange Online, not your on-premises server. That should already be the case during the migration cutover. But double-check it before decommission - if a previous admin set it back or used a CNAME that resolves to the old server, mail will go to the wrong place.

Your SPF record should include the Exchange Online sending IPs and should have removed any old on-premises server IPs. If you are unsure what your SPF record looks like, check it before you remove anything. An SPF record that includes a server that no longer sends mail is not dangerous - but one that is missing Exchange Online IPs will cause delivery failures.

What to Remove When You Are Ready

Once the checklist above is satisfied, remove things in this order:

1. Remove received connectors on-premises. These accept inbound mail from the internet. If all your mailboxes are in Exchange Online and your MX points there, these connectors are not doing anything. Removing them first means you can still re-enable them if something goes wrong.

2. Remove or repoint internal DNS records for Exchange. If you have internal DNS zones pointing to the Exchange Server for any namespace (autodiscover, MX for an internal domain, etc.), remove or update those records. Clients that resolve the internal namespace first will still try to connect to Exchange Server even after the migration.

3. Remove the hybrid send connector from Exchange Online. Do this only after confirming all on-premises recipients are cloud-only. This connector is created and managed in the Exchange Online admin center under mail flow > connectors. Removing it severs the mail routing between Exchange Online and your old server.

4. Revoke and remove certificates. Exchange Server uses certificates for IIS, SMTP, and other services. If these certificates are still bound to services, remove them from the server or let them expire naturally. If you have a load balancer in front of Exchange, remove the certificate there too.

5. Remove Exchange Server from your topology. Once mail flow is confirmed working without the on-premises server, you can shut down the virtual or physical machine. Do not demote the Active Directory site without checking that no other services depend on the Exchange AD site configuration.

How to Verify Nothing Breaks Before You Pull the Plug

Before you shut down the server, run these checks:

Test inbound mail from external senders. Send a test email from a Gmail account and a Yahoo account to an Exchange Online mailbox. Confirm it arrives in the inbox, not quarantine. This confirms your MX, SPF, DKIM, and Exchange Online receiving configuration are all correct.

Test outbound mail to external recipients. Send from your Exchange Online mailbox to a test external address. Confirm delivery. This confirms your Exchange Online send connector, SPF, and DKIM signing are all working.

Test third-party integrations. If you have any fax, IoT, or application integrations that send through an Exchange relay, send a test message through each one. Confirm delivery to the intended external recipient.

Test OAuth and Outlook connectivity. Confirm that Outlook clients are connecting to Exchange Online via OAuth. In organizations that have completed the migration, Basic Auth is typically already disabled or scheduled for retirement - but in some environments, legacy Outlook connections may still be in use. If Outlook falls back to the on-premises server after shutdown, that indicates a hybrid connection was still active.

Check Exchange Online delivery reports. In the Exchange Online admin center, go to Mail Flow > Message Trace and run a trace for your test messages. If they show as delivered to the right recipient, you are in good shape.

What to Do If Mail Breaks After Decommission

If something goes wrong after you remove the server:

If inbound mail is bouncing: Check your MX record is pointing to Exchange Online. Run a message trace in the Exchange Online admin center. Check whether the issue is a SPF, DKIM, or DMARC failure - all three can cause mail rejection after a migration if the sending infrastructure changed.

If outbound mail is failing: Confirm your Exchange Online send connector is still there. Check whether your SPF record still includes the right IPs. If you changed your SPF record as part of the decommission and accidentally removed Exchange Online IPs, that will cause failures immediately.

If a third-party integration stops working: This means it was still using the on-premises Exchange relay. Re-enable the on-premises receive connector temporarily, then work with the application owner to update their relay configuration to point to Exchange Online directly.

If OAuth breaks for Outlook clients: Check that your application registrations in Azure AD are still valid. The modern auth infrastructure for Exchange Online depends on Azure AD app registrations - if those were tied to the on-premises server's service principal, they may need to be recreated.

After Decommission: Clean Up Without Rushing

Once mail flow is confirmed stable without the server, you can proceed with the full cleanup:

• Remove Exchange Server from the Active Directory site configuration
• Remove any scheduled tasks or services on other machines that reference the Exchange Server
• Update your monitoring to remove checks for the old server
• Document the final configuration for future reference

Do not rush this part. Give yourself a week of normal mail flow observation before you do the final AD cleanup. Most problems surface within the first 48 hours.

FAQ

Can I just shut down the Exchange Server without removing connectors and records?

You can, but it is more likely to cause intermittent issues. If the server is off but DNS still points to it, mail will fail. If connectors still exist in Exchange Online but reference a server that is not there, you may get delayed or bounced mail for specific scenarios.

Do I need to keep any on-premises Exchange components after migrating all mailboxes?

If you have fully migrated all mailboxes and have no third-party integrations depending on Exchange Server, you do not need any on-premises Exchange components. However, many organizations keep an Exchange Server object in AD for management purposes even if the server itself is off. That is fine - just make sure nothing is trying to use it.

What happens to public folders?

Public folders in modern Exchange Online migrations are moved to cloud public folders. If your public folders are still on-premises, they need to be migrated before decommission. Microsoft provides a script-based migration process for this.

Should I update my SPF record after decommission?

Yes. Remove any IP addresses that belong to the decommissioned Exchange Server from your SPF record. Add the Exchange Online sending IPs if they are not already there. Your SPF record should reflect your current sending infrastructure, not the old one.

What about DMARC after the migration?

After decommissioning Exchange Server, check your DMARC configuration to make sure it still matches your current sending setup. Your DMARC aggregate reports are the fastest way to spot any legitimate senders that are now failing after the infrastructure change - for example, a SaaS tool that was previously routing through Exchange and is now sending directly without proper DKIM signing. DMARCFlow reads your aggregate reports and flags exactly which senders are failing, which helps you fix the configuration before it becomes a deliverability problem.

Bottom Line

The Exchange Server decommission is mostly a cleanup job, not a migration job. The actual mailbox migration is the hard part. Everything after that is about confirming what still needs to work, removing what no longer does, and verifying the change did not break anything.

If you run the checks in this guide before you touch the server, you will catch most problems before they become incidents.

---

Need help reading your DMARC reports after an Exchange migration? DMARCFlow interprets aggregate reports and tells you exactly which senders are failing and why.