Introduction

A Microsoft 365 migration can move user mailboxes successfully while inbound mail still lands on the old mail server because the secure email gateway remains in front of the environment. Internet senders reach the gateway normally, but the gateway still forwards accepted mail to the legacy destination instead of the new Microsoft 365 path.

Treat this as a downstream gateway-routing problem instead of an MX or mailbox problem. Start by tracing a real inbound message through the secure email gateway, because the gateway may still be the public entry point while its internal handoff target remains set to the pre-migration mail server.

Symptoms

  • Inbound mail passes through the secure email gateway but still delivers to the old mail server
  • Microsoft 365 mailboxes do not receive new inbound messages while the legacy server still does
  • Gateway logs show successful acceptance and forwarding to the previous destination
  • MX records point to the gateway, so DNS appears correct even though delivery is wrong
  • Direct Microsoft 365 testing works, but normal internet mail still follows the old path
  • The issue started after a Microsoft 365 cutover, staged migration, or mail-flow cleanup

Common Causes

  • The secure email gateway still uses the old mail server as its delivery target
  • A failover, smarthost, or downstream route on the gateway was never updated for Microsoft 365
  • Gateway routing scope still treats the domain or some recipients as legacy destinations
  • The migration changed MX records or mailbox locations but not the gateway handoff settings
  • The old mail server remains reachable and accepts mail, which hides the routing mistake
  • Validation focused on Microsoft 365 settings and mailbox access instead of the gateway-to-destination delivery path

Step-by-Step Fix

  1. Trace a recent inbound message through the secure email gateway logs and confirm the exact destination it forwarded to, because you need proof of the live handoff path before changing gateway routing.
  2. Confirm the intended post-migration design for the domain, because the gateway may need to deliver directly to Microsoft 365, to Exchange Online Protection, or to another approved downstream target.
  3. Review the gateway delivery target, routing policy, connector, and failover settings for the affected domain, because one leftover legacy destination can keep all accepted mail flowing to the old server.
  4. Compare route scope and recipient conditions on the gateway, because some policies may still send only part of the domain or a subset of users to the previous environment.
  5. Update the gateway to use the intended Microsoft 365 delivery path and remove the stale legacy handoff only after confirming there is no compliance, journaling, or relay dependency that still requires the old route.
  6. Check the old mail server and any receive connector or inbound service it still exposes, because a legacy system that silently accepts mail can make the gateway problem harder to notice.
  7. Send new external test messages through the normal internet path and confirm they appear in Microsoft 365 message trace as well as in the target mailbox, because direct tests alone do not validate the real gateway path.
  8. Monitor gateway logs, Microsoft 365 traces, and old-server logs through at least one retry cycle, because queued or deferred mail may continue following the old route for a while after the main change.
  9. Document the final secure-email-gateway handoff design for the domain, because downstream delivery targets are commonly overlooked during future Microsoft 365 migrations.