DKIM · Selectors · DNS
DKIM “no key for signature” — the verifier knocked, and nobody was home
This is not vague checker-speak. The DKIM specification names this outcome: the verifier followed your signature's directions to the key's address — and the address was empty, wrong, or pointed at nothing.
The fast answer — build the address yourself
- From a real message's headers, take the signature's two values:
d=(domain) ands=(selector). - The verifier queried exactly this name:
<s>._domainkey.<d>— e.g.google._domainkey.example.com. - Query that name yourself (any DNS lookup tool; then again against your authoritative nameserver to defeat caches). What comes back sorts you into the cause table below — every row has a different fix.
- Read the reason, not the result word: receivers attach this same cause to
fail,permerror, or checker prose. The parenthetical — “no key for signature” — is the diagnosis.
What the query can return — and what each answer means
| Query result | Meaning | Go to |
|---|---|---|
One TXT with v=DKIM1 and a full p= key | The key is findable. Your problem is elsewhere (signature damage in transit, or the checker queried the wrong selector). | Cause 3 |
Nothing at that name — but a record exists at name.yourdomain.yourdomain or without ._domainkey | Wrong name — the panel appended your domain, or the middle label was dropped at entry. | Cause 1 |
| Nothing anywhere | Never published — generating a key and publishing it are separate acts. | Cause 2 |
| A CNAME — whose target has no key at its end | Chain ends in air — wrong tenant target, or the target was deleted. | Cause 5 |
A record whose p= is empty, or the key looks garbled/truncated | Revoked or damaged — an empty p= is a revoked key by specification. | Cause 6 |
| Correct at the authoritative server, missing elsewhere | Propagation / negative caching — the one cause whose fix is waiting. | Cause 9 |
The causes, ranked — fix and verify for each
1. Wrong name (the champion)
DNS panels append your domain to what you type; a fully-typed name doubles, and a dropped ._domainkey publishes the key where no verifier will ever look. Fix: re-enter with the relative name only. Verify: the exact constructed name returns your key — and enjoy the grim satisfaction of finding the old record sitting at the doubled name.
2. Generated, never published
Consoles (Google's included) generate key material first and publish nothing themselves; the DNS step is yours, and the separate “start/enable” click is a different trap (Cause 8). Fix: publish the record from your provider's current instructions. Verify: query returns the key.
3. Selector mismatch
The signature's s= names a selector you never published — or your checker guessed the wrong selector and cried “not found” at a healthy setup. Checkers that don't read your actual signature are guessing. Fix: trust the header's s=, publish/query that exact name. Verify: query using the header's values, not a tool's defaults.
4. TXT where the provider wants a CNAME (Microsoft 365)
Microsoft's model delegates: your selectors are CNAMEs to keys Microsoft hosts. A hand-pasted TXT key leaves the portal at CnameMissing — Microsoft supports the CNAME form only (see our M365 DKIM guides). Fix: remove the TXT, publish the two CNAMEs from your portal. Verify: portal status clears; query returns the CNAME chain ending at a key.
5. The CNAME chain ends in air
Values copied from another tenant, a target deleted in a cleanup, or the second selector missing — invisible until rotation day, when it becomes an outage. Fix: re-copy both targets from your own portal. Verify: follow each chain by hand to a key.
6. Damaged or revoked key
2048-bit keys are long; some panels truncate at string limits, and pasted quotes/line-breaks corrupt silently. Two different corpses, two different errors: undecodable data fails as a syntax problem, while a decodable-but-wrong key yields “signature did not verify” — if you see the second, stop hunting DNS and compare the published key character-for-character against the provider's current value. An empty p= is a deliberate revocation — and note the spec's bleak footnote: there is no defined way to distinguish a revoked key from a removed record, so no tool can honestly tell you which you are looking at.
7. Retired-selector ghosts
Rotation done backwards (new key live, old record deleted instantly) breaks mail already signed with the old selector and still in flight; the specification says to retain the old public key for a validation interval. Second platforms signing with their own selectors belong in the same inventory. Fix: restore the old record until its mail drains, then retire it.
8. Not a key problem at all — signing is off
If messages carry no signature (dkim=none), the key hunt is a distraction: the provider was never told to sign (Google's separate Start-authentication click; Microsoft's signing toggle). Different error, different fix — our setup guides cover both switches.
9. Propagation (last, by design)
The only cause cured by time, and the most over-diagnosed. It is real only when the authoritative nameserver already serves the correct record. If the authority itself lacks it, you don't have propagation — you have Cause 1 or 2 wearing a patient face.
p= value in DNS is the public key — public by design, safe to show any checker. The private key never belongs in DNS, in a form, or in a support ticket; hosted platforms never ask for it because they hold it themselves. Any service that does ask is asking for your domain's identity. Stop.FAQ
What is the g= tag I see in an old record?
A ghost: the granularity tag was deprecated by RFC 6376 itself and verifiers must ignore it. Leave it, remove it — it does nothing either way, and no modern setup should be built around it.
My checker says the key is fine but Gmail says permerror.
Compare what each queried: the checker likely used a selector you fed it; Gmail used the signature's actual s=. When they differ, Gmail is right about your mail and the checker is right about a record your mail doesn't use.
Can a key be “too strong” for some hosts?
Long keys stress weak DNS panels (Cause 6), which is a panel limitation, not a reason to downgrade: 2048-bit is the modern recommendation from the providers themselves; choose entry care — and a host that doesn't truncate — over weaker keys.
Sources
RFC 6376 — DKIM Signatures (§3.6.2.1 key-query construction, §6.1.2 verification outcomes incl. “no key for signature,” §5.2 key retirement, Appendix C.2 the deprecated g= tag) · RFC 7001 — authentication-results vocabulary (§2.5) · Microsoft Learn — DKIM CNAME model and CnameMissing troubleshooting · Google Workspace Admin Help — DKIM generation vs Start authentication.
Did this fix work for you?
Your reaction tells us whether this guide solved the problem it promised to solve.