Moving a domain between Microsoft 365 tenants without losing mail
Mailbox content is a data copy and mostly boring. The domain cutover is where mail actually gets lost, and the admin centre will tell you it is fine before it is.
What actually happens
Removing a custom domain from a tenant tears down its mail routing host and rebuilds it under the new tenant. Until that host resolves again, nothing delivers. Expect well over an hour, not minutes.
The admin centre health check is not the readiness signal. Poll the routing host in DNS yourself. That is the real one.
The dangerous window is not the outage
While the routing host does not resolve, senders get a temporary failure and queue. That is safe. Mail sits in their outbound queues and retries.
The danger is the period after the host comes back but before the mail edge servers accept the domain. In that window they reject permanently:
551 5.5.1 Unable to relay non-accepted domainPermanent means no retry. Every queued message drains into bounces at once. Counterintuitively, the safest configuration during a move is MX pointing at something unreachable, so everything queues rather than being rejected.
Probe it properly
Open an SMTP conversation and issue a RCPT TO for a deliberately fake address at the domain:
- 551 means the edge server does not know the domain yet. Not ready.
- 550 means it knows the domain and is correctly rejecting an unknown mailbox. Ready.
Edge servers flip over gradually rather than together, so expect a mixed result for a while. A minority still returning 551 means a minority of senders are still hard bouncing, whatever your message trace shows.
Audit aliases, not usernames
Short secondary addresses often do not appear in the admin centre user list, and are frequently the ones customers actually use. Enumerate the full address list on every mailbox before you move, or you will silently drop live addresses.
When rebuilding them, note that adding an address does not promote it to primary. There is a separate parameter for that, and using the wrong one fails with a confusing complaint about multiple primary addresses.
Registrar automation will undo your preparation
Some registrars auto configure the zone when a domain is added to a tenant. That is helpful for the records it creates and unhelpful when it silently resets the TTLs you lowered in advance. Re-check TTLs after the domain is added, not before.
Anything tenant bound needs rebuilding
Signature managers, compliance tooling and anything else that authenticates against the tenant is bound to the old one. Budget for rebuilding them rather than assuming they follow the domain.
Need help with any of this?
These notes are free and always will be. If you would rather someone just set it up, or you are stuck on something similar, get in touch at hello@opsira.io.