Introduction

A hybrid migration can reach the cutover stage while Centralized Mail Transport still forces Microsoft 365 outbound mail through the on-prem Exchange environment. Users appear to be fully in the cloud, but external mail still hairpins through legacy transport that was meant only for coexistence, compliance hold points, or staged relay dependencies.

Treat this as a final outbound-design problem instead of a general mail-routing issue. Start by checking whether Centralized Mail Transport is still enabled in the hybrid configuration and whether the tenant is truly ready for direct outbound delivery from Microsoft 365, because this failure mode is about the post-cutover send architecture rather than a generic leftover connector path.

Symptoms

  • Microsoft 365 outbound mail still leaves through on-prem Exchange after cutover
  • External recipients still see the old on-prem public IP, certificate, smart host, or journaling hop in outbound headers
  • An on-prem outage, queue delay, or relay issue now blocks cloud users who should be sending directly from Microsoft 365
  • Compliance, archiving, or allowlist systems still appear tied to the old outbound path
  • Test messages leave Microsoft 365 successfully, but only after an unnecessary handoff through legacy Exchange
  • The issue started after Hybrid Configuration Wizard cleanup, final cutover, or an incomplete move away from centralized transport

Common Causes

  • Centralized Mail Transport is still enabled in the hybrid configuration
  • Hybrid Configuration Wizard settings were never updated after coexistence ended
  • The tenant still depends on on-prem journaling, compliance, relay, or smart-host controls for outbound mail
  • SPF, allowlists, or downstream mail-security policy were never prepared for direct Microsoft 365 outbound sending
  • The project moved mailboxes but never completed the direct-to-internet outbound design
  • Validation focused on mailbox moves and inbound delivery instead of the final outbound transport architecture

Step-by-Step Fix

  1. Capture a recent outbound message header or trace and confirm that Exchange Online is still handing external mail to on-prem Exchange, because you need evidence of the live outbound path before changing centralized transport.
  2. Confirm the intended end state for outbound mail after cutover, because you should only remove Centralized Mail Transport if the tenant is meant to send directly from Microsoft 365.
  3. Review the Hybrid Configuration Wizard state and hybrid transport settings specifically for Centralized Mail Transport, because this feature can remain enabled even after mailbox migration is otherwise complete.
  4. Inventory any journaling, disclaimer, relay, compliance, smart-host, or downstream allowlist dependency that still assumes outbound mail leaves from on-prem Exchange, because those dependencies often block a clean move away from centralized transport.
  5. Update the real control point for centralized transport only after confirming the tenant is ready for direct outbound delivery, because removing the old path without dependency review can break compliance or mail acceptance.
  6. Send new test messages to external recipients and inspect the outbound headers, because you need to confirm messages now leave from Microsoft 365 rather than hairpinning through legacy Exchange.
  7. Check whether downstream systems such as gateways, spam filters, partner allowlists, or SPF records now reflect the Microsoft 365 outbound path, because direct send readiness is part of the fix.
  8. Verify the on-prem Exchange queues and logs no longer receive routine cloud outbound traffic, because the old server should stop acting as the forced egress point once Centralized Mail Transport is removed.
  9. Document the final outbound transport design, any retired dependency, and the date Centralized Mail Transport was disabled, because HCW-era outbound settings are easy to overlook during later Exchange cleanup.