Introduction

A Microsoft 365 migration can move mailboxes and domains successfully while a mail flow rule still redirects some messages to the old mail system. Users may look fully cut over in Exchange Online, but a leftover transport rule continues to catch certain senders, recipients, or domains and sends traffic back to legacy infrastructure.

Treat this as a rule-scope problem instead of a general mailbox or MX issue. Start by checking whether any Microsoft 365 mail flow rule still uses a redirect, blind copy, or add-recipient action tied to the previous mail platform, because one coexistence-era rule can keep part of the mail path alive after the rest of the migration is complete.

Symptoms

  • Some messages still arrive in the old mail system after the Microsoft 365 migration
  • The problem affects only specific senders, recipients, groups, or domains
  • Message trace shows a mail flow rule acting on the message before final delivery
  • Mailboxes are already in Microsoft 365, but certain traffic still detours to legacy infrastructure
  • Internal and external messages do not follow the same delivery path
  • The issue started after staged migration cleanup, coexistence changes, or transport-rule edits

Common Causes

  • A Microsoft 365 mail flow rule still uses a redirect, blind copy, or add-recipient action toward the old mail system
  • Rule conditions still match migrated recipients, groups, or domains that should now stay in Microsoft 365
  • Rule exceptions were never updated after the final cutover
  • Rule priority causes an old coexistence rule to run before the intended post-migration logic
  • Mailbox migration finished, but transport-rule cleanup was postponed
  • Validation focused on normal delivery and missed rule-based edge cases

Step-by-Step Fix

  1. Run a message trace for an affected message and record which rule acted on it, because you need to prove that a transport rule is part of the live path before changing mail routing.
  2. Open the matching Microsoft 365 mail flow rule and review every action it applies, because redirect, blind copy, and add-recipient behavior can all keep messages flowing toward the old system.
  3. Compare the rule conditions and exceptions with the intended post-migration design, because a rule that was correct during coexistence may now be matching users or domains that are fully cloud-hosted.
  4. Check the rule priority and whether it stops additional processing, because an older redirect rule can override newer cleanup rules if it still runs first.
  5. Disable, narrow, or remove the stale redirect behavior only after confirming the domain or recipients no longer depend on the old platform, because transport cleanup should follow the real migration end state.
  6. Retest with the same sender, recipient, and message path that exposed the issue, because mail flow rules often affect only specific combinations and can look fixed when the wrong scenario is tested.
  7. Review the new message trace and confirm the rule no longer sends mail toward the old system, because successful delivery alone does not prove the redirect action is gone.
  8. Check for related coexistence rules that were created in the same migration phase, because one leftover redirect rule often means other transition rules were also left behind.
  9. Document the final rule inventory and remove any migration-only transport logic from your checklist, because mail flow rules are easy to miss after mailbox cutover appears complete.