DKIM key not found or could not be retrieved - causes and fixes
What 'DKIM key could not be retrieved - no valid record', 'selector not found' and 'found _domainkey but DKIM not found' mean, and how to fix each.
"DKIM key not found" appears in a bounce, or Gmail's Authentication-Results header says dkim=neutral (no key for signature), 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.
Exact error messages and what they mean
Different checkers and mail gateways word the same failure differently. If you pasted one of these strings into a search box, here is what it is telling you.
DKIM key could not be retrieved from '...' error - no valid record
Some tools print it as DK/DKIM key could not be retrieved from 's1._domainkey.example.com' error - no valid record. The name in quotes is the exact DNS name the verifier queried, so it already tells you the selector (s1) and the signing domain (example.com). "No valid record" means one of two things: there is no TXT record at that name (NXDOMAIN or an empty answer), or there is one but it is not a usable DKIM key.
Fix: query that exact name - dig TXT s1._domainkey.example.com. Nothing back: publish the record under that host (causes 1-3 below). Watch for a doubled host: many DNS panels append the domain for you, so typing s1._domainkey.example.com as the host creates s1._domainkey.example.com.example.com. Something back: check that it has a non-empty p=, that a v= tag, if present, is v=DKIM1 and comes first, and that the key was not cut at 255 characters (cause 4).
DKIM selector not found
A checker asked for a TXT record at the selector you typed - or at every selector in its built-in list - and got nothing. Selectors are arbitrary names picked by the sender, so a checker that only knows a short list will report "not found" on a perfectly healthy domain that uses a custom selector.
Fix: send a message to a mailbox you control (Gmail: "Show original"), find the DKIM-Signature: header and read the s= tag. Use the received copy - the one in your Sent folder is usually stored before signing and has no such header. That is your selector. Or let the DKIM Checker probe 84 common selectors at once.
Found _domainkey but DKIM not found
The checker found something under _domainkey for your domain, but no usable key at the selector it was checking. Typical reasons:
- Only other selectors exist - an old key from before a rotation, or another sending service - and the one in your signature was never published.
- The selector is a CNAME to your email provider, and the target has no TXT record (wrong target, or the provider rotated the key).
- The TXT record is something else - an SPF string pasted into the wrong host, or a key with a broken tag such as
v=DKIMinstead ofv=DKIM1. - The key is revoked:
p=is empty.
Fix: look at the raw answer (dig TXT s1._domainkey.example.com shows the CNAME chain and what is at the end of it, or the DKIM Checker's record view) and compare it with the record your provider gave you, character for character.
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: open a message as it was received (not the Sent-folder copy), 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
A 2048-bit DKIM key is about 400 characters, but a single TXT string holds at most 255. Some DNS panels silently cut the rest off. 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 splits long TXT records for you (Cloudflare does; Route 53 expects you to split them yourself).
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 - how long is set by the SOA minimum of your zone, commonly 5 minutes to an hour.
What a valid record looks like
selector._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."Key elements:
v=DKIM1- version tag. Optional, but if present it must be exactly DKIM1 and come first.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:
k2,k3(older setups:k1) - 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).