Microsoft 365 uses two DKIM selectors, not one: selector1._domainkey and selector2._domainkey, each published as a CNAME record pointing at a Microsoft-hosted key rather than a TXT record you paste a value into directly. Only one selector actually signs mail at any given time. Get the exact CNAME target values for your tenant by running Get-DkimSigningConfig -Identity yourdomain.com in Exchange Online PowerShell, which returns the tenant-specific Selector1CNAME and Selector2CNAME values.
The second selector exists for key rotation, not redundancy: Microsoft's own documentation states it stays inactive until a future key rotation activates it, so signing keeps working through a rotation without any gap.
Publishing only selector1._domainkey, usually because a generic guide mentioned only one record, does not stop DKIM from enabling. Microsoft's own documentation is explicit about the actual symptom: signing enables successfully, and the failure shows up later, when key rotation cannot complete because selector2 was never created. A setup that looks finished today can be one missing record away from breaking silently at the next rotation.
The DNS & auth checker confirms DKIM resolves correctly alongside SPF and DMARC, useful for a quick external check without opening the Defender portal each time.
Selector1 and selector2 let Microsoft rotate the signing key automatically between the two selectors without a gap in DKIM coverage, a security practice most other providers don't build into the base setup.
Run Get-DkimSigningConfig -Identity yourdomain.com in Exchange Online PowerShell, which returns the Selector1CNAME and Selector2CNAME values specific to your tenant, rather than a generic value that applies to every Microsoft 365 domain.
Both selector1._domainkey and selector2._domainkey need to resolve before DKIM is enabled in the Microsoft 365 Defender portal. A single missing CNAME is the most common cause of DKIM staying disabled after setup.