Why a DKIM check works differently
SPF and DMARC live at predictable addresses, so a checker can always find them. DKIM doesn't, and it's worth understanding why before you read the result above.
A DKIM public key is published at selector._domainkey.yourdomain.com, where the selector is a label your mail provider chose. DNS offers no way to ask "which selectors exist?" — you can only look up a name you already know. So every DKIM checker, including this one, probes well-known selector names and reports what it finds.
We probe 83 selector names, chosen by measurement rather than guesswork: each one was tested against 52 domains spanning Google Workspace, Microsoft 365, Proofpoint, Mimecast, Proton, Fastmail, Migadu, Titan and the major sending platforms. That list finds a key on 92% of them.
It covers the mailbox providers (google, selector1/selector2, protonmail, fm1–fm3, key1–key3, zoho, titan1, Yahoo's s1024/s2048), the generic conventions (default, dkim, mail, smtp, mx), and the platforms that sign on your behalf — Mailchimp, SendGrid, Mailgun, Postmark, Resend, Amazon SES, Zendesk, HubSpot, Intercom, Klaviyo and others. Seeing zendesk1 or mandrill in your results is useful in itself: it's a map of who sends as you.
"No keys found" is not the same as "no DKIM"
If your provider uses a custom selector, your DKIM is fine and simply invisible to the probe. That's a limit of the protocol, not a verdict on your setup, and it's why this tool says "may still be configured under a custom selector" rather than declaring DKIM missing.
How to find your real selector
Send yourself a message, then view its full headers and look for the DKIM-Signature line:
DKIM-Signature: v=1; a=rsa-sha256; d=yourdomain.com;
s=selector1; h=from:to:subject:date; b=Ax0pQ...The s= tag is the selector and d= is the signing domain. In Gmail, use "Show original"; in Outlook, "View message source". Once you know the name, you can look the key up directly at <selector>._domainkey.<domain>.
What makes DKIM worth the setup
DKIM signs the message itself, which gives it one decisive advantage over SPF: the signature survives forwarding. An SPF check fails the moment a message is relayed by a server that isn't in your record, and forwarding is entirely outside your control. A DKIM signature keeps validating as long as the signed headers and body are untouched.
Mailing lists are the usual exception — appending a footer or rewriting the subject invalidates the signature, which is the problem ARC was designed to solve.
Because DMARC passes when either SPF or DKIM aligns, publishing both means two independent chances for legitimate mail to authenticate. Domains that rely on SPF alone are the ones whose forwarded mail mysteriously lands in spam.
Common questions
Should I rotate DKIM keys?
Yes, and selectors are what make it painless. Publish a new key under a second selector, switch signing to it, and retire the old one once nothing is signing with it — no window where mail goes unsigned. Annually is a reasonable cadence for most senders.
Is 1024-bit still acceptable?
It validates today, but it's weak, and the major mailbox providers have made clear they intend to stop accepting it. Choose 2048-bit whenever your provider offers it.
Can I have more than one DKIM key?
Yes — unlike SPF, where a second record is a permanent error, DKIM expects multiple keys. Each sending platform gets its own selector, and that's the normal arrangement for anyone using a mail host plus a marketing platform.
For the mechanics of signing and verification, see how DKIM works.