Office 365 DNS Verification Failed: Step-by-Step Fix for TXT and MX Records

Configuring a custom domain in Microsoft 365 (formerly Office 365) is required to route corporate email to Exchange Online, authenticate outbound messages via SPF and DKIM, and enable Microsoft Teams. However, administrators frequently encounter the error: 'We didn't find the DNS records you added' when clicking verify in the Microsoft 365 Admin Center.

Phase 1: Domain Ownership TXT Verification Record

Before Microsoft 365 allows any service configuration, you must prove administrative control over the domain. Microsoft provides a unique verification token formatted as MS=msXXXXXXXX.

1. 1

   1. Configure Host / Name Field

   Set the host field to @ or leave it empty, indicating the root zone apex. If your DNS provider does not accept @, enter your bare domain name (example.com).

2. 2

   2. Paste the Exact Token

   Paste the complete verification string into the TXT value field, including the MS= prefix. Do not add quotes manually unless required by your provider.

3. 3

   3. Set Minimal TTL

   Set the record TTL to 300 seconds (5 minutes) so that any corrections propagate quickly.

Phase 2: Correcting Inbound MX Records for Exchange Online

Once ownership is established, Microsoft requires configuring an MX (Mail Exchanger) record to route inbound email into Exchange Online Protection.

Phase 3: Autodiscover and Client Configuration CNAME

To allow Outlook on Windows, macOS, iOS, and Android to discover server endpoints automatically without manual IMAP/SMTP server configuration, Microsoft requires the autodiscover CNAME record:

Host / Name: autodiscover
Type: CNAME
Points to / Value: autodiscover.outlook.com
TTL: 3600 seconds

Ensure your DNS management panel does not automatically append your domain to the Host field, which creates a broken record at autodiscover.example.com.example.com.

Phase 4: Merging SPF Records (Avoid Multiple v=spf1 Strings)

Microsoft 365 requires adding include:spf.protection.outlook.com to your domain's SPF record. If your domain already publishes an SPF record for another service (e.g., SendGrid, Salesforce, or Zendesk), do not create a second SPF record.

Under RFC 7208 Section 3.2, publishing multiple SPF records triggers an immediate PermError, causing email to fail authentication globally. Combine all authorized senders into a single record:

v=spf1 include:spf.protection.outlook.com include:sendgrid.net -all

Phase 5: Configuring Dual DKIM CNAME Records

To enable DKIM signing in Microsoft 365, configure two CNAME records pointing to Microsoft's domain key infrastructure. This dual-selector architecture enables automated cryptographic key rotation:

Host: selector1._domainkey
Target: selector1-example-com._domainkey.example.onmicrosoft.com

Host: selector2._domainkey
Target: selector2-example-com._domainkey.example.onmicrosoft.com

After publishing both CNAME records, navigate to the Microsoft Defender Security Portal > Email & Collaboration > Policies & Rules > Threat Policies > Email Authentication Settings > DKIM, select your domain, and toggle Sign messages for this domain with DKIM signatures to Enabled.

Phase 6: Teams SRV and Mobile Device Management (Intune) Records

While core mail delivery functions with MX and SPF, the Microsoft 365 Admin Center flags domain setup as incomplete unless optional unified communications and device management records are published:

Direct CLI Verification of All Microsoft 365 Records

Before clicking 'Check again' or 'Verify' in the admin center, run direct command-line queries to verify that every required record is answering publicly:

# 1. Verify Domain Ownership TXT:
$ dig TXT example.com +short | grep "MS=ms"

# 2. Verify Exchange Online MX Record:
$ dig MX example.com +short

# 3. Verify Autodiscover CNAME:
$ dig CNAME autodiscover.example.com +short

# 4. Verify SPF TXT:
$ dig TXT example.com +short | grep "spf.protection.outlook.com"

# 5. Verify DKIM Selectors:
$ dig CNAME selector1._domainkey.example.com +short

Hybrid Deployments, Remote Routing Domains, and DNS Cutover Strategies

For enterprise organizations migrating from on-premises Microsoft Exchange Server to Exchange Online, changing the primary MX record before mailbox synchronization finishes will drop inbound messages. Microsoft Hybrid deployments solve this by introducing a secondary remote routing domain (tenant.mail.onmicrosoft.com).

In a hybrid architecture, your primary public MX record continues pointing to your on-premises edge mail transport servers or secure email gateway (SEG). The on-premises transport server forwards migrated mailboxes across an outbound TLS connector to <tenant>.mail.onmicrosoft.com. Only after the final cutover batch completes do you update your public MX record to <tenant-key>.mail.protection.outlook.com with priority 0.

# Query DNS records directly using native Windows PowerShell cmdlets:
Resolve-DnsName -Name example.com -Type TXT -Server 1.1.1.1 | Where-Object { $_.Strings -like "MS=ms*" }
Resolve-DnsName -Name autodiscover.example.com -Type CNAME -Server 8.8.8.8

# Connect to Exchange Online PowerShell to check accepted domain authentication:
# Connect-ExchangeOnline
Get-AcceptedDomain -Identity example.com | Format-List DomainName, DomainType, OutboundOnly
Get-DkimSigningConfig -Identity example.com | Format-List Domain, Enabled, Status

Check your result and continue troubleshooting

Use the txt lookup tool to inspect the public DNS data relevant to this guide. Record the hostname, query type, resolver and time so you can compare results after a change. This is a DNS check, not a guarantee of worldwide propagation or successful application delivery.

For the underlying behavior and current configuration guidance, consult the official reference. Provider dashboards can change; use the values shown for your own domain rather than copying an example into production.