How do we move an email domain between Microsoft 365 tenants without losing mail?

Key facts

• A domain can be verified in only one Microsoft 365 tenant at a time.
• Every source object using the domain, including groups and aliases, must be changed before the domain can be removed.
• Lowering DNS TTL to 5 to 15 minutes a few days before cutover speeds up the MX switch.
• Sending mail servers queue and retry for many hours, so a short gap delays mail rather than losing it.
• Pre-staging mailboxes means only recent changes move during the cutover window.

Why the domain move needs a cutover window

Microsoft 365 allows a custom domain to be verified in one tenant only. To add contoso.com to the target tenant, it must first be fully removed from the source. Removal fails while any user, group, contact, shared mailbox, alias or SharePoint and Teams reference still uses it.

That means the move is a single event. Between removing the domain from the source and switching MX to the target, mail for that domain has no valid destination. The goal is to keep that gap short and make sure senders queue rather than bounce.

Preparation in the weeks before

Most of the work happens before cutover night. The more is done ahead, the shorter and safer the window.

• Inventory every object in the source using the domain: UPNs, primary SMTP addresses, proxy addresses, groups, shared mailboxes, resource mailboxes and mail contacts.
• Script the rename of all source objects to the tenant's onmicrosoft.com domain and test it on a few accounts.
• Create target users with onmicrosoft.com addresses and pre-stage mailbox content with Cross-tenant mailbox migration or a migration tool.
• Lower TTL on MX, Autodiscover and SPF records to 5 to 15 minutes at least 48 hours before cutover.
• List third-party services tied to the domain: email security gateways, SMTP relays, scanners, CRM and marketing platforms, DKIM selectors and DMARC reporting.
• If Entra Connect syncs the source domain from on-premises AD, plan the attribute changes there, since cloud-only renames will be overwritten.

Cutover sequence

A typical weekend cutover follows the steps below. Exact order varies with hybrid setups and email gateways, so it should be written as a runbook and rehearsed.

• Freeze changes and run a final delta sync of mailbox content.
• Optionally point MX at a holding location or gateway that queues mail, so nothing bounces during the gap.
• Rename all source objects off the domain, then remove the domain from the source tenant.
• Add and verify the domain in the target tenant with the TXT record Microsoft provides.
• Assign the domain to target users and groups as UPN and primary SMTP address, adding old addresses as proxies.
• Update MX to the target tenant's Exchange Online endpoint, then update Autodiscover, SPF and DKIM.
• Send test mail inbound and outbound, release any queued mail and confirm delivery.

Protecting against lost mail

Standard mail servers queue undeliverable messages and retry for many hours before returning a failure. If MX points somewhere that responds with a temporary error, or the gap is short, mail is delayed, not lost. Problems happen when a destination returns a permanent rejection, such as an unknown recipient error from a tenant that no longer owns the domain.

Mail sent internally in the source tenant during the window is the other risk. Freezing user activity, communicating the window clearly and running a final delta after cutover covers most of it.

Replies to old messages are another detail. Add the old LegacyExchangeDN of each source mailbox as an X500 proxy address in the target, so cached Outlook addresses and old meeting threads still resolve.

Avoiding the domain move entirely

Some organizations do not move the domain at all. Users adopt the acquirer's domain, and the old domain stays in the source tenant with forwarding until it is retired, or is moved later in a small, low-risk cutover.

This lets user migration run in flexible waves, since no single date ties every mailbox to the domain switch. The trade-off is a brand and address change for the moved users, which business leaders need to agree to.

How Accred Consulting approaches it

Accred Consulting treats the domain move as its own workstream. During discovery we inventory every object and service that uses the domain, then build a scripted, rehearsed runbook for the cutover window. Mailboxes are pre-staged so the window only handles final changes. Our US-based specialists run the cutover directly, test mail flow and handle the first business morning. The proposal sets scope, a fixed price and a timeline, and handover includes the runbook and DNS records for your records.

Track record: 400+ client projects, 2,000+ migration workstreams and 150,000+ users migrated by a US-based team. Company facts · Case studies

Related questions