How to understand and resolve a DKIM permerror (no key for signature) in email headers?
Published 11 Aug 2025
Updated 12 Oct 2026
11 min read
Summarize with
Updated on 12 Oct 2026: We clarified missing-key diagnosis and added checks for CNAME failures affecting a single receiver.
A dkim=permerror result with no key for signature is a DKIM authentication error. It means the receiving server found a DKIM signature but its DNS lookup did not find the matching public key. Check the exact selector hostname before changing DNS, because a receiver can retain a cached negative answer after the record is published.
The practical fix is usually straightforward: find the d= domain and s= selector in the DKIM-Signature header, look up the matching DNS hostname, then publish the missing DKIM public key as a TXT record or the CNAME supplied by the sender. If an ESP (email service provider) signs with your domain, the ESP supplies the public key or CNAME target, but the domain owner usually publishes it in DNS.
- Actual error: The receiver could not verify DKIM because the public key record was not available.
- Most common cause: The selector TXT record is missing, published at the wrong hostname, or delegated to a CNAME target that does not return the key.
- Deliverability impact: DKIM will not pass for that signature, and DMARC depends on an aligned SPF pass or another aligned DKIM pass. A DKIM error alone does not establish why a message was rejected or sent to spam.
- Fastest proof: Query the exact selector hostname in public and authoritative DNS, then inspect the response type.
What DKIM permerror (no key for signature) means
DKIM uses a private key at the sending system and a public key in DNS. The sender signs selected parts of the message. The receiver finds the matching public key through DNS, verifies the cryptographic signature, then writes the result into Authentication-Results.
When the result says no key for signature, the receiver could not get the public key needed to verify that signature. Body hash failures, revoked keys and invalid key syntax have different diagnostic reasons, although the exact wording varies by receiver. Some receivers report the missing-key reason with dkim=fail or dkim=neutral instead of dkim=permerror.
Illustrative DKIM headers, not a usable signaturetext
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=selector1; h=from:to:subject:date; bh=abc123; b=def456 Authentication-Results: mx.google.com; dkim=permerror (no key for signature) header.d=example.com header.s=selector1
The important values are d= and s=. The receiver builds the DNS hostname as s._domainkey.d. If s=selector1 and d=example.com, the public key must be at selector1._domainkey.example.com.
What permanent means
A DKIM permerror is permanent for that verification attempt. It does not mean the DNS configuration cannot be repaired. RFC 6376 specifies a permanent failure when the corresponding key record does not exist, and distinguishes this from a lookup that fails to respond.
How to read the DKIM signature
Start with the raw message headers. In Gmail, use Show original. In Outlook, use view message details or view message source. Use Authentication-Results added by the receiving system you are investigating, then match its header.d and, when present, header.s to the DKIM-Signature. Do not assume the first signature is the failing one. The header trust requirements are specified in RFC 8601.
A message can have more than one DKIM signature. One can pass while another returns permerror. That matters because DMARC only needs one aligned DKIM signature to pass, or an aligned SPF result to pass. Still, an unused or broken signature should be removed or fixed because it creates noise and can hide real sending-source problems.
- Find the signature: Match the failing result to its signing domain and selector, especially when the message has multiple signatures.
- Copy the domain: Use the value after d= as the signing domain.
- Copy the selector: Use the value after s= as the DNS selector.
- Build the lookup: Check the TXT record at selector dot _domainkey dot signing domain.
For a quick public lookup, Suped's DKIM checker checks whether the selector hostname returns a DKIM public key. A successful DNS check does not prove that a message signature verifies; confirm that with a fresh test email.
DKIM checker
Check selector records and public key configuration.
?/7tests passed
If the lookup returns no TXT record, the receiver's error is expected. If a record exists but has an empty p= value, the key has been revoked. Invalid key syntax produces a different permanent key error, so preserve the exact Authentication-Results wording when diagnosing it.
How to interpret the DNS lookup
Query the TXT record type explicitly. A command that defaults to an A-record lookup only checks for an IP address, so an empty A answer does not show whether a DKIM key exists. Check for a CNAME too because some senders delegate the selector hostname to a key they host. Use the trace to identify the authoritative zone if a subdomain is delegated, and replace ns1.example.net below with an actual authoritative nameserver.
DKIM DNS diagnostic commandsbash
dig TXT selector1._domainkey.example.com. dig CNAME selector1._domainkey.example.com. dig NS example.com. dig +trace TXT selector1._domainkey.example.com. dig @ns1.example.net +norecurse TXT selector1._domainkey.example.com.
- TXT answer: A valid key record normally contains v=DKIM1 and a non-empty p= value. DNS can display one TXT record as several quoted strings; DKIM joins those strings without adding spaces. Do not split the key into separate TXT records: multiple records at the same selector have undefined verification results.
- CNAME answer: Follow the target and confirm that it returns the DKIM TXT record. If the DNS host offers HTTP proxying, keep a DKIM CNAME set to DNS-only so the query reaches the target.
- NXDOMAIN or no TXT data: NXDOMAIN means the queried name does not exist; NODATA means the name exists without a TXT answer. A CNAME-only answer still requires checking the target. Confirm the result at authoritative DNS because a recursive resolver can return cached data.
- SERVFAIL or timeout: The resolver could not complete the query. Check authoritative nameserver health, delegation, DNSSEC validation, and retry behavior.
Publish either a TXT record or a CNAME at the selector hostname. A CNAME cannot coexist with a TXT record at that same name, as specified by RFC 2181. Use distinct selectors for sending services with different keys to avoid record conflicts.
If the selector previously returned NXDOMAIN or no TXT data, recursive resolvers can retain that negative answer for the zone's negative-cache TTL. A newly added key can therefore appear at the authoritative nameservers before every receiver can retrieve it. Publish a new selector before the sender starts using it, and leave old selectors available until queued mail has cleared.
How to distinguish missing keys from DNS failures
A timeout or SERVFAIL means the receiver could not complete the DNS lookup and is usually reported as dkim=temperror. Broken delegation or DNSSEC validation can cause these failures. An authoritative NXDOMAIN or NODATA answer for the exact selector, or its final CNAME target, points to a missing key instead.
Use scope, timing, and repeatability. A one-off failure at one receiver during a DNS incident points to a lookup problem. The same no-key result across multiple receivers and fresh campaign samples points to a missing public key or wrong selector. A current lookup does not prove what the receiver saw earlier, especially after the key was just published.
Temporary DNS issue
- Key exists: The authoritative selector hostname returns a valid DKIM TXT record.
- Failure varies: Some receivers pass DKIM while others report a lookup problem.
- Retest passes: A fresh message passes DKIM after DNS service or cached data recovers.
Permanent setup issue
- Record missing: The selector hostname has no TXT record or usable CNAME target.
- Wrong host: The key was published under the root domain or the wrong subdomain.
- Wrong selector: The sender signs with a selector that has not been published.
If the header says temporary error instead, troubleshoot it as a DNS lookup reliability issue. The DKIM temperror path is different because the receiver is saying the key lookup could not be completed at that moment.
Check DMARC even when SPF passes
If DMARC passes only through aligned SPF, fixing DKIM restores another authentication path. Forwarding can change the sending IP and break SPF; DKIM can survive forwarding when the signed content is unchanged. A DKIM pass still does not guarantee inbox placement.
When only one receiver reports no key
If fresh messages pass DKIM elsewhere but fail at Microsoft or another receiver, check the entire CNAME chain and DNS consistency before replacing the key. Public resolver success does not prove what the affected receiver saw when it processed the message.
- Follow every CNAME target to the final TXT record. Check for a deleted target or a loop, including targets hosted outside your DNS zone.
- Query each authoritative nameserver for the selector and final target. Inconsistent answers can explain why different receivers get different results.
- If a DNS response is truncated or UDP queries fail, compare a TCP lookup using dig +tcp TXT selector1._domainkey.example.com. and check DNS firewall rules.
- Retest after the relevant cache TTLs expire. Save the raw headers, message timestamp with timezone, DNS responses and SMTP rejection code for escalation to the sender or receiver.
A Microsoft Q&A report describes CNAME-related failures, but the reply requests diagnostic evidence and does not confirm a platform bug. Escalate with matching failed and successful samples rather than assuming CNAME delegation is unsupported.
How to fix the missing key
The fix depends on who controls the DNS zone and who owns the sending system. If the sender is an ESP, ask for the exact DKIM public key or the exact CNAME target for the selector shown in the failing header. Do not ask only for generic DKIM setup instructions. The public key must match the private key actually used by that sender; generating an unrelated replacement key will not repair existing signatures.
|
|
|
|---|---|---|
Get key | ESP | Exact selector |
Publish record | DNS owner | TXT or CNAME |
Check caches | DNS owner | Public lookup |
Send test | Sender | DKIM pass |
DKIM no-key repair checklist
DKIM DNS record exampledns
Host: selector1._domainkey.example.com TXT value: "v=DKIM1; k=rsa; " "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..." If the ESP gives a CNAME: selector1._domainkey.example.com. IN CNAME selector1.esp.example.
The hostname must match the failing signature exactly. A key published at selector1._domainkey.mail.example.com will not help a signature that says d=example.com. Likewise, a key for selector2 will not help a signature that says s=selector1. The signing domain in d= determines the lookup location, even when the visible From address uses a different subdomain.
If the DNS editor automatically appends example.com, enter selector1._domainkey in its host field, then verify the resulting full hostname. Entering the full name in that editor can create selector1._domainkey.example.com.example.com. The key in the example above is abbreviated; publish the complete value supplied by the sender.
Google Admin Console DKIM setup screen showing a DNS host name and TXT record value.
If you are helping a client and do not have DNS access, the handoff is still clear. Send the client the failing d= and s= values, ask the ESP for the matching public key, then have the DNS owner publish it. A missing public key often appears as no DKIM record found in separate DNS validation results.
What to check after publishing the key
After the DNS record is published, allow time for positive or negative DNS cache TTLs to expire, then test with a fresh message. Old messages do not become authenticated retroactively in mailbox headers. The receiver wrote the result at the time it processed the email.
Check the public DNS record first, then send mail and inspect Authentication-Results for the expected signing domain and selector. Suped's domain health check can also show whether SPF, DMARC, rDNS, or TLS policy has separate gaps after the DKIM key works.
Post-fix checks
- Header result: A new message should show DKIM pass for the expected signing domain and selector at the affected receiver.
- DMARC alignment: With relaxed alignment, the passing DKIM domain and visible From domain share an organizational domain. Strict alignment requires an exact match.
- Old selectors: Keep previous DKIM records published until delayed or queued mail has aged out.
- Failure type: If the error changes to bad signature, check that the DNS key matches the sender's private key as well as checking content changes after signing.
How Suped helps confirm the fix
A one-off header check solves the immediate no-key question. Ongoing DMARC monitoring shows DKIM results by sending source and whether DMARC is relying on SPF. Use selector details when the receiver includes them, and compare them with the failing message headers.
Suped is our DMARC reporting and email authentication platform. It groups aggregate report data by sending source so a missing DKIM key can be tied to the affected domain and source, then checked again after the DNS repair. Aggregate reports do not always include the exact missing-key reason: RFC 9990 requires the DKIM selector, but the human-readable failure detail is optional. Reports using older formats or incomplete implementations can omit selectors, so use headers and DNS to confirm the cause.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
The workflow is to validate the selector, publish the key, send a fresh test, then compare DKIM results for the affected source across later aggregate reporting periods. Suped's issue detection helps identify authentication failures to investigate; report data alone does not establish a no-key DNS error.
Practical DKIM troubleshooting tips
Best practices
Extract the d= domain and s= selector from headers before changing DNS or escalating.
Check the selector hostname in public DNS, not only inside the ESP setup screen or admin UI.
Keep old DKIM keys published during sender migrations until all queued mail has aged out.
Common pitfalls
Treating no key for signature as harmless leaves affected DKIM signatures unverified.
Publishing the key under the wrong subdomain makes the TXT record invisible to receivers.
Removing a rotated selector too early breaks delayed mail that still carries old signatures.
Expert tips
Ask for the selector, signing domain, TXT value and expected hostname, then verify each.
Use DMARC reports to identify affected sending sources, then confirm selectors in headers.
Set alerts for new DKIM failures so one campaign does not reveal the issue weeks later.
Frequently asked questions
Yes. The receiver's lookup did not find the DKIM public key for the selector and signing domain when it checked the message. A later successful DNS lookup does not change that stored result.
A missing-key error removes that DKIM authentication path. DMARC can still pass through aligned SPF, but forwarding can change the sending IP and break SPF. Fix DKIM to restore another authentication path; DMARC pass alone does not guarantee inbox placement.
The ESP provides the DKIM public key or CNAME target. The domain owner usually publishes that record in DNS unless the ESP manages DNS for the domain.
Check the authoritative answer, query the exact selector and signing domain from the failed header, and compare the lookup time with the message time. A receiver can have a cached negative answer after a key is published.
It depends on the published record's TTL and any negative-cache TTL retained after an earlier missing-record response. Send a fresh message after the record is visible on authoritative and public resolvers.
