One domain, two tenants: how the mail keeps finding people mid-migration
Two companies are merging, and for a few weeks half the mailboxes live in one tenant and half in the other — but everyone still hands out the same @contoso.com address. That domain can only be verified in one place. This is how mail crosses the line anyway, and it is part of the Azure tenant-to-tenant migration guide.
New to cloud? CAMPUX is a free, build-first course. Start here →
Here is the fact that decides everything else. A custom domain — the vanity name on your address, contoso.com — can be verified in exactly one Microsoft 365 tenant. Microsoft states it plainly in the cross-tenant migration guidance: domains are associated with one Microsoft Entra ID or Exchange Online tenant only. You cannot half-verify it in the source and half in the target. You cannot let the sales team's mailboxes claim it in tenant A while engineering's claim it in tenant B. It belongs to one directory, whole, until you deliberately move it. So the moment you start relocating mailboxes across the boundary, you have people who still advertise @contoso.com whose actual mailbox now lives somewhere the domain does not point. Something has to bridge that gap.
Why you cannot just split the domain
The reason is not a licensing nicety — it is how Exchange decides who is allowed to send as a domain. A tenant is authoritative for the domains it has verified, and it will only let a mailbox stamp a primary address in a domain the tenant owns. If Microsoft let two tenants both claim contoso.com, either one could send mail as the other's users, and inbound routing would have two equally valid answers for where [email protected] lives. That ambiguity is exactly what the one-tenant rule forbids. You will see the same rule bite in a smaller way during setup: put a proxy address on a target object in a domain that tenant does not own, and once the object is licensed, Exchange scrubs it off. Verified-domain addresses stay; foreign ones get stripped. The system is consistent about it — a mailbox may only wear addresses in domains its own tenant is authoritative for.
The domain lives in one tenant. The mailboxes can live in the other. Something has to carry mail across.
The service domain does the carrying
Every tenant is born with a routing domain that no one else can claim: <tenant>.mail.onmicrosoft.com, alongside the familiar <tenant>.onmicrosoft.com. These are yours forever and they are globally unique, which makes them the natural rails for cross-tenant delivery. During coexistence, the two organizations address each other over these service domains rather than the shared vanity name. A person whose mailbox has moved to northwindtraders.onmicrosoft.com can always be reached there, no matter what their public contoso.com address does. The vanity domain stays parked in the source tenant, still authoritative, still where the world's MX record points — and the routing domain quietly relays anything that needs to reach the far side.
Target addresses and proxy addresses, in plain terms
The mechanism is the same one hybrid Exchange has used for years: a mail user. A mail user is a pointer — a directory entry that looks like a person but holds no mailbox, only a forwarding address to where the real mailbox lives. When a mailbox is moved from the source tenant, Microsoft's process converts the old source mailbox into a mail user and stamps its target address (you will see it as ExternalEmailAddress in Exchange, targetAddress under the hood) with the routing address at the destination. Mail arriving for that person in the source tenant now redirects to their ...onmicrosoft.com address in the target. In the other direction, the target tenant holds a mail user representing each not-yet-moved person, its target address pointing back at the source. Two sets of pointers, one per direction, and mail follows them across the boundary.
Routing is not the only thing riding on those objects. Before a move runs, the target mail user needs the source mailbox's LegacyExchangeDN copied on as an x500 proxy address, plus every other x500 address from the source. Microsoft's guidance is blunt: the move does not proceed if those x500 addresses are missing. They are what lets a reply to an email sent before the migration, and the autocomplete cache in Outlook, still resolve to the right person. Skip them and delivery can fail with a 5.1.1 non-delivery report — mail bouncing off people who are sitting right there.
The cutover, when the domain finally moves
Coexistence is a bridge, not a destination. The end state is every mailbox on the target and the vanity domain owning them there. To get it, you reach the cutover moment: mailboxes are on the target side, and now you remove contoso.com from the source tenant. Removing it is what frees the name — remember, one tenant only — so you can then add and verify it in the target and set it as the primary address for the migrated users. Up to that instant the world's MX record and the domain's authority still sit in the source, and every cross-tenant hop has been leaning on the onmicrosoft.com routing addresses. After it, the target is authoritative and the routing addresses fade into being just backup proxies.
Be honest with yourself about the seam here. Microsoft's native tooling makes the source-to-target routing clean once a mailbox has moved, but a truly transparent share of one domain across two live tenants — where a source user can send as contoso.com while their mailbox already sits in the target — is not something the platform does on its own. Organizations that need that reach for address-rewriting appliances or third-party coexistence services. If someone promises you a clean split domain with no rewriting layer, ask exactly which object is authoritative for the name. There is only ever one.
The takeaway
One domain, one tenant — that constraint is the whole shape of the problem. While mailboxes straddle two tenants, the shared contoso.com stays put in the source, and mail crosses the boundary on the tenants' onmicrosoft.com routing domains, carried by mail users whose target and proxy addresses point at wherever each mailbox lives. Copy the x500 addresses so old replies still land. Then, at cutover, pull the domain from the source and verify it in the target. "The vanity domain never splits; the routing addresses do the coexistence; the domain moves last" is the sentence that tells a hiring manager you have actually run one of these.
Questions people also ask
Can the same domain be verified in two Microsoft 365 tenants at once?
No. Microsoft's own guidance states that domains are associated with one Microsoft Entra ID or Exchange Online tenant only. A custom domain is verified in exactly one tenant, and until it is removed from that tenant no other tenant can claim it. This single constraint is what shapes the entire coexistence design during a cross-tenant move.
How does mail flow between two tenants during a migration?
Each tenant carries a mail user that points to the mailbox in the other tenant. When a mailbox is moved, the source mailbox is converted to a mail user whose target address is stamped with the routing address of the destination. Mail that arrives for that person in the source tenant is redirected to the destination over the onmicrosoft.com service domain.
What is a routing or target address in a tenant-to-tenant move?
The target address, shown as ExternalEmailAddress in Exchange, is the forwarding pointer on a mail user that says where the real mailbox lives. During coexistence it is set to the person's address at the other tenant's onmicrosoft.com domain, for example [email protected]. That routing address is how mail crosses the tenant boundary before the vanity domain moves.
Why must I copy x500 and LegacyExchangeDN addresses to the target?
The move will not proceed unless the LegacyExchangeDN is present on the target mail user as an x500 proxy address, and all x500 addresses from the source mailbox are copied over. Those addresses let replies to older messages, and the Outlook autocomplete cache, still resolve to the person after the move. Miss them and mail to migrated users can bounce with a 5.1.1 error.
When does the custom domain actually move to the new tenant?
At cutover, once mailboxes are on the target side. You remove the domain from the source tenant, which frees it, then add and verify it in the target tenant and set it as the primary address for the migrated users. Until that moment the vanity domain stays authoritative in the source, and all cross-tenant delivery rides on the onmicrosoft.com routing addresses.