What is the difference between 'DKIM selector not found' and dkim=fail?

They are not the same problem. 'Selector not found' means the receiver looked up `selector._domainkey.yourdomain` and got nothing back — no key, so there is nothing to verify against, and the result is usually `dkim=none`. `dkim=fail` means a key *was* found and a signature *was* checked, but it did not verify — typically because the message body changed in transit. One is a missing record; the other is a broken signature. Fixing the wrong one wastes a day.

Why does my DKIM checker say 'record published, no record found'?

Almost always a name mismatch. You added the record in your DNS provider's UI, but the host ended up wrong — most commonly the provider auto-appends your domain, so `selector._domainkey.example.com` becomes `selector._domainkey.example.com.example.com`. The record exists; it's just not at the name the receiver queries. The fix is to enter only `selector._domainkey` (or whatever your provider's UI expects) and verify the final fully-qualified name with a direct DNS lookup.

My email provider told me to add a CNAME, not a TXT. Is that right for DKIM?

Yes, and this is where DKIM differs from MX. Many senders — Amazon SES, SendGrid, Microsoft 365, Mailchimp — have you publish the selector as a CNAME that points into their zone, so they can rotate the actual key without touching your DNS. A resolver follows that CNAME to the TXT record on their side, and verification works normally. (Contrast MX, where a CNAME target is forbidden by RFC 2181.) If the CNAME is missing, mistyped, or was never propagated, the chain dead-ends and the selector resolves to nothing.

Views: 8

DKIM Selector Not Found: dkim=none and Missing Key

DKIM selector not found means receivers can't fetch your key. Check the s= selector, CNAME delegation, and typos in 4 steps. Free instant check, no sign-up.

Check your domain for this issue now

Free, no sign-up. Runs the exact check this guide describes and shows what to fix.

Problem

A receiver gets your mail, reads the s= selector out of the DKIM-Signature header, looks up the public key at selector._domainkey.yourdomain — and finds nothing. There is no key to check the signature against, so DKIM does not fail so much as it never runs. The Authentication-Results header comes back dkim=none, your DMARC alignment drops to whatever SPF can carry on its own, and your mail starts landing in spam for reasons that have nothing to do with what’s in it.

This is a DNS problem wearing an email costume. The signature on the message is probably fine. The record that proves it just isn’t where the receiver is looking.

Symptoms

Authentication-Results shows dkim=none even though your sending platform says DKIM is enabled.
A DKIM checker reports “no DKIM record found” or, more confusingly, “record published — no record found.”
Mail from your main platform authenticates, but a second sender (a CRM, a ticketing system, a newsletter tool) shows no DKIM at all.
DMARC reports list dkim as none/fail for a specific source IP while SPF still passes.
You can see the key in your DNS provider’s dashboard, but an external lookup returns empty.

What “selector not found” actually means

DKIM signs a message with a private key and tells the receiver where to find the matching public key using two tags in the signature: d= (the domain) and s= (the selector). The receiver builds one name from those — <selector>._domainkey.<domain> — and does a single DNS TXT lookup. The answer it wants is a record like v=DKIM1; k=rsa; p=<base64 public key>.

“Selector not found” means that one lookup came back empty. RFC 6376 is precise about what the receiver does next: with no key, there is no verifiable signature, so the result is none, not fail. That distinction matters because the two send you to opposite ends of the problem. fail means “I found your key and your signature didn’t match” — go look at what mangled the body. none means “I couldn’t find your key at all” — go look at DNS. People burn hours chasing body-hash gremlins when the real issue is a record sitting at the wrong name.

Top 3 Causes

The selector in the signature doesn’t match a published record. The receiver queries the exact s= value from the signature. If your platform signs with s=selector1 but you published default._domainkey, the lookup misses. This also bites when you rotate keys or add a new sending service: the new selector signs the mail before its record is live, or an old selector record was deleted while mail still references it. The tell: read the s= tag in the actual DKIM-Signature header, then query that precise name.
Double-appended domain (the UI footgun). You entered selector._domainkey.example.com into a DNS panel that already appends the zone name, and the record was silently created at selector._domainkey.example.com.example.com. The dashboard shows your record; the receiver, querying the correct name, gets nothing. This is the single most common cause of “record published but not found,” and it’s invisible unless you check the fully-qualified name.
Broken or unpropagated CNAME delegation. Your sender had you add a CNAME (SES, SendGrid, M365, Mailchimp all do this) so they can manage the key. If that CNAME is mistyped, points at the wrong target, hasn’t propagated yet, or got removed during a DNS cleanup, the resolver follows it into a dead end. Unlike a missing TXT, this one looks configured — the CNAME is right there — but the chain it points to resolves to nothing.

Diagnose with DechoNet

Email Check looks up DKIM the way a receiver would and tells you whether a key is actually resolvable for your domain’s common selectors — so you can see at a glance whether the problem is “no record” versus “record, but signature broken.”
DNS Check lets you query the exact <selector>._domainkey.<domain> name as a TXT (and follow a CNAME if your provider uses delegation). An empty answer at the precise name the receiver uses is the smoking gun — and it catches the double-appended-domain case the dashboard hides.
Email Header Analyzer reads the real Authentication-Results from a received message and shows you the s= selector your mail is actually signed with — which is the name you should be querying, not the one you assume.

Resolution Checklist

Open a received message and read the DKIM-Signature header. Note the exact s= (selector) and d= (domain) values — query what the mail actually claims, not what you think you set.
Run a direct TXT lookup on <selector>._domainkey.<domain>. If it’s empty, the record isn’t where the receiver looks — that’s your problem, full stop.
Check for the double-domain trap: confirm the fully-qualified name has the zone exactly once, not twice. If your provider appends the domain, enter only selector._domainkey.
If your sender uses CNAME delegation, verify the CNAME exists, has no typo, and resolves through to a TXT on the provider’s side. A present-but-misdirected CNAME fails the same way a missing record does.
After any key rotation, confirm the new selector’s record is live and resolvable before mail starts signing with it — and don’t delete the old selector until traffic has moved off it.
If you publish multiple senders, check each one has its own selector record. One working selector does not cover mail signed by a different service.

When to Escalate

If the selector record is correct and resolvable but dkim=none persists, the problem has moved upstream to signing: the sending platform isn’t actually adding a DKIM-Signature at all. That’s a setting in the email service, not in DNS — escalate to whoever administers that sender.
If you don’t control the DNS zone (a managed host, a registrar’s default zone, a parent domain that delegates to you), and the record or CNAME can’t be created at the exact name required, the DNS operator has to make the change — you can’t override an authoritative record you don’t administer.