Email authentication
Microsoft 365 setup checker
Check a domain’s Microsoft 365 SPF include and both DKIM selector CNAMEs, mistake by mistake.
Free, no accountLive check
Result
The verdict appears here once you press Check Microsoft 365 records.
What this is
This Microsoft 365 setup checker reads the two DKIM selector hostnames every tenant shares, confirms each one is a CNAME rather than a TXT record, and compares the part of its target that can be computed from your domain - then checks the SPF include for whichever of Microsoft’s three clouds you are on.
Microsoft 365 publishes the same two DKIM hostnames for every organisation, selector1._domainkey and selector2._domainkey, and both have to be CNAME records. Their targets are only half yours: the selector and your domain with its periods turned into dashes, then a tenant prefix and, in the newer format, a partition character that Microsoft assigns and you cannot choose.
Two target formats are in circulation. Custom domains added since May 2025 get a target ending in "-v1.dkim.mail.microsoft"; existing custom domains and initial domains keep one ending in onmicrosoft.com. Microsoft says the two cannot coexist for the same selector, so a domain is on one or the other and seeing either is not a fault.
How to read the result
Each selector row says which of the two documented formats its target matched, or which named mistake it ran into instead: a TXT record where the CNAME belongs, a hostname carrying the domain twice because the DNS editor appended the zone to a name that already ended in it, or a target with the periods still in the domain where dashes belong.
Only the computable part of the target is compared exactly, and the page says so rather than implying more. A target that starts with the right selector and the right dashed domain, and ends somewhere this page has not seen before, is reported as matching the shape - the Defender portal is the only place the real value for a tenant is shown.
This checker only covers Microsoft 365’s own fixed SPF include and the two DKIM selectors. For how SPF, DKIM and DMARC fit together, what order to fix them in, and what to do once one fails, see our guide How SPF, DKIM and DMARC work together, and what to do when one fails.
Common mistakes
What goes wrong most often, and how to tell.
- Publishing selector1 and leaving selector2 for laterMicrosoft requires both records. With one of them, signing enables successfully and messages are signed, so the setup looks finished - and then the first key rotation fails because there is no second selector to rotate into. The gap usually surfaces long after anyone remembers making it.
- Creating the selector as a TXT record holding a keyEvery other DKIM setup in the world is a TXT record with a public key in it, so this is the natural thing to do and it is not supported here. The CNAME exists precisely so Microsoft can replace the key behind it without anyone editing DNS again.
- Letting the DNS editor append the domain twiceMost editors add the zone to whatever goes in the host field, so pasting the fully qualified hostname produces selector1._domainkey.contoso.com.contoso.com. The record exists, resolves and is never consulted by anything, which is the most time-consuming way for this to fail.
- Leaving the periods in the domain part of the targetMicrosoft replaces every period in the custom domain with a dash, so contoso.com becomes contoso-com and marketing.contoso.com becomes marketing-contoso-com. Copying the target by hand and keeping the periods produces a name that looks almost right and resolves to nothing.
- Setting the selector TTL very low to make a change arrive soonerA very low TTL is on Microsoft’s own list of things that stop DKIM working, and it is also invisible from outside: what a resolver returns is whatever is left of a cached answer, not the number in your zone. It is worth checking in the zone itself rather than with a lookup.
Questions
What people ask about this tool.
- Because rotation alternates between them. Microsoft requires both CNAME records: with only selector1 published, signing enables and works, and then key rotation fails later - which is why a missing selector2 almost always turns up months after the setup appeared to be complete.
- No. A TXT record at selector1._domainkey or selector2._domainkey is not supported for Microsoft 365 and appears on Microsoft’s own list of mistakes that prevent DKIM working. The CNAME is what lets Microsoft rotate the key behind it without you editing DNS again.
- No. Microsoft documents spf.protection.office365.us for GCC High and DoD, and spf.protection.partner.outlook.cn for Office 365 operated by 21Vianet. This page recognises all three and names the cloud it found, rather than failing the two that are not the commercial one.
- No. Correct CNAME records make signing possible; switching it on happens in the Defender portal and leaves no trace in DNS. Microsoft also says the CNAME values printed in its article are illustrations, so the portal is the only place the real targets for your tenant appear.
Sources
Every fixed value here comes from the provider’s own documentation. These pages change, so each says the day it was last read.
- Microsoft, “Set up SPF to identify valid email sources for your Microsoft 365 domain” read 13 October 2026
- Microsoft, “How to use DKIM for email in your custom domain” read 13 October 2026
Use it from the API
The same check, as one request.
This example uses a name RFC 2606 reserves for documentation, ending in .example, .test, .invalid or .localhost. None of them is a real domain, and nobody can register one.