Can the same Microsoft 365 custom domain be active in two tenants at the same time?

No. The custom domain must be released from the source tenant before it can be attached to the target tenant. Clear the Microsoft 365 objects that still reference the domain before attempting the removal.

Do I need temporary onmicrosoft.com addresses?

Temporary tenant-specific onmicrosoft.com addresses are useful for keeping source and target identities uniquely addressable while the vanity domain is being released and reassigned. The source tenant's onmicrosoft.com domain itself does not move to the target tenant.

What must be changed before I can remove the custom domain?

Confirm that the domain is not the source tenant's default domain and clear the Microsoft 365 references that still use it, including affected users, administrators, shared/resource mailboxes, contacts, Microsoft 365 Groups, distribution lists, Teams where applicable, and blocking email aliases or addresses reported by Microsoft 365.

When should I change MX records?

Change MX when the custom domain is available in the target tenant and the migration has reached the planned mail-flow cutover. Use the target tenant's Microsoft 365-provided value and verify send/receive behavior after propagation.

How long does domain removal take?

Do not plan around a fixed removal time. The duration depends on whether source references have been cleared and how Microsoft 365 processes the domain release. Treat the domain-release and verification period as part of the controlled cutover window.

Can users continue working during the migration?

Mailbox data can be pre-staged before the domain cutover where appropriate. The domain-transfer window can still cause temporary sign-in or mail-flow disruption, so plan user communications and cutover validation accordingly.

When should I run the final incremental migration?

Run the verified EdbMails incremental/repeat migration after the initial pre-stage and before final sign-off so supported new or changed mailbox items can be processed. Review the migration report before decommissioning source access.

What should I validate after domain cutover?

Verify target-domain status, user sign-in, mail flow, required DNS resolution, Outlook/Autodiscover behavior, migrated mailbox data and EdbMails migration reports. Resolve failed or skipped items before source decommissioning.

Can I migrate shared mailboxes, public folders, and archive mailboxes between two Office 365 tenants?

Yes. EdbMails supports migration of primary mailboxes, shared mailboxes, archive (In-Place Archive) mailboxes, and public folders. Follow the current product prerequisites for each workload.

What happens if the EdbMails migration is interrupted?

Review the migration report, correct the underlying network, throttling, access, or mapping issue, and use the supported EdbMails repeat/incremental migration behavior for supported new or changed items.Resume behavior can depend on the migration state, so follow the current EdbMails documentation for the supported repeat or incremental process.

Download Buy Now

Office 365 Tenant-to-Tenant Migration with the Same Domain

An Office 365 tenant-to-tenant migration with the same custom domain requires two coordinated activities: moving mailbox data and transferring the custom domain from the source tenant to the target tenant. Microsoft does not allow the same custom domain to remain attached to both tenants at the same time, so users and other Microsoft 365 objects that reference the domain must be moved to temporary addresses before the domain can be released from the source. This page focuses on that same-domain preparation and cutover sequence. For the complete EdbMails mailbox-migration click path, use the tenant-to-tenant step-by-step guide.

Office 365 tenant-to-tenant migration with the same domain

Why organizations keep the same domain during a tenant migration
- Organizations may move away from a hosted Microsoft 365 provider so they can manage the tenant directly.
- Mergers, acquisitions, divestitures, restructuring, and tenant consolidation can require a move to another Microsoft 365 tenant while retaining the existing customer-facing domain.
- Keeping the established domain preserves familiar email addresses and brand continuity for users, customers, suppliers, and partners.
- Retaining the domain can reduce the user-facing change associated with adopting a completely new email domain, but the cutover still requires planning for sign-in and mail-flow readiness.
For broader migration-planning considerations, see cross-tenant Office 365 migration. For commercial product evaluation, see the Office 365 tenant-to-tenant migration tool.
Before you start a same-domain tenant migration
- EdbMails migration preparation: Confirm source and target tenant access, the mailboxes in scope, the source-to-target mapping plan, the migration workstation/network, and the supported repeat/incremental workflow.
- Microsoft domain-transfer requirements: Confirm the custom domain is not the source tenant's default domain at cutover and identify every Microsoft 365 object that still references the domain.
- Temporary addresses: Ensure source identities that must continue operating during cutover can use appropriate tenant onmicrosoft.com addresses; prepare target users/mailboxes using temporary target addresses before vanity-domain assignment.
- Cutover plan: Document the DNS settings before change, define a go/no-go window, identify who can make registrar/DNS changes, and decide when the final incremental mailbox pass will run.
- User readiness: Plan sign-in, Outlook/mobile, mail-flow testing and user communications for the cutover window.
Cutover risk: Plan a controlled cutover window for a same-domain migration. Mailbox data can be pre-staged before the domain transfer, but the custom domain itself must be released from the source tenant before it can be added to the target tenant. The duration of the cutover depends on how quickly source references are cleared, the domain is released and verified, required DNS changes propagate, and users can sign in and resume mail flow in the target environment. Do not promise zero downtime or instant propagation; prepare users for a possible period of mail-flow or sign-in disruption during the domain-transfer window.

Same-domain tenant migration and cutover sequence

Step 1: Inventory the domain dependencies

Identify the mailboxes, users, administrator accounts, aliases, groups and DNS records that use the custom domain. Record the current DNS values and confirm who has access to both Microsoft 365 administration and the DNS provider.

Step 2: Prepare the target tenant with temporary addresses

Prepare the target recipients with temporary target addresses and confirm the target licensing and prerequisites required for your migration design.

Step 3: Pre-stage mailbox data

Where operationally appropriate, run the initial EdbMails mailbox migration before the custom-domain cutover. This reduces the volume that must be handled during the final cutover window. Use the Office 365 tenant-to-tenant migration step-by-step guide for the complete EdbMails source connection, target connection, mapping, migration, reporting, and validation workflow.

Step 4: Move source identities off the vanity domain

Use tenant-specific onmicrosoft.com addresses as temporary identities while the vanity domain is being released and reassigned. The temporary addresses keep source and target objects uniquely addressable during the cutover; the original source tenant's onmicrosoft.com domain itself does not move to the target tenant. Prepare and test the temporary sign-in/mailbox access before the cutover window so administrators are not dependent on the vanity domain while it is being transferred.

Open the Microsoft 365 Admin Center.
Select Users > Active users.
Select the affected users.
Use the available domain-change action in the Microsoft 365 admin center to move affected source identities away from the custom domain.
Use the appropriate source tenant onmicrosoft.com address or another verified temporary address for the cutover design.

Step 5: Clear source-tenant references before removing the custom domain

Before the custom domain can be removed from the source tenant, clear the Microsoft 365 references that still use it. Use the Microsoft 365 admin center to confirm the domain is no longer the default and that the objects below no longer reference it.

Active users and their sign-in/user principal names where applicable.
Administrator accounts that sign in with the custom domain.
Shared mailboxes.
Resource mailboxes.
Contacts.
Microsoft 365 Groups.
Distribution lists.
Teams that reference the domain through Microsoft 365 Groups where applicable.
Email aliases or other addresses shown by Microsoft as blocking the domain-removal operation.

Important: Do not remove the custom domain until Microsoft 365 reports that the blocking references have been cleared.

Step 6: Release the custom domain from the source tenant

In the Microsoft 365 admin center, open the Domains area.
Select the custom domain that is being transferred.
Use the domain-removal action only after Microsoft 365 no longer reports blocking references.

Do not rely on a fixed domain-removal time. The release can be delayed when Microsoft 365 still finds references to the domain or while the service processes the change.

Step 7: Add and verify the custom domain in the target tenant

Add and verify the custom domain in the target Microsoft 365 tenant and make it available for the planned target identities. If Microsoft reports that the domain is still associated with another tenant, stop the cutover and resolve the remaining source-side dependency or Microsoft tenant association before proceeding.

Step 8: Update mail flow and DNS for the target tenant

Apply only the DNS records required for the target Microsoft 365 service configuration. Do not remove or replace unrelated DNS records without verifying the target tenant requirements.

Record / setting	When relevant	Target action	Verification / risk
TXT verification	When Microsoft requests ownership proof for the transferred domain.	Publish or retain the Microsoft verification value required for the target tenant.	Verify the exact Microsoft value before changing DNS.
MX	When Exchange Online mail flow should switch to the target.	Point MX to the target tenant's Microsoft 365-provided value.	Test inbound and outbound mail after propagation.
Autodiscover	When Outlook discovery uses DNS for the moved domain.	Use the target Microsoft 365 Autodiscover configuration if required.	Validate Outlook connectivity after cutover.
SPF	When the domain sends through Microsoft 365 or other approved senders.	Update SPF only to reflect the final authorized sending services.	Avoid multiple SPF records and account for third-party senders.
DKIM	If DKIM signing is enabled for the domain.	Configure or enable DKIM for the target tenant according to current Microsoft guidance.	Review the target tenant’s DKIM selector and CNAME requirements rather than reusing the source-tenant configuration automatically.
DMARC	If DMARC is already published or planned.	Review alignment after SPF/DKIM changes; change only if required.	Incorrect policy or alignment can affect legitimate mail.
CNAME / other service records	Only when required by target services.	Use the records Microsoft 365 shows for the target domain.	Do not publish every possible record by default.

For Microsoft DNS setup guidance, see steps to add DNS records for your Microsoft 365 domain.

Step 9: Assign the transferred domain to target identities

After the custom domain is available in the target tenant, update the planned target users and mailboxes to use the transferred vanity-domain addresses and sign-in identities.

Step 10: Run the final incremental migration

If source mailboxes received new or changed data after the initial pre-stage, run the supported EdbMails incremental/repeat migration before final sign-off. Review the migration report and confirm that the supported new or changed items have been processed. If a migration is interrupted, review the migration report and use the supported EdbMails repeat or incremental migration process for eligible new or changed items.

Review EdbMails incremental migration for the current supported behavior.

Step 11: Validate the same-domain cutover

Confirm the custom domain appears and is verified in the target tenant.
Confirm the target users/mailboxes have the expected vanity-domain addresses and sign-in identities.
Confirm representative users can sign in to the target environment.
Send and receive test messages for migrated users after the MX/mail-flow cutover.
Confirm the target MX record and other required DNS records resolve as intended.
Confirm Outlook/Autodiscover behavior for representative users and recreate profiles only if required.
Review EdbMails migration reports and resolve failed or skipped items.
Run the verified incremental/repeat migration if source mailboxes received changes after the initial pass.
Verify migrated mailbox data for representative users before sign-off.
Do not cancel source subscriptions or remove remaining source access until technical and business validation is complete.

Step 12: Complete source decommissioning only after validation

A same-domain cutover has a point where the vanity domain is no longer attached to the source tenant, so rollback is not equivalent to undoing a file copy. Use a controlled contingency plan instead of relying on a guaranteed rollback.

Document the current DNS values before cutover.
If operational policy permits, reduce relevant DNS TTL values in advance so planned changes can propagate more predictably.
Keep source data and administrative access available until target validation is complete.
Define explicit go/no-go checkpoints before removing the domain from the source and before cancelling source licenses.
Have Microsoft 365 admin access and registrar/DNS access available during the cutover.
If domain release or verification fails, stop the next irreversible step and resolve the blocking source reference rather than repeatedly changing DNS.

Remove source licenses or remaining references only after technical and business sign-off.

Frequently Asked Questions (FAQs)

Can the same Microsoft 365 custom domain be active in two tenants at the same time?
No. The custom domain must be released from the source tenant before it can be attached to the target tenant. Clear the Microsoft 365 objects that still reference the domain before attempting the removal.
Do I need temporary onmicrosoft.com addresses?
Temporary tenant-specific onmicrosoft.com addresses are useful for keeping source and target identities uniquely addressable while the vanity domain is being released and reassigned. The source tenant's onmicrosoft.com domain itself does not move to the target tenant.
What must be changed before I can remove the custom domain?
Confirm that the domain is not the source tenant's default domain and clear the Microsoft 365 references that still use it, including affected users, administrators, shared/resource mailboxes, contacts, Microsoft 365 Groups, distribution lists, Teams where applicable, and blocking email aliases or addresses reported by Microsoft 365.
When should I change MX records?
Change MX when the custom domain is available in the target tenant and the migration has reached the planned mail-flow cutover. Use the target tenant's Microsoft 365-provided value and verify send/receive behavior after propagation.
How long does domain removal take?
Do not plan around a fixed removal time. The duration depends on whether source references have been cleared and how Microsoft 365 processes the domain release. Treat the domain-release and verification period as part of the controlled cutover window.
Can users continue working during the migration?
Mailbox data can be pre-staged before the domain cutover where appropriate. The domain-transfer window can still cause temporary sign-in or mail-flow disruption, so plan user communications and cutover validation accordingly.
When should I run the final incremental migration?
Run the verified EdbMails incremental/repeat migration after the initial pre-stage and before final sign-off so supported new or changed mailbox items can be processed. Review the migration report before decommissioning source access.
What should I validate after domain cutover?
Verify target-domain status, user sign-in, mail flow, required DNS resolution, Outlook/Autodiscover behavior, migrated mailbox data and EdbMails migration reports. Resolve failed or skipped items before source decommissioning.
Can I migrate shared mailboxes, public folders, and archive mailboxes between two Office 365 tenants?
Yes. EdbMails supports migration of primary mailboxes, shared mailboxes, archive (In-Place Archive) mailboxes, and public folders. Follow the current product prerequisites for each workload.
What happens if the EdbMails migration is interrupted?
Review the migration report, correct the underlying network, throttling, access, or mapping issue, and use the supported EdbMails repeat/incremental migration behavior for supported new or changed items. Resume behavior can depend on the migration state, so follow the current EdbMails documentation for the supported repeat or incremental process.

Additional resources:

In this manual

Introduction Reason for O365 tenants O365 migrating same domain

Office 365 Migration

100 Mailboxes $299 Only

Buy Now

Need help?

24/7 Customer support

Personalized Demo

Book a personalized demo

Still need help?

Email us / Call us