Introduction

A Microsoft 365 migration can move mailboxes successfully while Exchange Online still routes some mail to the old on-premises server through a leftover connector. Users appear to be on the cloud, but hybrid mail flow or staged-cutover settings keep handing certain messages back to infrastructure that should already be retired.

Treat this as a connector-scope problem instead of a generic DNS or mailbox issue. Start by checking whether Exchange Online still has an active connector for the affected domain or route, because connectors can override the mail path even after mailbox moves are complete.

Symptoms

  • Mail still routes through the old on-prem server after Microsoft 365 migration
  • Some domains or recipients behave correctly while others still follow the previous hybrid path
  • Message traces show Exchange Online handing mail to legacy infrastructure
  • Mailboxes are already in Microsoft 365, but mail flow still depends on the old environment
  • The problem appears during hybrid cleanup or staged migration completion
  • The issue started after Exchange hybrid migration, cutover, or tenant cleanup

Common Causes

  • An Exchange Online connector still targets the old on-prem server
  • Connector scope still includes domains or recipients that should now stay in Microsoft 365
  • Hybrid mail flow cleanup was not completed after mailbox migration
  • Accepted-domain or routing settings still assume the old server handles part of the mail path
  • A staged migration ended, but the connector remained active for legacy coexistence
  • Message routing was validated for mailbox access but not for the final outbound and internal path

Step-by-Step Fix

  1. Review recent message traces and identify exactly where Exchange Online hands the affected mail next, because you need proof that a connector is still part of the live route.
  2. Check every Exchange Online connector related to the migrated domains and confirm whether any still point to the old on-prem server, because one leftover hybrid connector can keep rerouting mail after user moves are finished.
  3. Compare connector scope, domains, and recipient conditions with the current migration state, because a connector that was valid during coexistence may now be broader than intended.
  4. Review accepted-domain and mail-routing settings for the affected domains, because stale coexistence assumptions can make Exchange Online keep treating the old server as authoritative for part of the route.
  5. Disable, narrow, or replace the stale connector only after confirming the intended cloud-side path, because connector cleanup should follow the final migration design rather than guesswork.
  6. Retest with the exact sender and recipient combination that exposed the problem, because connector issues often affect only certain routes or domain scopes.
  7. Compare message traces before and after the change to confirm Exchange Online no longer hands mail to the old on-prem environment, because successful delivery alone does not prove the legacy hop is gone.
  8. Verify that the old server is no longer receiving connector-driven traffic in its logs, because backend evidence should match the new Exchange Online routing state.
  9. Document the final connector inventory and intended hybrid end state after recovery, because leftover coexistence connectors are easy to miss during future Microsoft 365 cleanups.