Moving a domain between Microsoft 365 tenants: the outage is not where you expect
Every guide says allow an hour. What none of them say is that the safe state is the one where nothing resolves, and the risk starts when it does.
A domain can only be verified in one Microsoft 365 tenant at a time, so moving one means removing it from the old tenant and adding it to the new. The documented process is straightforward. The failure mode is not.
The MX record does not change, and that is the trap
The MX for a custom domain on Microsoft 365 points at a host derived from the domain name itself, with dots replaced by dashes. It is not tenant specific, so it looks like nothing needs to change. It does not.
What does change is that Microsoft tears that host down when the domain leaves the old tenant and rebuilds it under the new one. For as long as the rebuild takes, the MX record points at a hostname that does not resolve.
Resolve-DnsName yourdomain-com.mail.protection.outlook.com -Server 8.8.8.8NXDOMAIN means no mail can be delivered. In our case that lasted just under an hour.
An unresolvable MX is a temporary failure. Sending servers queue and retry for days rather than rejecting. Nothing is lost while the host is missing.
The dangerous part is when it comes back
Once the host resolves again, queued mail stops waiting and starts connecting. If the tenant is not fully ready it gets a real SMTP answer instead of a DNS failure, and that answer is permanent:
551 5.5.1 Unable to relay non-accepted domainThat is a 5xx. Sending servers do not retry it. Everything that had been queuing safely for an hour drained into bounces in a few minutes. One message we traced had been queued since 08:53, connected at 09:48 the moment the host appeared, and was returned to sender immediately.
The tenant does not agree with itself
This is the part worth internalising. Every check we could run said the domain was correctly configured:
- Domain verified and Authoritative in the new tenant
- Supported services including Email
- Admin centre domain health showing every record OK
- All mailboxes carrying the correct primary addresses
And yet a majority of the mail servers fronting the tenant rejected the domain as unknown, and the mailbox server refused to add proxy addresses on it with a not-accepted-domain error for over four hours. Directory operations succeeded while mailbox operations failed, against the same domain, at the same moment.
Propagation is not a single event. It is dozens of independent systems catching up at their own pace, and the portal only reflects the fastest of them.
What we would do differently
Do it when nobody is working. Not the evening before a busy day. An early Saturday costs nothing if it takes six hours.
Lower TTLs a day ahead, and check they stuck. Ours were reset back to the default by the registrar integration when the domain was added to the new tenant, undoing the preparation without saying so.
Consider pointing the MX at a deliberately unreachable host during the switch. Microsoft own guidance suggests this and it is sound: it forces the safe queuing state rather than leaving it to chance, and you control when delivery resumes.
Audit secondary addresses, not just usernames. Short aliases do not appear in the admin centre user list and are often the ones suppliers actually use. Anything you fail to recreate bounces silently.
Expect the same again for every additional domain. A second domain we moved a day later completed in minutes. Same process, same tenants, wildly different duration. There is no way to predict which you will get.
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.