Adding a domain to Microsoft 365: verification, DNS records and "already added" errors

Adding a custom domain to Microsoft 365 is usually quick: prove you own it with a TXT record, then add the records for mail and the other services. When it stalls, it's because the verification record can't be found, the domain is already verified in another tenant, or the service records clash with what's already in DNS. In this post I'll take each of those in turn, including the documented ways to release a domain from another organization, and show how to prove the setup is right.

Symptoms#

• The Add domain wizard in the Microsoft 365 admin center can't verify the TXT record you added.
• The wizard confirms you own the domain but refuses to add it, with a message such as We have confirmed that you own contoso.com, but we can't add it to your account because the domain is already added to a different Microsoft 365 organization. It names the other organization and one of its admins, and suggests signing in there to remove the domain or contacting support.
• The domain is verified, but the DNS records step still reports missing or incorrect records, or mail keeps arriving at the old provider.
• After adding the Microsoft 365 SPF record, messages from the domain show spf=permerror in their headers.

Why it happens#

• Verification uses a TXT record with a value like MS=ms18939161 at the root of the domain. It fails when the record was added at the wrong host name, at a DNS provider that isn't authoritative for the domain, or before it has propagated.
• "Already added" means the domain is verified in another Microsoft Entra tenant: a domain can be verified in only one at a time. That tenant may be an old subscription, one run by a former partner, or an unmanaged ("shadow") directory created automatically when someone signed up for a self-service Microsoft service with a work email address. Unmanaged directories have no Global Administrator.
• Service records fail when an old MX record outranks the new one, the values were retyped instead of copied, or a second SPF record was created: SPF allows only one, so two cause spf=permerror.

How to fix it#

1. Make the verification record visible#

Find out which DNS servers are authoritative for the domain, add the TXT record there with the host set to @ (or blank, depending on the provider), then query those servers directly:

Resolve-DnsName -Name contoso.com -Type NS
Resolve-DnsName -Name contoso.com -Type TXT -Server ns1.example-dns.net   # one of the NS names above

When the MS=ms... value appears, select Verify again; propagation can take a while. With Microsoft Graph PowerShell (the Domain.ReadWrite.All scope; Domain Name Administrator is the least privileged role that can verify domains):

Connect-MgGraph -Scopes 'Domain.ReadWrite.All'
New-MgDomain -BodyParameter @{ Id = 'contoso.com' }     # skip if the domain is already listed
(Get-MgDomainVerificationDnsRecord -DomainId 'contoso.com' |
    Where-Object RecordType -eq 'Txt').AdditionalProperties.text
Confirm-MgDomain -DomainId 'contoso.com'

2. Release a domain that's already added elsewhere#

Which route applies depends on the other tenant:

• A managed tenant you can reach: sign in there as the admin the message names (reset the password if you need to), move users and groups off the domain by renaming them to the .onmicrosoft.com domain, then remove it under Settings › Domains. A forced removal renames remaining users automatically. Wait for the removal to finish, then add the domain to your tenant.
• An unmanaged (shadow) directory: do an internal admin takeover. Microsoft's documented path is to sign up for a self-service service such as Power BI with an address at the domain, sign in to the Microsoft 365 admin center with that account, accept the offer to become the admin, and add the TXT record it gives you. You're then Global Administrator of that directory, so you can remove the domain there and add it to your own tenant. Nothing is migrated in an internal takeover.
• External admin takeover moves users, subscriptions and license assignments into your tenant, but it isn't supported for any service whose plans include SharePoint, OneDrive or Skype for Business, which rules it out for most Microsoft 365 cases. Where it is supported, Confirm-MgDomain can't do it; Microsoft documents calling the Graph domain: verify API with forceTakeover set to true, after which the unmanaged directory is deleted 10 days later.
• A managed tenant you can't access, such as one held by a former reseller: ask its admins to remove the domain, or open a support request from the Microsoft 365 admin center, as the error message suggests.

3. Add the service records and let the admin center check them#

Go to Settings › Domains, select the domain, then DNS records › Manage DNS. In the wizard, keep Exchange and Exchange Online Protection selected and use Advanced options for extras such as DKIM or Intune and Mobile Device Management for Microsoft 365. If your registrar supports Domain Connect, the records are added for you; otherwise add them by hand:

Create users and mailboxes before you switch the MX record, because new mail starts flowing to Microsoft 365 as soon as it takes effect. Then return to the wizard and select Continue: Microsoft 365 checks the records and shows Domain setup is complete when they're right. DKIM and DMARC come next; see SPF, DKIM and DMARC for your Microsoft 365 custom domain.

Verify the fix#

Get-MgDomain -DomainId 'contoso.com' | Select-Object Id, IsVerified, SupportedServices
Resolve-DnsName contoso.com -Type MX
Resolve-DnsName autodiscover.contoso.com -Type CNAME
Resolve-DnsName contoso.com -Type TXT | Where-Object { $_.Strings -like 'v=spf1*' }

• IsVerified is True and the domain lists the services you set up.
• The MX lookup returns the Microsoft 365 value at the best priority, and exactly one SPF record comes back.
• A test message sent from an outside mailbox arrives in the user's Microsoft 365 mailbox, and a reply sent back shows spf=pass in its headers.

Prevent it next time#

• Add and verify your domains before creating users, so self-service sign-ups land in your managed tenant instead of an unmanaged one.
• Keep a record of which tenant holds each domain and who its admins are, and remove domains from trial or test tenants when you finish with them.
• Copy record values from the admin center rather than reusing values from older guides, and keep a single SPF record.
• If you relay mail through Exchange Online for a domain, make sure it's added and verified first; otherwise you'll meet NDR 550 5.7.750.

References#

• Connect your domain by adding DNS records
• Take over an unmanaged directory as administrator in Microsoft Entra ID