BETA

Microsoft 365 DNS Checker

A one-click DNS audit for Microsoft 365 tenants

🪟 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: microsoft.com · outlook.com

Frequently Asked Questions

Common questions about Microsoft 365 DNS configuration.

The minimum is v=spf1 include:spf.protection.outlook.com -all. If you also send through third-party services like Mailchimp or Salesforce, add their includes too, but keep an eye on the 10-DNS-lookup limit. -all is the recommended hard fail. ~all (softfail) is acceptable while you're still consolidating senders.

Microsoft 365 uses selector1 and selector2. They are CNAMEs: selector1._domainkey.<your-domain> points at selector1-<tenant>._domainkey.<tenant>.onmicrosoft.com (same idea for selector2). Microsoft rotates the underlying key between the two, so both have to be present. After you create the CNAMEs, enable DKIM signing in the Microsoft Defender or Exchange admin centre.

The M365 MX is <tenant>.mail.protection.outlook.com, where <tenant> is your verified domain with hyphens replacing dots. So example.com becomes example-com.mail.protection.outlook.com. The record is published in your tenant's domain settings.

Microsoft hosts the MTA-STS policy for you on mta-sts.<tenant>.onmicrosoft.com. For your custom domain, publish a CNAME from mta-sts.<your-domain> to Microsoft's hosted policy. MTA-STS doesn't change SPF or DKIM, but it does stop opportunistic-TLS downgrade attacks on inbound mail.

The standard CNAME is autodiscover.<your-domain> pointing at autodiscover.outlook.com. Without it, Outlook falls back to root-domain probing, which usually works but is slower and tends to throw TLS errors. The explicit CNAME is worth it.