Moving a domain between Microsoft 365 tenants

Preparing a domain move as a coordinated operation

A Microsoft 365 tenant domain move coordinates identity, email and applications. The domain may appear in sign-in names, primary addresses, aliases, groups and application references. Inventory these uses and define temporary replacements before release. The visible portal user list alone does not describe every dependency.

The cutover plan identifies who acts at source, prepares the destination and modifies DNS. These may be different providers. Verify authorised access, required people and step-by-step tests before the window. Missing credentials or unavailable owners can stop an otherwise technically prepared operation.

Explain changes users will notice: sign-in names, renewed sessions or settings requiring assistance. Check email addresses and access accounts as related but distinct elements. This helps troubleshoot without changing addresses or permissions unrelated to the cause.

Validating the domain after destination association

Administrative verification is a milestone followed by service tests. Check sign-in, recipients, alternative addresses and internal and external mail flow. Also review domain-sending systems and authentication settings for the new design. One delivered email does not validate every path.

Record results by recipient and application, with initial support arrangements. Contingency must reflect the domain’s actual state and data created since transition. An instant return to the starting point cannot be promised without examining changed dependencies and conditions.

What moving a domain between Microsoft 365 tenants means

When discussing moving a Microsoft 365 domain, we normally mean removing a custom domain’s association with the source tenant so it can be added and verified in another tenant. For example: empresa.com is associated with Tenant A and should be used by Tenant B’s users after migration.

The procedure involves more than opening Settings > Domains, selecting removal and adding it elsewhere. Resources must stop using the domain before Microsoft permits removal. Microsoft explicitly documents blocking references in users, groups and certain applications, with additional Exchange Online and collaboration dependencies requiring prior removal or changes.

Official reference: Microsoft – Remove a domain from Microsoft 365.

A tenant domain move is different from registrar transfer or DNS changes

A business may register its domain with Cloudflare, GoDaddy, IONOS, Arsys or another registrar while using Microsoft 365 email. Registrar and DNS hosting may also be separate providers. A Microsoft 365 tenant domain move does not necessarily change registrar or nameservers.

Microsoft explicitly distinguishes the registrar and DNS hosting provider in its documentation. They may be the same company, but need not be. Document control and required change credentials before migration.

The main rule: the same custom domain cannot be verified in two tenants

Microsoft is explicit: the exact same custom domain cannot be added and verified in multiple Microsoft Entra tenants simultaneously. If empresa.com is verified in Tenant A, Tenant B cannot verify it until removal from A. This creates the critical transfer point. Preparation can happen beforehand, but the domain must: leave the source → become available → be added to the destination → be verified → be assigned to objects and services.

There is no normal stage where the same empresa.com is fully operational and verified in both tenants. Official reference: Microsoft – Microsoft Entra Connect supported topologies.

The subdomain exception to understand

Microsoft documents an important distinction: although the same exact domain cannot be verified twice, a subdomain can be verified in a tenant different from its root domain. For example:

Verify the subdomain through its TXT record. This may assist particular identity or transition designs, but subdomains are not an automatic substitute for a migration strategy. Assess email, branding, applications and user experience before adopting temporary subdomains. Official reference: Microsoft – Manage custom domain names in Microsoft Entra ID.

UPN, SMTP and domain: three commonly confused concepts

“User”, “email” and “domain” are often used interchangeably. They are related but different.

UPN and email often match but can differ technically. Domain transfer requires decisions for both. A user may temporarily change from: ana@empresa.com to: ana@tenantorigen.onmicrosoft.com while the domain is released, then receive at destination: ana@empresa.com Design the process so users always understand their sign-in identity and email address.

When a domain needs moving or releasing

Acquisitions commonly trigger domain moves. An acquired company’s domain may remain its email address while users and data move into the parent tenant. A carve-out reverses this: a division leaves an existing tenant and takes its domain into a new organisation.

What can prevent Microsoft 365 domain removal

The Remove domain button works only when Microsoft considers tenant resources no longer need the domain. Current Microsoft 365 documentation requires it not to be the default and not to be used by users, shared or resource mailboxes, contacts, Microsoft 365 groups, distribution lists, teams or administrator accounts.

Entra adds checks for groups with domain email or proxy addresses and applications whose App ID URI contains it.

Administrators count too

An administrator using the domain being removed can block the change. Microsoft recommends performing removal through an account using the initial domain onmicrosoft.com or another domain. If the only Global Administrator uses the retiring domain, prepare another administrator on a different domain before changing that user.

Using onmicrosoft.com during migration

The domain onmicrosoft.com is useful for preparing users and objects before the corporate domain is available. Microsoft assigns an initial tenant domain, for example: empresa123.onmicrosoft.com That initial domain remains associated and cannot be removed. Microsoft currently supports additional onmicrosoft.com domains and choosing one as the fallback domain. The documented limit is five onmicrosoft.com domains in total, which also cannot be removed once created.

This can help where the initial tenant name is unsuitable for transition or a more recognisable namespace is required.

Official reference: Microsoft – Add or replace an onmicrosoft.com fallback domain.

What changes with on-premises Active Directory or Microsoft Entra Connect

Cloud-only user UPNs can be changed directly in Entra ID. Hybrid organisations differ: synchronised objects may retain their source of authority in on-premises Active Directory. Cloud changes may be unavailable or overwritten by synchronisation.

Before cutover, check:

Microsoft also states ForceDelete does not work with federated domains. Modify users and groups through their managing Active Directory first.

DNS during a tenant change

DNS is the visible part of transition but should change only when underlying services are ready. Export or document the current zone and distinguish Microsoft 365 records from other services before cutover.

Official reference: Microsoft – Connect your domain by adding DNS records. TTL helps but does not make changes instantaneous. Lowering relevant TTLs beforehand can shorten retention of old values by some resolvers. It does not force every internet system to update immediately. Intermediate caches and provider behaviour remain outside Microsoft’s or domain administrators’ control.

Do not assume instant propagation when designing transition.

MX and mail flow: avoid premature changes

MX tells sending systems where to deliver domain mail. Its change timing depends on mail flow architecture. Too early and messages reach a destination missing users or mailboxes; too late and messages continue reaching source while users work at destination.

Microsoft also recommends preparing users and mailboxes before directing MX to Microsoft 365 when migrating from other email services. The principle applies here: prepare the destination before changing incoming email.

SPF: do not create two records during a tenant move

SPF causes problems where Microsoft 365, local servers, SaaS apps, marketing, ERP and support systems send through the same domain during migration. The main rule is: only one SPF TXT record should exist per domain or subdomain. Separate Microsoft 365 and external application SPF records do not combine permissions. Microsoft warns that multiple SPF records cause a permerror.

Combine authorised sources in one record while respecting SPF’s DNS lookup limit.

Microsoft recommends complementing SPF with DKIM and DMARC rather than relying on SPF alone against spoofing. Official documentation: Microsoft – Set up SPF for custom domains.

DKIM: do not blindly reuse source tenant settings

DKIM is easily overlooked in tenant migration. Custom domains need Exchange Online signing configuration, including two selector CNAME records supplied by Microsoft. When the domain changes tenant, obtain the target values of those CNAMEs from the new tenant.

Microsoft currently specifies querying values directly through: Microsoft Defender portal or Exchange Online PowerShell. Do not assume old DKIM values remain valid: they reflect configuration and routing for the relevant tenant. Recommended order.

Official reference: Microsoft – Set up DKIM to sign mail from your custom domain.

DMARC: maintaining protection during transition

DMARC resides in DNS rather than belonging directly to a tenant. It relies on SPF and/or DKIM alignment with the From domain. Incomplete cutover settings can make legitimate messages fail DMARC. Identify every sending platform before changing tenant.

Microsoft recommends configuring SPF and DKIM first, then introducing DMARC gradually with monitoring before restrictive policies such as p=reject. Official reference: Microsoft – Set up DMARC in Microsoft 365.

Applications and external services: hidden dependencies

Domain release, Exchange configuration and published DNS can all succeed while a critical application fails because integrations reference the corporate domain.

Entra directly blocks removal where certain applications have an App ID URI containing the domain. Other applications may fail afterwards without blocking removal. Inventory functionality alongside administrative references.

Preliminary assessment before booking the change window

Reduce risk by assessing the domain separately and creating a dedicated inventory.

A simple check that prevents problems. Before cutover, determine whether Microsoft would permit removal and inspect dependencies in the admin centre without completing deletion. Identify unexpected references while there is time to correct them.

Strategies for moving domains during migration

Domain moves need different strategies for different projects. Single cutover. Users and principal services change within one window, with source release and destination addition during that period. Conceptually simpler, it concentrates many changes into a few hours. Waves with the domain moved last.

Premigrate data and prepare users on temporary addresses. Move the corporate domain once most workloads are ready. This reduces outstanding cutover data but requires clear coexistence design. Rebranding. If the corporate domain also changes, strategy may differ. Instead of retaining empresa-antigua.com as the primary address, keep it as an alias or for a transitional period.

Migration can then simplify configuration rather than reproduce it exactly.

Recommended domain release and transfer process

Details vary, but a sound process normally follows this sequence. 1. Prepare the destination tenant. Before touching the domain, prepare as much as possible: temporary-domain users, group assignments, licensing and workload preparation according to tool limitations.

2. Inventory source domain references. Identify UPNs, SMTP addresses, aliases, groups, contacts, teams, applications and synchronised objects. 3. Prepare a temporary namespace. Typically use onmicrosoft.com or another domain remaining at source to temporarily replace references to the corporate domain being released. 4. Change source users and objects.

Update UPNs, addresses and groups still using the domain, respecting the source of authority for synchronised objects. 5. Review Exchange Online. Check shared mailboxes, resource mailboxes, contacts, distribution groups, mail-enabled groups and remaining proxyAddresses. 6. Review applications. Change blocking App ID URIs and prepare affected SSO, SCIM, Graph or SMTP integrations.

7. Change the default domain where necessary. Microsoft does not permit removal of the default domain. Select another before proceeding. 8. Use an independent administrative account. Avoid performing the operation with admin@empresa.com when empresa.com is the domain being removed. Prefer an administrator based on onmicrosoft.com or another domain.

9. Remove the domain from the source tenant. After resolving dependencies, request removal in the admin centre. Microsoft indicates minutes to several hours, potentially up to a day in environments with many references. 10. Add the domain to the destination tenant. Once Microsoft recognises availability, add it and prove ownership through the appropriate verification record.

11. Apply it to users and groups. Set final UPNs, SMTP addresses and aliases. 12. Prepare email authentication. Review SPF, obtain new DKIM selectors and check existing DMARC policy. 13. Change mail flow. Update MX and other routing elements according to design. 14. Validate. Test identity, email, applications and devices before announcing completion.

ForceDelete: its purpose and why it should not be the primary plan

Entra provides a feature called ForceDelete for certain domains with remaining references. It can replace custom domain references with the initial onmicrosoft.com. This shortcut has significant restrictions.

Therefore, ForceDelete should not replace controlled domain clean-up in a planned migration. It may suit specific administrative scenarios, but deliberate reference correction is preferable for tenant migration. Official reference: Microsoft – ForceDelete and custom domain management.

Recommended cutover runbook

Use an operational document specifying who makes each domain change, when and how it is validated.

What to validate after the domain moves

Microsoft showing a domain as Healthy or Verified does not demonstrate complete business operation. Validate several layers. Identity.

Exchange Online.

Email authentication. Send actual messages and inspect headers for: SPF=pass, DKIM=pass and DMARC=pass, where the sending architecture is designed accordingly. Test corporate users, ERP, CRM, marketing and every other domain-sending system. Clients and devices. Some clients may require reauthentication following a tenant change.

Test: Outlook, Teams, OneDrive Sync, mobiles, Microsoft 365 Apps and Intune-managed devices where included.

Common mistakes when moving a domain

Frequently asked questions about Microsoft 365 domains and tenant migration

Does changing tenant require a registrar change?

These are separate operations. The registrar maintains registration, DNS hosting publishes records and the tenant associates Microsoft identities and services. Identify responsibility and required changes for each without confusing tenant migration with registration transfer.

Why might a source domain remain impossible to remove?

Remaining objects or references may still use it. Review users, addresses, groups and relevant dependencies according to service requirements. Without this inventory, troubleshooting is pushed into cutover. Check references and temporary handling beforehand.

Does changing sign-in name update every access route?

Do not assume every application and session updates identically. UPNs, email addresses and application identifiers have different functions. Test the planned account journey and document configurations or sessions requiring intervention.

What should be tested after destination domain verification?

Beyond administrative association, test sign-in, recipients, internal and external sending and reception, aliases and relevant applications. Review designed email authentication. Retain evidence and incident owners because domain verification does not validate every service.

Final recommendations: make the domain a project phase rather than a last-minute task

Moving a domain between Microsoft 365 tenants brings identity, email and DNS together at one project point. The difficulty is not selecting Remove domain, but resolving every dependent user, administrator, mailbox, group, team, alias and application so Microsoft permits removal.

Destination addition and reconstruction are equally important: UPNs, SMTP, MX, SPF, DKIM, DMARC, mail flow, applications and user experience. Current Microsoft documentation adds important details: exact domains cannot be verified twice although some subdomains can be in different tenants; onmicrosoft.com domains cannot be removed; ForceDelete has restrictions; SPF allows one record per domain; and DKIM needs destination-provided values.

The recommended strategy is to prepare as much as possible before cutover, resolve domain dependencies early, document the exact sequence and technically validate every service afterwards.

Recommended official documentation

Microsoft 365 and Microsoft Entra domains.

• Microsoft – Remove a domain from Microsoft 365
• Microsoft – Add a custom domain to Microsoft 365
• Microsoft – Add your custom domain name to Microsoft Entra ID
• Microsoft – Manage custom domain names in Microsoft Entra ID
• Microsoft – Microsoft Entra Connect supported topologies

onmicrosoft.com domains.

• Microsoft – Add or replace an onmicrosoft.com fallback domain

DNS and email.

• Microsoft – Connect your domain by adding DNS records
• Microsoft – External DNS records for Microsoft 365

SPF, DKIM and DMARC.

• Microsoft – Set up SPF for your Microsoft 365 domain
• Microsoft – Set up DKIM for your custom domain
• Microsoft – Set up DMARC in Microsoft 365
• Microsoft – How email authentication works in Microsoft 365

Domains associated with another tenant.

• Microsoft – Remove a domain from another Microsoft 365 account
• Microsoft – Admin takeover of an unmanaged directory