Home › Blog › Tenant migration
Guide · Tenant migration
A custom domain lives in one tenant at a time. What has to be true before the weekend, the ten steps in order, and the one DNS mistake that sends every message to spam on Monday.
By Alex Makey · 6 September 2026 · 8 min read · Verified against Microsoft documentation, September 2026
A custom domain can be attached to exactly one Microsoft 365 tenant at a time. That single fact turns a domain move into the most carefully sequenced hour of any tenant migration, and the one where a missed step means bounced mail on a Monday morning. Here is the sequence, what has to be true before you start, and what breaks if you rush it.
Every mailbox has already been migrated. The domain move is the last step, not the first. Content moves while both tenants run on their own domains; the domain follows once the data is in place. If you move the domain first, the target tenant has addresses with no mailboxes behind them and mail bounces.
You know who controls DNS. Not the company — the person, with the login. Cutover is a DNS change, and finding out on Saturday night that the registrar password left with the previous IT provider costs you the weekend.
Every reference to the domain in the source is inventoried. The source tenant will refuse to release a domain that anything still uses. That means every user principal name, every primary and secondary email address, every group, every shared and resource mailbox, every Teams channel email, every application registration that uses an address on the domain. Export the list; you will be editing all of it.
The target has the users, groups and mailboxes ready — on the target’s own .onmicrosoft.com domain or another domain the target already holds. They will be renamed onto the moved domain afterwards.
Users have been told. The domain move is the only part of a migration they see. Tell them the date, the window, and what to do on Monday: sign in with the new address, re-add the account on the phone.
1. Lower the DNS TTLs a few days before. Set MX, autodiscover and the relevant CNAME records to a short time-to-live — five to fifteen minutes — so that when you change them on the day the change propagates fast.
2. Stop mail flow into the source. Point MX at the target tenant first, or at a holding queue, so that mail arriving during the move queues rather than lands in the old mailboxes. Mail sent to a domain during a switch is delayed, not lost, provided nothing bounces it.
3. Rename every source object off the domain. UPNs to the source’s .onmicrosoft.com. Every primary and proxy address that ends in the domain, removed or changed. Groups, shared mailboxes, resource mailboxes, Teams. In PowerShell this is a loop over Get-Mailbox, Get-DistributionGroup, Get-UnifiedGroup and Get-MgUser, editing EmailAddresses and UserPrincipalName. Expect the loop to miss something.
4. Remove the domain from the source. Admin centre → Settings → Domains → Remove. If the domain is still referenced anywhere, the removal is refused and the error names the object. Fix it, try again. This is the step where the inventory from before the weekend earns its keep.
5. Add and verify the domain in the target. Add the domain; Microsoft gives you a TXT record; add it at the registrar; verify. With low TTLs this takes minutes. With default TTLs it can take most of an hour.
6. Set it as the default domain in the target, if that is the plan, so new users get the right address.
7. Rename target objects onto the domain. UPNs and primary addresses for every migrated user, group and shared mailbox. Add the old addresses from the source as secondary proxies if anyone had aliases, so mail to old aliases still arrives.
8. Publish the target’s DNS. MX to the target. Autodiscover CNAME to autodiscover.outlook.com. SPF to the target’s include. Two new DKIM CNAMEs — the selectors are tenant-specific, so the source’s DKIM records are wrong for the target and must be replaced. DMARC stays but check the reporting address still exists. Teams and Skype SRV records if Teams Phone is in use.
9. Enable DKIM signing in the target. Defender portal → Email authentication → DKIM. Until the CNAMEs resolve and signing is enabled, outbound mail is unsigned and some recipients will quarantine it.
10. Test from outside. Send to an address on the moved domain from Gmail. Reply from it. Check the headers for DKIM=pass and SPF=pass. Check autodiscover with Outlook’s connectivity test.
Step 3 skipped: the domain cannot be removed and the weekend is spent finding the shared mailbox nobody knew about.
Step 8 partly done: mail arrives but goes to spam, because SPF or DKIM still describe the source tenant. This is the commonest post-cutover complaint, and it looks like a deliverability problem when it is a DNS one.
Step 2 skipped: mail keeps landing in source mailboxes during the move, and someone has to reconcile the delta afterwards.
Users not told: Monday morning is a support queue of people who cannot sign in because their address changed and nobody said so.
The steps themselves are two to four hours for a mid-sized tenant with the inventory done. DNS propagation with lowered TTLs, under an hour. The whole window fits in a Saturday. What does not fit in a Saturday is discovering the inventory during it — which is why it is done the week before.
One email a month, at most
Postmortems, timelines, licensing changes that cost people money. If a month has nothing worth your time, you hear nothing.
Please enter a work email address.
Done. Unsubscribe by replying to any email; we will not argue.
Related questions
No. A custom domain can be verified in exactly one tenant at a time. It has to be fully removed from the source before it can be added to the target, which makes the move a scheduled cutover rather than a gradual transition.
Because something in the tenant still references it: a user principal name, a proxy address, a group, a shared or resource mailbox, a Teams channel or an app registration. The error names the object. Every reference has to be renamed off the domain first.
Mail sent during the window is delayed, not lost, provided nothing bounces it. Point MX away from the source before removing the domain so mail queues rather than lands in old mailboxes, and run a delta pass afterwards.
Almost always DNS: SPF still includes the old tenant, or DKIM records still point at the source tenant’s selectors. DKIM CNAMEs are tenant-specific and must be replaced, then signing enabled in the target.
After. Move the content while both tenants run on their own domains, then move the domain as the final step. Moving the domain first leaves addresses with no mailboxes behind them.
Rather not do this yourself?
Describe the situation and you get back a sequence, an honest view of what will be slow, and a fixed price — usually within one business day. Or ask one question and get one answer.