Introduction

A Microsoft 365 migration can move the mailbox successfully while part of mail routing still follows an old targetAddress or remote mailbox setting. Users may look fully cloud-based, yet internal delivery, forwarding behavior, or hybrid message flow still treats the recipient as if the old environment owns the mailbox.

Treat this as a recipient-object problem instead of a general Exchange Online outage. Start by checking whether the affected user still has a stale targetAddress, remote mailbox object, or coexistence setting that points mail back toward the previous server.

Symptoms

  • Mail for a migrated user still routes to the old server after Microsoft 365 migration
  • Internal senders and external senders see different delivery behavior for the same mailbox
  • Exchange hybrid cleanup appears incomplete for one or more recipients
  • Mail loops, misroutes, or lands in the wrong environment after the mailbox move
  • The user is already in Microsoft 365, but directory objects still behave like coexistence is active
  • The issue started after mailbox migration, hybrid transition, or staged cleanup

Common Causes

  • The recipient still has a stale targetAddress pointing to the old environment
  • A remote mailbox or mail-enabled user object was not cleaned up after migration
  • Directory synchronization preserved coexistence attributes longer than intended
  • The mailbox moved, but hybrid recipient state was never finalized
  • One conflicting recipient object still owns routing for the legacy address
  • Migration validation focused on mailbox access instead of final message-routing behavior

Step-by-Step Fix

  1. Review message traces for the affected recipient and confirm where mail is handed off next, because you need proof that recipient routing is still following the old path.
  2. Check the user’s current Exchange and directory attributes for targetAddress, remote mailbox state, and related hybrid routing properties, because one stale value can keep mail flowing toward the previous server.
  3. Compare the live recipient object in Microsoft 365 with any synchronized on-prem or coexistence object, because conflicting directory state often explains why one mailbox still behaves like a hybrid target.
  4. Confirm whether the mailbox should now be treated as fully cloud-hosted with no legacy routing dependency, because cleanup should match the intended post-migration design.
  5. Remove, update, or finalize the stale routing attribute only after confirming which recipient object is authoritative, because hybrid environments can create duplicate or overlapping mail-enabled objects.
  6. Retest the exact sender and recipient path that exposed the issue, because routing problems tied to stale recipient state often affect only certain combinations of internal and external delivery.
  7. Check for related recipients migrated in the same batch, because leftover targetAddress or remote mailbox state is often a pattern rather than a one-user exception.
  8. Verify the old server stops receiving recipient-driven traffic for that mailbox, because successful delivery alone does not prove the legacy routing hop is gone.
  9. Document the final recipient state and hybrid cleanup outcome after recovery, because stale routing attributes are easy to miss during later Exchange cleanup.