DKIM "No Key for Signature": Selector and Rotation Fixes (2026)

Published 2026-07-08

Figures as of 2026-06-29 · methodology v7. Aggregate census data across 261 million graded domains. See how we grade.

“No key for signature” means the receiver queried the DNS record your DKIM signature points to — selector._domainkey.yourdomain — and found no key: it was never published, or was deleted mid-rotation. Publish the selector your signer actually uses. Only 10,092,481 domains — 3.87% — complete the SPF+DKIM+DMARC triad, according to the Defaults.Exposed census of 261,086,232 graded domains.

The fix is one DNS record, found in one header. Read the s= and d= tags from a real DKIM-Signature header to learn which selector your mail is signed with, publish (or repair) that exact record, and prefer CNAME delegation so your provider rotates keys for you. Then rotate by the runbook below — this error usually means someone deleted an old selector too early.

What does “dkim no key for signature” mean?

Every DKIM signature carries two tags telling the receiver where to fetch the public key: d= (signing domain) and s= (selector). The receiver queries one DNS name built from them — s._domainkey.d — for the key. “No key for signature” means that query came back empty: the signature exists, but the key it names does not.

The wording appears in Authentication-Results headers and DMARC aggregate reports — the exact phrasing varies by receiver, but two flavours matter:

Result string (fragment, as widely observed)	What actually happened	Transient?
`dkim=temperror (no key for signature)`	The DNS query failed or timed out — the receiver couldn’t get an answer at all	Yes — retries often pass; investigate only if persistent
`dkim=permerror (no key for signature)`	The DNS query succeeded and the answer was “no such record” — the selector is genuinely absent	No — the record is missing until you publish it

A one-off temperror is DNS weather. A permerror — or a temperror repeating across days and receivers — means the record the signature points to is not in your zone. That’s this guide.

The consequence: an unverifiable signature counts as no DKIM at all, so DMARC falls back to SPF alone — and SPF breaks under forwarding. If the signature is present but invalid rather than missing (body hash, mangled key), that’s a different failure — see “DKIM signature not valid”.

How do I find which selector my mail is signed with?

Don’t guess from your provider’s documentation — read it from a real message:

Send a message from the affected system to a mailbox you control (a Gmail address works well).
Open the raw source (“Show original” in Gmail, “View message source” in Outlook).
Find the DKIM-Signature: header and read two tags: s= is the selector, d= is the signing domain. An illustrative example: DKIM-Signature: v=1; a=rsa-sha256; d=yourdomain.com; s=mail2026; ...
The record the receiver queries is s._domainkey.d — here, mail2026._domainkey.yourdomain.com. Check it yourself: dig TXT mail2026._domainkey.yourdomain.com +short. Empty answer = the error is real for every receiver.
Repeat per sending system. A message can carry multiple DKIM signatures — mailbox provider, newsletter tool, helpdesk — each with its own s=/d= pair and record. Fix the failing one, and note its d=: only a signature whose d= matches your From domain helps DMARC.

Why is the selector record missing?

Four causes account for nearly all of these errors — check them in this order:

It was never published. The signer was switched on (or defaulted on) with a selector nobody added to DNS. Common with new tools and gateways that sign unexpectedly.
It was deleted mid-rotation. Someone “cleaned up” the old selector while messages signed with it were still in transit, queued for retry, or awaiting forwarding. That mail is already signed with s=old; deleting old._domainkey retroactively breaks every one of those messages.
Your DNS UI mangled a CNAME target. Many providers delegate via CNAME (s1._domainkey.yourdomain.com → s1.domainkey.u123.esp.com), and many DNS panels silently append your zone to the target — storing s1.domainkey.u123.esp.com.yourdomain.com, which resolves to nothing. Verify the target: dig CNAME s1._domainkey.yourdomain.com +short. The same trap bites during tool migrations — see DKIM failing after switching email tools.
The provider rotated, your zone didn’t. A provider key pasted as a static TXT record (instead of their CNAMEs) is orphaned by their scheduled rotation — the signer moves to a selector you never published. Only 51.84% of the 261 million domains in the census present a discoverable DKIM key at scan time (data as of 2026-06-29).

How do I fix “no key for signature”?

Run the free scan at defaults.exposed before touching DNS. It reads your live DKIM, SPF and DMARC records and shows what receivers actually see — including whether the selector resolves and whether a CNAME target got mangled.
Publish the selector the signer actually uses — the s= value from the header, not the one in an old runbook. Get the record from your provider’s admin console (Google Workspace DKIM setup · Microsoft 365 DKIM setup) and add it at exactly s._domainkey.yourdomain.com.
Prefer CNAME delegation over pasting a TXT key. If your provider offers DKIM CNAMEs, use them: the key lives in their zone, so they rotate it without you touching DNS again — cause 4 becomes impossible. Newsletter platforms almost all work this way; see Mailchimp/Brevo/Klaviyo emails failing DMARC.
Verify from outside your panel. dig TXT s._domainkey.yourdomain.com +short (or dig CNAME … for delegated selectors) from a machine off your network. The panel showing the record proves nothing if the zone serves something else.
Re-scan and re-send the test message. Authentication-Results should now read dkim=pass. Then work through anything else the scan flags on the fix DKIM page — a passing signature that doesn’t align with your From domain still fails DMARC.

How do I rotate DKIM keys without causing this error?

Rotation is where working setups break. The rule that prevents it: a selector is deleted only after the last message signed with it has drained — never at cutover. Signed mail lives longer than you think: retry queues run for days, and forwarded messages get re-verified whenever they move.

Step	Action	Gate before the next step
1. Add	Publish the new selector (`s2._domainkey…`) alongside the old one	`dig` confirms it resolves from outside
2. Switch	Point the signer at the new selector	Test message shows `s=s2` and `dkim=pass`
3. Wait	Leave the old selector published while in-flight, queued and forwarded traffic drains	≥ 7 days; watch DMARC aggregate reports until the old selector stops appearing
4. Retire	Remove the old key — or better, republish it with an empty `p=` tag: “retired”, not “never existed”	Never start this at cutover — premature deletion is the #1 cause of “no key for signature”

With CNAME delegation, your provider runs this exact runbook inside their own zone and you never see it — the strongest argument for delegating.

Frequently asked questions

Is “no key for signature” a temperror or a permerror? Both strings exist: temperror is a DNS lookup that failed or timed out — transient, often gone on retry — while permerror means DNS answered “no such record”. A temperror repeating across receivers usually turns out to be a genuinely missing record too. Check with dig and trust the answer, not the label.

Does this error mean someone is spoofing my domain? No — a spoofer wouldn’t sign with your selector. It means your own mail carries a signature receivers can’t verify, so it counts as unsigned and DMARC leans on SPF alone. Full, aligned authentication is rare: only 10,092,481 of 261,086,232 domains (3.87%) completed the SPF+DKIM+DMARC triad in the Defaults.Exposed census (data as of 2026-06-29).

Can I just delete the old selector once the new one works? Not immediately. Messages signed with it are still in retry queues and forwarding paths; deleting the key breaks them retroactively. Keep the old record at least a week, watch your DMARC reports until the old selector stops appearing, then retire it — ideally with an empty p= rather than deletion.

My provider’s checker says DKIM is configured, but receivers still report no key. How? Almost always the CNAME-target trap: your DNS panel appended your zone to the target (…esp.com.yourdomain.com), so the record exists but points nowhere. dig CNAME selector._domainkey.yourdomain.com +short shows the stored target verbatim — compare it character-for-character with what the provider asked for.

Send the owner the report

If you’re fixing this for a client or your employer, close the loop with evidence. Re-run the free scan once the selector resolves and forward the graded report to the business owner: dated, plain-language, DKIM now verifying. It’s the artefact they’ll need for the cyber-insurance renewal and the next supplier security questionnaire — proof of a working control, not just a closed ticket.

Check your DKIM free

See whether your selectors resolve — and exactly what to fix — privately and owner-only.

Check your domain → · “DKIM signature not valid” → · Fix DKIM → · Set up DKIM on Google Workspace → · Aggregate data only. Data stored and processed in the EU.