Microsoft 365 DNS Checker

Enter a domain hosted on Microsoft 365 / Exchange Online. We check the records that matter for an M365 tenant: SPF includes spf.protection.outlook.com, DKIM selector1 and selector2, DMARC, an MX pointing to *.mail.protection.outlook.com, MTA-STS, and Autodiscover.

Try an example: siemens.com · absa.co.za · nedbank.co.za · accenture.com

Frequently Asked Questions

Common questions about Microsoft 365 DNS configuration.

The minimum is:

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

Add any other services that send as you (Mailchimp, Salesforce, an ERP outbound relay) by appending their includes. Watch the 10-lookup limit, because spf.protection.outlook.com alone burns three.

-all is the right qualifier once you've audited every sender. ~all is acceptable while you're still working out who else is sending as the domain, but it's not a permanent home.

Always selector1 and selector2, both published as CNAMEs. Domains added since May 2025 point into dkim.mail.microsoft; older ones point into onmicrosoft.com:

selector1._domainkey  CNAME  selector1-<domain-token>._domainkey.<tenant>.<x>-v1.dkim.mail.microsoft
selector2._domainkey  CNAME  selector2-<domain-token>._domainkey.<tenant>.<x>-v1.dkim.mail.microsoft

selector1._domainkey  CNAME  selector1-<domain-token>._domainkey.<tenant>.onmicrosoft.com
selector2._domainkey  CNAME  selector2-<domain-token>._domainkey.<tenant>.onmicrosoft.com

<tenant> is your initial onmicrosoft.com prefix and <x> is a letter Microsoft assigns. Neither can be worked out from DNS. Microsoft rotates the live key between the two selectors, so both CNAMEs have to be there. Then switch DKIM signing on in the Defender portal. Until you do, the records look right and outbound mail is not signed with your domain.

The M365 MX is <domain-token>.mail.protection.outlook.com, and the token is the same one the DKIM CNAMEs use. For a domain with no hyphen, it is the domain with dots swapped for dashes:

example.com.  MX  0  example-com.mail.protection.outlook.com.

A hyphenated domain is different. Microsoft drops the hyphens and adds a short suffix that records where they were. As published on 20 October 2026:

dig +short MX 7-eleven.com
0 7eleven-com0c.mail.protection.outlook.com.

dig +short MX b-and-q.co.uk
0 bandq-co-uk0cc.mail.protection.outlook.com.

So never build the value by hand. Copy it from the domain's DNS records page in the Microsoft 365 admin centre. The DKIM check above compares your CNAME targets with the token for your domain. How the suffix is built, with six live examples you can dig: why your Microsoft 365 DKIM record lost its hyphen.

Microsoft hosts the policy file for you at mta-sts.<tenant>.onmicrosoft.com. On your custom domain, publish a CNAME pointing at it:

mta-sts.example.com  CNAME  mta-sts.<tenant>.onmicrosoft.com

You also need the _mta-sts.<domain> TXT record with a version and id. MTA-STS doesn't replace SPF or DKIM. It blocks opportunistic-TLS downgrades on inbound mail, which is a separate category of attack.

Publish a CNAME from autodiscover.<your-domain> to autodiscover.outlook.com. Without it, new Outlook clients fall back to probing the root domain over HTTPS. That sometimes works, often throws a certificate warning, and is the source of most "Outlook won't connect on a new laptop" tickets.

The CNAME is one record. Publish it.

How this Microsoft 365 DNS checker works

A working Microsoft 365 tenant rests on about half a dozen DNS records. Each one has to sit where Microsoft expects it. Miss the MX and inbound mail dies. Miss the DKIM CNAMEs and DMARC fails silently. Miss Autodiscover and new Outlook clients sit on the connect screen for thirty seconds before giving up.

Type a domain above and the tool runs every M365-specific check in one pass. For each row you get what Microsoft expects, what's actually published, and the exact change to make if the two disagree.

Which records does the tool check?

Eleven lookups, all against the live DNS for your domain: 

MX           → <tenant>.mail.protection.outlook.com
SPF          → include:spf.protection.outlook.com
DKIM         → selector1 and selector2 CNAMEs into Microsoft 365
DMARC        → _dmarc TXT published with a policy
MTA-STS      → _mta-sts TXT + policy file on mta-sts.<domain>
TLS-RPT      → _smtp._tls TXT with a rua= mailbox
Autodiscover → autodiscover.<domain> CNAME to autodiscover.outlook.com
BIMI         → default._bimi TXT, if you publish a logo
Teams SRV    → _sip._tls and _sipfederationtls._tcp

DKIM and Teams take two lookups each. The Teams row only shows up when one of the two SRV records exists.

Publishing the CNAMEs is half the job. Signing is a separate toggle in the Defender portal, switched on per domain once Microsoft 365 has found the CNAMEs. Until it's on, Microsoft 365 doesn't sign that domain's mail with its own keys.

Why is the MX hostname so strangely formatted?

Microsoft derives the inbound hostname from your verified domain by swapping the dots for hyphens. So example.com becomes: 

example-com.mail.protection.outlook.com

The exact value is shown in the M365 admin centre under your domain's DNS records. Copy it from there rather than guessing, because tenants that were migrated between regions occasionally end up with a non-obvious value.

Why does a DKIM selector show "has no key" when the CNAME is there?

The CNAME points at the target Microsoft 365 builds for your domain, but no key answers there. The likely cause is that DKIM was never set up for the domain in the Defender portal. DNS can't see that setting, so the card says "probably".

A green DKIM row means the key is published. Whether your mail is signed shows up only in a received message. Send yourself one and read its Authentication-Results header. This means signing is off: 

dkim=none (message not signed)

What to do: in the Defender portal, open Email & collaboration → Policies & rules → Threat policies → Email authentication settings → DKIM, pick the domain, and switch on Sign messages for this domain with DKIM signatures. Microsoft says the change can take several minutes to sync.

Why this matters

Outlook.com, Hotmail and Live have their own SPF + DKIM + DMARC rule for bulk senders, announced for May 2025: SPF and DKIM must both pass, and the message must pass DMARC. Senders that fall short get rejected with 550 5.7.515.

Our take: treat any red row on this page as a deliverability incident, not a config nit. The CNAMEs and the signing toggle are both required. Publishing one without the other is the same as publishing neither.

Where to go next

For deeper dives on the individual records, see the SPF checker, the DKIM checker and the DMARC checker. If you run mail through Google as well, the equivalent set of checks lives at the Google Workspace DNS checker. To rotate or upgrade Microsoft 365 DKIM to 2048-bit, follow the PowerShell walkthrough.

🤖 Using an AI agent?

This same check runs over our free MCP server. Point Claude, Cursor or any MCP client at https://tamingdns.com/mcp and ask it to call check_m365. You get the same grade the page shows, as JSON, from the same engine. You don't need a key or an account. How it works →

📖 Further reading