DKIM key not found — common causes and fixes
// published 2026-04-17
"DKIM key not found" appears in a bounce or in a Gmail Authentication-Results header, and suddenly a chunk of outgoing mail is landing in spam. The error is generic — it can mean half a dozen different things. Let's narrow it down.
How DKIM lookup works
When a receiving server verifies a DKIM signature, it reads the d= (domain) and s= (selector) tags from the message header, then queries TXT records at {selector}._domainkey.{domain}. If no TXT record is returned, verification fails with "key not found".
Example: a signature with d=example.com; s=s1 triggers a lookup at s1._domainkey.example.com. Use the DKIM Checker to run this query yourself.
Common causes ranked by frequency
1. Wrong selector in your DNS
The selector your mail server puts in the signature has to match the TXT record you published. Classic case: your provider uses google but you published under google1. Different character. Whole chain fails.
Fix: grab an outgoing email, look at the header DKIM-Signature:, extract s=, and verify a TXT record exists at that exact selector.
2. CNAME pointing at the wrong target
Most ESPs (Mailchimp, SendGrid, Postmark, Amazon SES) ask you to create a CNAME pointing at their DKIM record. If the CNAME target is mistyped or the provider rotated keys, the lookup resolves to nothing.
Fix: dig CNAME {selector}._domainkey.yourdomain.com from your workstation. The result should be a host at the ESP's domain. If it returns NXDOMAIN or the wrong target, fix the CNAME.
3. Record published at the wrong zone
If you host email on mail.yourdomain.com and the d= in the signature is the apex yourdomain.com, the TXT record must be at the apex. Publishing it in the subdomain zone won't help.
4. Record too long, got truncated
DKIM public keys are ~250+ characters. Some DNS providers silently truncate at 255. The signature verification then fails with a malformed-key error that looks a lot like "not found".
Fix: publish the record as a multi-string TXT (split into 255-char chunks), or use a provider that handles long TXT records transparently (Cloudflare, Route53).
5. DNS caching stale results
You published the record 30 seconds ago and someone is still getting "not found". Check TTL. If your resolver negative-cached the NXDOMAIN from before publication, you have to wait it out (typically 300 seconds).
What a valid record looks like
selector._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."Key elements:
v=DKIM1— version tag, always DKIM1.k=rsa— key type. RSA is universal; Ed25519 is valid but still rare on receivers.p=...— the public key, base64-encoded. Must be ≥1024 bits (better: 2048).
Selectors to try if you don't know yours
These are conventions used by major providers — if you use the provider, start here:
- Google Workspace:
google - Microsoft 365:
selector1,selector2 - SendGrid:
s1,s2 - Mailchimp:
k1,k2 - Amazon SES:
{random-string}(check the SES console) - Generic:
default,dkim,mail
Plug any of them into the DKIM Checker to see the record (or confirm it's missing).