The Domain Cutover in a Microsoft 365 Tenant-to-Tenant Migration: Why It Is the One Unavoidable Outage, and How an MX Spooler Keeps Mail Flowing
In a Microsoft 365 tenant-to-tenant migration almost everything can be staged: mailboxes pre-synced for weeks, files copied in the background, Teams rebuilt before anyone moves. The email domain cannot. A custom domain is verified in one tenant at a time, so there is a window in which it belongs to neither. This is what that window looks like, how long it really is, what happens to mail arriving during it, and how an MX spooler keeps it from bouncing; the notes come from a holding-company consolidation we ran this year, anonymized.
Why the domain cutover is the one unavoidable outage
A custom domain can be verified in only one Microsoft 365 tenant at a time; our no-downtime migration page states the same constraint from the other side. Everything else tolerates overlap: mailbox content is pre-staged (the standard service moves mail older than 30 days first), files copy while people keep working, Teams is recreated before cutover. The domain is either here or there.
Removing it is not one click either. Exchange Online will not release a domain while any object still references it, so every primary SMTP address, alias, user principal name, group and Exchange object carrying it must first be rewritten, usually to the tenant's .onmicrosoft.com address. Only then does the removal go through, only then can the destination add and verify the domain, and only then can every user and mailbox there get it back.
That sequence is the outage: realistically 30 minutes to three hours of the domain being attached to neither tenant, depending on how many objects reference it. The standard cutover service page states the conservative planning figure, about 24 hours during which incoming mail may not be received because of domain-name binding in Exchange Online; the gap between the two numbers is margin for DNS propagation and sender behavior, which nobody controls.
The cutover, in order
The order matters more than the tooling. This is the sequence, with the domain window in the middle:
- Confirm Global Administrator on both tenants and DNS zone access, both prerequisites on every tenant-to-tenant service page; borrowing an admin at the last minute is how a three-hour window becomes a day.
- Finish and verify the pre-stage migration.
- Lower the MX TTL days ahead and, if a spooler is used, point MX at it.
- In the source tenant, export and then rewrite every reference to the domain: primary SMTP addresses, aliases, UPNs, groups, Exchange objects.
- Remove the domain from the source tenant.
- Add the domain to the destination tenant and verify it with the TXT record.
- Reassign the domain: UPNs and primary SMTP addresses on users, shared mailboxes and groups.
- Publish MX (or repoint it from the spooler), SPF, DKIM, DMARC and Autodiscover for the destination.
- Run the final mailbox pass (recent mail, calendars, contacts, rules), release the spooler queue, and verify mail in both directions.
Steps 4 through 8 are the window; the table below shows what happens to a message arriving during each.
What happens to inbound mail, and how the MX spooler works
During the window most sending servers queue the message and retry for hours or days; some retry briefly, and a few return a non-delivery report at the first failure. Without protection some of the mail sent during the window bounces, you never learn which, and the sender assumes you are gone.
The MX spooler removes that uncertainty: an Exchange server we deploy and host in Azure for the duration of the migration. Before the window, MX is pointed at it, so it accepts and holds every inbound message; when the domain is live in the destination and mail flow is confirmed, the queue is released and MX is pointed at the destination. The MX Spooler Service is $2,890 per project for a 14-day hold-and-release engagement alongside a tenant-to-tenant migration, transport rules, connectors and MX values included. Held mail is delayed until release, by design; the stated success criterion is that no incoming message is lost.
It is worth it whenever a customer-facing address is in play: a shared support mailbox receiving orders, claims or client instructions cannot absorb an unknown number of bounces, and that is the case we recommend it for. For an internal-only domain cut over on a weekend night with a lowered TTL, the standard service's risk may be acceptable.
The other packaging is the migration without downtime and bounced email service, $1,400 plus $25 per mailbox, which builds proxy services for inbound mail into the migration itself and quotes a receipt delay of about three to five minutes.
DNS: where the zone lives does not matter; keeping access does
Where the zone is hosted, at the registrar, a DNS provider or Azure DNS, makes no difference. What matters is that someone with access is available on cutover day and the week after, because the records change several times: the verification TXT record, MX (twice if a spooler is used), SPF, the DKIM selector records the destination tenant issues, DMARC, and Autodiscover. Every tenant-to-tenant service page lists DNS zone access as a prerequisite; the MX change itself is the client's, with us supplying the values.
Publish authentication in the right order: a domain whose SPF or DKIM records still describe the source tenant fails authentication from the destination and lands in junk during your most visible week. SPF, DKIM and DMARC for Microsoft 365: the setup order is the sequence. Lower the MX TTL days ahead, not on the day.
What does not affect the cutover, and what to inventory first
Three worries that do not change the plan:
- Shared mailboxes migrate in the same Microsoft-native cross-tenant batches as user mailboxes, permissions inventoried and re-applied. Shared Mailbox Tenant-to-Tenant Migration is $35 per mailbox plus a $500 tenant fee and needs no special handling at the cutover beyond being on the reassignment list; per that page, each migrating mailbox needs a Cross-Tenant User Data Migration add-on license.
- Two billing accounts in the source tenant, a Microsoft Customer Agreement account alongside an older MOSA account, have no effect; billing and the tenant are separate things.
- Which partner holds the subscriptions: price the CSP billing transfer and the one-time migration separately; one is paperwork, the other engineering.
What moves the quote is the inventory, so do it first. The Tenant Optimizer scan (read-only, Global Administrator required) returns an Excel workbook covering users including guests, mailboxes including shared ones, devices, Teams, SharePoint sites and OneDrive: the counts every migration line is priced on. The Migration Estimator turns them into the fixed-price lines at the prices printed on their pages: mail at $35 per mailbox plus a $3,500 tenant fee, SharePoint at $100 per site plus $2,500, OneDrive at $10 per user plus $1,500, Teams at a $3,500 tenant fee plus a per-team fee. The domain cutover is a step inside the mail line; the spooler is a line of its own.
Tenant-to-tenant migration after a merger covers the wider program.
Frequently asked questions
Can the domain stay in both tenants during a coexistence period?
No. A custom domain is verified in one tenant at a time, which is why the window exists; coexistence is done with mailbox pre-staging and, where needed, the spooler.
How long is inbound email actually down?
Realistically 30 minutes to three hours; the standard service plans for about 24 hours of possible inbound impact to allow for DNS propagation and sender retries. With the spooler in front, inbound mail is held rather than refused throughout.
Do we need the MX spooler if our TTLs are low and we cut over at night?
Not always. It is recommended when a customer-facing shared address is in play, because sender retry behavior is outside anyone's control and an unknown number of bounces is a business problem.
Does it matter that our DNS is at the registrar rather than a dedicated DNS host?
No. Zone location is irrelevant; uninterrupted access is not, because the records change several times across cutover week.
Who needs to be Global Administrator?
The engineer running the migration, on both tenants; both tenant-to-tenant service pages list it as a prerequisite. If two companies each hold their own tenant, arrange the second role early.
Sources
- IT Partner service pages (content/services/): Microsoft 365 Tenant-to-Tenant Cutover Email Migration (ITPWW170MIGOT); the Without Downtime and Bounced Email variant (ITPWW380MIGOT); MX Spooler Service (ITPWW530MIGOT); Shared Mailbox Tenant-to-Tenant Migration (ITPWW570MIGOT); SharePoint Online, OneDrive and Microsoft Teams Tenant-to-Tenant Migration: scope, prerequisites, limitations, price
- IT Partner tool pages: Tenant Optimizer (src/app/tools/tenant-optimizer/page.tsx); Microsoft 365 Migration Estimator (src/app/tools/migration-estimator/page.tsx)
- IT Partner blog posts (content/blog/new/): Tenant-to-Tenant Migration After a Merger; SPF, DKIM and DMARC for Microsoft 365
- IT Partner engineering notes, September 2026
| Step | Where | What happens to a message arriving now | Who |
|---|---|---|---|
| Lower the MX TTL; point MX at the spooler | Public DNS | Delivered to the source until DNS propagates, then held by the spooler | Client changes DNS with our values |
| Rewrite every reference to the domain | Source tenant | Held by the spooler; without one, most senders retry and some bounce | IT Partner |
| Remove the domain | Source tenant | Same | IT Partner |
| Add and verify the domain | Destination tenant and public DNS | Same | IT Partner; client publishes the TXT record |
| Reassign UPNs and primary SMTP addresses | Destination tenant | Same | IT Partner |
| Publish MX, SPF, DKIM, DMARC and Autodiscover | Public DNS | New mail reaches the destination as DNS propagates | Client with our values |
| Release the spooler queue; final mailbox pass | Spooler and both tenants | Held mail delivered to the destination; nothing lost | IT Partner |
| Verify both directions on every device type | Destination tenant | Normal | IT Partner and client |
Key takeaways
- A custom domain lives in one tenant at a time, so the cutover has an unavoidable window of 30 minutes to three hours in which it belongs to neither; the standard service plans for about 24 hours.
- The order is fixed: strip every reference in the source, remove, add and verify in the destination, reassign, then publish DNS; export the address list before you start.
- Without protection some senders bounce and you never learn which; the MX spooler, an Exchange server hosted in Azure for the migration, holds inbound mail and releases it when the destination is live ($2,890 per project).
- Zone location does not matter; keeping DNS access does, because TXT, MX, SPF, DKIM, DMARC and Autodiscover all change during cutover week.
- Shared mailboxes need no special handling, two billing accounts change nothing, and the Tenant Optimizer inventory sizes the quote before anyone names a date.
Before a cutover date is set, run the Tenant Optimizer scan and put the counts into the Migration Estimator; it lists the mail, SharePoint, OneDrive and Teams lines at the prices on their pages, and the MX Spooler Service ($2,890 per project) is the line to add when a customer-facing address cannot afford a bounce. Every line is quoted in writing before work begins and paid after you approve delivery; Microsoft licenses in the destination tenant are billed separately at Microsoft's list price.
Questions this article didn’t answer?
Thirty minutes with Mike — our CEO, not a sales rep. Bring the hard version of the question.