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

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?

Seven probes, 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 to *.onmicrosoft.com
DMARC        → _dmarc TXT published with a policy
MTA-STS      → mta-sts.<domain> CNAME + policy file
TLS-RPT      → _smtp._tls TXT with a rua= mailbox
Autodiscover → autodiscover.<domain> CNAME to autodiscover.outlook.com

Publishing the CNAMEs is not enough on its own. DKIM signing has to be switched on in the Defender or Exchange admin centre, otherwise both selectors resolve but no outbound mail is ever signed. That mismatch is one of the most common findings on this page.

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 DKIM show as "not signing" when the CNAMEs are there?

The CNAMEs are the DNS side. Microsoft also keeps a per-tenant toggle that has to be flipped before Exchange Online will actually attach a DKIM-Signature header. New tenants ship with the toggle off, and it's easy to publish both CNAMEs, see them go green in every external checker, and still send unsigned mail.

What to do: in the Defender portal, open Email & collaboration → Policies & rules → Threat policies → Email authentication settings → DKIM, pick the domain, and switch signing on. The setting takes effect within a few minutes.

Why this matters

Outlook.com, Hotmail and Live now enforce the same SPF + DKIM + DMARC rule Google and Yahoo turned on in February 2024. Microsoft's version went live in May 2025. Bulk senders that fail the check 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.

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:

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

Microsoft rotates the live key between the two, so both have to resolve. After the CNAMEs are in place, switch DKIM signing on in the Defender or Exchange admin centre. Until you do, the records look perfect and outbound mail still goes unsigned.

The M365 MX is <tenant>.mail.protection.outlook.com. The <tenant> part is your verified domain with dots replaced by hyphens, so example.com becomes:

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

Copy the exact value from your tenant's domain settings in the admin centre. Tenants migrated between regions sometimes end up with a non-obvious hostname, and guessing the format gets you a silent NXDOMAIN.

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.