DKIM is the standard most likely to be misdiagnosed during an assessment — not because it's more complex than SPF or DMARC, but because a "not found" result is genuinely ambiguous in a way the other two standards' results aren't. This article covers what's actually happening when DKIM validation fails, and why the fix depends entirely on which specific failure it is.
How DKIM actually works
DKIM signs outgoing email with a private key held by the sending system. The corresponding public key is published in DNS at a specific, predictable location: <selector>._domainkey.<domain>. A receiving server extracts the selector from the message's DKIM-Signature header, looks up that exact DNS record, and uses the public key found there to verify the signature.
Two things have to be true simultaneously for DKIM to validate: the sending system must actually be signing outgoing mail (a configuration on the mail platform itself, not DNS), and the matching public key must be correctly published in DNS at the selector the signature references.
Selectors: the part that makes lookups ambiguous
The selector is an arbitrary identifier your mail provider assigns — there's no universal standard selector name. Microsoft 365, Google Workspace, and every other provider each use their own selector conventions, and some rotate selectors automatically as part of key rotation.
This is why a DKIM checker not finding a record at a common selector does not prove DKIM is unconfigured. A domain can have DKIM fully enabled and correctly signing mail, using a selector the checking tool simply didn't try. This is a fundamentally different situation from SPF or DMARC, where the record lives at a fixed, predictable DNS location (the domain's root TXT records for SPF, _dmarc.<domain> for DMARC) — there is no equivalent ambiguity for those two standards.
Where to find your actual selector
Check your email provider's admin portal directly: Microsoft 365 (Exchange Admin Center, under DKIM settings for the domain), Google Workspace (Admin Console → Apps → Gmail → Authenticate email), or your provider's DNS setup documentation. The selector is the value immediately before ._domainkey in the DKIM DNS record name.
Common DKIM failure modes and what each one actually means
| Symptom | Likely cause | What to check |
|---|---|---|
| No DKIM record found at any common selector | Genuinely unconfigured, OR using a non-standard selector the check didn't try | Confirm the actual selector in your provider's admin portal before concluding DKIM is absent |
| Selector found, but signature verification fails | DNS record doesn't match the actual signing key — often from an incomplete key rotation | Confirm the DNS TXT record's public key matches what the mail platform is currently signing with |
| DKIM enabled in the mail platform, but DNS record missing | Signing was turned on before the DNS record was published, or the record publication step was missed | Publish the exact record the mail platform's admin console provides — don't hand-construct it |
| Signature present but using a weak key length | Older configuration using 512-bit or 1024-bit RSA keys | Modern guidance recommends 2048-bit RSA keys; regenerate and republish if using a shorter key |
| Multiple DKIM records under different selectors, one stale | Incomplete decommissioning after a mail-platform migration | Remove DNS records for selectors no longer actively signing mail |
DNS publication vs. signing: two separate failure points
A genuinely common cause of confusion is treating DKIM as a single on/off setting. It's actually two independent things that both have to be correct:
- Signing — is the mail platform actually attaching a DKIM-Signature header to outgoing messages?
- Publication — is the correct public key published in DNS at the selector referenced in that signature?
Either one can be wrong independently of the other. A DNS record can be perfectly published for a selector the platform isn't actually signing with (leftover from a prior configuration), and a platform can be actively signing with a selector whose DNS record was never published or was published incorrectly.
Key rotation
DKIM keys should be rotated periodically as a matter of standard hygiene, similar to any cryptographic credential. Rotation typically means generating a new key pair, publishing the new public key under a new selector, confirming the mail platform is signing with the new key, and — only after confirming the new configuration is working — removing the old selector's DNS record. Removing the old record before confirming the new one works risks a period where DKIM fails entirely.
Practical next steps
Run IT KORR's SPF/DKIM/DMARC Checker, which checks common selectors automatically and accepts a manually-entered selector for an authoritative lookup when you know your provider's actual selector. For how a DKIM failure affects the overall DMARC outcome, see Email Authentication Architecture.