Introduction

A Microsoft 365 migration can move mailboxes successfully while the domain itself is still treated as an internal relay in Exchange Online. Users may already sign in and send mail from the cloud, but unresolved recipients, shared addresses, or certain routing paths still behave as if another mail system owns part of the domain.

Treat this as a domain-routing state problem instead of a general mailbox failure. Start by checking whether the accepted domain is still configured as Internal Relay when the intended end state is now fully cloud authoritative, because that one coexistence leftover can keep message handling tied to the old environment.

Symptoms

  • Mail routing still behaves like coexistence is active after Microsoft 365 migration
  • Unknown-recipient handling does not match the expected fully cloud-hosted design
  • Some messages still follow old hybrid logic even though user mailboxes are already in Microsoft 365
  • Exchange cleanup appears incomplete for one or more migrated domains
  • The domain works for most users, but edge cases still behave like the old platform is authoritative for part of the address space
  • The issue started after hybrid cleanup, staged migration completion, or domain cutover

Common Causes

  • The accepted domain in Exchange Online is still set to Internal Relay instead of Authoritative
  • Hybrid coexistence was partially removed, but domain routing state was left behind
  • A connector or on-prem dependency made teams hesitant to finalize accepted-domain settings
  • The migration moved mailboxes first and postponed final mail-routing cleanup
  • Another recipient object or downstream system still depends on the older relay-style design
  • Validation focused on user mailbox access instead of final accepted-domain behavior

Step-by-Step Fix

  1. Confirm the intended post-migration design for the domain, because you should only remove Internal Relay behavior if Microsoft 365 is now supposed to be fully authoritative.
  2. Check the accepted-domain type for the affected domain in Exchange Online and verify whether it is still set to Internal Relay, because that setting directly affects how unresolved or partially scoped recipients are handled.
  3. Review any remaining connectors, hybrid configuration, or downstream dependencies tied to that domain, because accepted-domain cleanup should match the real mail-flow architecture rather than guesswork.
  4. Compare the accepted-domain state with the current recipient inventory, because stale contacts, remote mailboxes, or coexistence objects can make teams think Internal Relay is still required when the real problem is leftover directory state.
  5. Change the accepted-domain type only after confirming the domain should now be fully cloud authoritative, because the wrong routing type can break edge cases if coexistence is still genuinely needed.
  6. Retest the exact sender and recipient scenarios that exposed the problem, including unresolved addresses or recipients migrated late, because accepted-domain issues often show up only on specific mail paths.
  7. Review message traces before and after the change to confirm Exchange Online no longer behaves like another system owns part of the domain, because successful delivery alone does not prove the routing model is finalized.
  8. Check for related domains migrated in the same project, because accepted-domain settings are often left inconsistent across the tenant after staged cleanup.
  9. Document the final accepted-domain type, connector state, and coexistence outcome for the domain, because this is one of the easiest Exchange migration leftovers to miss later.