Microsoft Entra ID custom domain verification fails despite valid DNS TXT records

The different tenant ID strongly indicates that the domain is already attached to another Microsoft Entra tenant, so determine whether that tenant is managed and accessible before attempting any takeover or removal.

Microsoft Entra permits a custom domain to be verified in only one directory at a time; a valid TXT record does not override that tenant binding.^1^

1. Determine whether the existing tenant is managed

Use a real, existing account associated with the affected domain and open this endpoint, replacing [Email]:

https://login.microsoftonline.com/common/userrealm/******@contoso.com?api-version=2.1

Inspect the JSON response:

• "IsViral": true means the account belongs to an unmanaged or self-service-created tenant.
• Otherwise, it belongs to a managed tenant.
• If no existing domain account is available or the response is inconclusive, do not assume either state; ask Microsoft Support to investigate the tenant ID.

An unmanaged tenant has no Global Administrator and is typically created when a user signs up for a Microsoft cloud service with an organizational email address.^2^

2. If it is a managed tenant

First try organizational accounts that might already administer the conflicting tenant, including accounts held by former IT providers or Microsoft 365 administrators.

If access is recovered:

1. Sign in to the Microsoft Entra admin center and switch to the tenant ID returned by the lookup.
2. Open Entra ID → Domain names and select the domain.
3. Rename or remove users, groups, email addresses, applications, and other objects that reference the custom domain.
4. Create or retain a Global Administrator account using the tenant’s .onmicrosoft.com domain so administrative access does not depend on the domain being removed.
5. Delete the custom domain from the old tenant.
6. In the destination tenant, open Entra ID → Domain names → Add custom domain, add the domain, publish its current TXT challenge, and verify it.

Normal removal requires dependencies to be cleared first. A force deletion can rename referenced users automatically, so it should not be used without assessing the effects on sign-in names and services.^3^

If the managed tenant remains inaccessible, do not call the Graph forceTakeover operation. That operation applies only to unmanaged domains. Open a support case and request investigation by the Data Protection team, which can assist with regaining access to or establishing ownership of a normal tenant.^4^

3. If it is an unmanaged tenant

Choose the takeover method according to its existing services.

External admin takeover

External takeover moves the domain, users, subscriptions, and license assignments into the destination managed tenant. It is supported for specified services such as Exchange Online and Azure Rights Management, but not for service plans containing SharePoint, OneDrive, or Skype for Business.^3^

Before calling Graph, ensure the domain exists as Unverified in the destination tenant and use the TXT challenge generated by that tenant:

Connect-MgGraph -Scopes "Domain.ReadWrite.All"

New-MgDomain -BodyParameter @{
    Id = "contoso.com"
    IsDefault = $false
}

Get-MgDomainVerificationDnsRecord -DomainId "contoso.com"
# Publish the returned TXT value, then:
$body = @{ forceTakeover = $true } | ConvertTo-Json
Invoke-MgGraphRequest -Method POST `
  -Uri "https://graph.microsoft.com/v1.0/domains/contoso.com/verify" `
  -Body $body -ContentType "application/json"

If it is already listed as unverified, omit New-MgDomain. The signed-in account needs Domain.ReadWrite.All; Domain Name Administrator is the least-privileged supported role. forceTakeover succeeds only for an unmanaged tenant after TXT ownership validation.^5^

Internal admin takeover

Use this branch when external takeover is unsupported or when the existing unmanaged tenant should be inspected before moving anything:

1. Create a user context by selecting Start Free on Power BI with an address at the affected domain.
2. Confirm the email verification.
3. Sign in to the Microsoft 365 admin takeover page with that account.
4. Select Yes, I want to be the admin and complete its TXT challenge.
5. After becoming Global Administrator, inventory the tenant’s users, licenses, subscriptions, and services.
6. Create an .onmicrosoft.com Global Administrator.
7. Rename or remove dependencies on the custom domain.
8. In Microsoft 365 admin center → Domains, remove the domain.
9. Add and verify it in the destination Entra tenant.^6^

4. Support channel

From the Microsoft Entra admin center, open Diagnose and solve problems → Self-Service Support → Create a support request. Describe the issue as Microsoft Entra ID / custom domain already in use, request Data Protection involvement, and include:

• Source and destination tenant IDs
• Domain name
• Verification error and timestamp
• Correlation/request IDs
• Evidence of registrar ownership and DNS control

Creating a technical case can depend on the tenant’s subscription or support entitlement. If the Free tenant does not offer technical-ticket creation, use Microsoft Support for business or create the request from a workforce tenant associated with an eligible Azure subscription.^7^

Do not remove records, force-delete the domain, or run forceTakeover until the tenant type and existing workloads are known; those actions can change usernames or interrupt access to existing services.

References

1. Add your custom domain name to your tenant
2. Responding to DSR requests for system-generated logs in Power Apps, Power Automate, and Microsoft Dataverse
3. Take over an unmanaged directory as administrator in Microsoft Entra ID
4. Discover your Microsoft cloud footprint FAQ
5. domain: verify
6. Perform an internal admin takeover
7. Find help and get support for Microsoft Entra