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. This creates a confusing situation where MX records appear correct but mail never reaches the new mailboxes.

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. This issue is common in organizations that use third-party email security gateways (Proofpoint, Mimecast, Barracuda, etc.) in front of their mail infrastructure.

The problem frequently appears after Microsoft 365 migrations where the gateway was not reconfigured to point to Exchange Online Protection (EOP), staged migrations where some users were moved but gateway routing was not updated, or when organizations forget that the gateway needs to deliver to a different destination after the mailbox cutover.

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
  • Users who were migrated report not receiving email while legacy users still do
  • Message trace in Microsoft 365 shows no inbound messages
  • Gateway quarantine and policy actions work, but final delivery goes to wrong server

Common Causes

  • The secure email gateway still uses the old mail server as its delivery target or smarthost
  • 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, hiding the routing mistake
  • Validation focused on Microsoft 365 settings and mailbox access instead of gateway-to-destination delivery path
  • Gateway connector or delivery domain settings point to the on-premises Exchange server
  • Hybrid configuration was completed but gateway was not updated for the cutover

Step-by-Step Fix

  1. 1.Trace a recent inbound message through the secure email gateway logs and confirm the exact destination it was forwarded to, because you need proof of the live handoff path before changing gateway routing.
  2. 2.Confirm the intended post-migration design for the domain, because the gateway may need to deliver directly to Microsoft 365 (tenant.mail.protection.outlook.com), to Exchange Online Protection, or to another approved downstream target.
  3. 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. 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. 5.Update the gateway to use the intended Microsoft 365 delivery path (typically yourdomain.mail.protection.outlook.com) and remove the stale legacy handoff only after confirming there is no compliance, journaling, or relay dependency that still requires the old route.
  6. 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. 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. 8.Monitor gateway logs, Microsoft 365 message 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. 9.Document the final secure-email-gateway handoff design for the domain, because downstream delivery targets are commonly overlooked during future Microsoft 365 migrations.

Verification

Confirm the fix is complete:

  1. 1.Send test email from external address and verify delivery to Microsoft 365 mailbox
  2. 2.Check gateway logs to confirm mail is forwarded to the correct Microsoft 365 endpoint
  3. 3.Verify Microsoft 365 message trace shows the inbound message
  4. 4.Confirm the old mail server receives no new inbound mail
  5. 5.Test multiple recipients to ensure all mail routes correctly

Prevention

To avoid this issue in future migrations:

  • Include gateway delivery target in the migration checklist alongside MX records
  • Update gateway routing as part of the cutover process, not post-migration
  • Document the relationship between gateway and mail infrastructure before migration
  • Test inbound mail flow through the gateway explicitly after cutover
  • Monitor both old server and Microsoft 365 for mail activity during migration
  • Include gateway configuration in change management and sign-off procedures
  • [Technical troubleshooting: Fix Bounce Handling Verp Envelope Return Path Conf](bounce-handling-verp-envelope-return-path-configuration)
  • [Fix Email Attachment Rejected Size Exceeding Provider Limit 25mb Issue in Email](email-attachment-rejected-size-exceeding-provider-limit-25mb)
  • [Fix Email Bounce 550 Permanent Failure Recipient Address Rejected Issue in Email](email-bounce-550-permanent-failure-recipient-address-rejected)
  • [Fix Email Dkim Signature Verification Failing After Key Rotation Issue in Email](email-dkim-signature-verification-failing-after-key-rotation)
  • [Fix Email Dmarc Policy Quarantine Message In Spam Folder Issue in Email](email-dmarc-policy-quarantine-message-in-spam-folder)

<script type="application/ld+json"> { "@context": "https://schema.org", "@type": "TechArticle", "headline": "How to Fix a Secure Email Gateway Still Delivering to the Old Mail Server After Microsoft 365 Migration", "description": "Resolve a secure email gateway still delivering to the old mail server after Microsoft 365 migration by checking gateway targets, route scope, and failover settings.", "url": "https://www.fixwikihub.com/fix-secure-email-gateway-still-delivering-to-old-mail-server-after-microsoft-365-migration", "publisher": { "@type": "Organization", "name": "FixWikiHub", "url": "https://www.fixwikihub.com" }, "author": { "@type": "Person", "name": "FixWikiHub Editorial Team" }, "datePublished": "2025-10-31T00:43:09.219Z", "dateModified": "2025-10-31T00:43:09.219Z" } </script>