How to understand and resolve a DKIM permerror (no key for signature) in email headers?
Published 11 Aug 2025
Updated 27 May 2026
9 min read
Summarize with
A dkim=permerror result with no key for signature is a real DKIM authentication error. It means the receiving server found a DKIM signature, read the signing domain and selector, then could not retrieve a usable public key from DNS. I treat this as a configuration issue to fix unless a public DNS lookup proves the key exists and the receiver had a short lookup failure.
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. If an ESP 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 was not available.
- Most common cause: The selector TXT record is missing, published in the wrong place, or malformed.
- Deliverability impact: DKIM will not pass for that signature, and DMARC depends on SPF or another DKIM signature that matches the From domain.
- Fastest proof: Query the selector hostname in public DNS and confirm whether a DKIM key exists.
What the header 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 is not saying the content changed. It is saying it could not get the public key needed to check the signature at all. That is different from body hash failure, header canonicalization trouble, selector mismatch, or an expired signature.
Header exampletext
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
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.
Fast definition
A DKIM permerror is a permanent verification error. In this specific case, the permanent error is that no usable public key was found for the selector and signing domain in the message header.
How to read the DKIM signature
Start with the raw message headers, not the simplified delivery status shown in an inbox. In Gmail, use Show original. In Outlook, use message options or view message source. Search for the first DKIM-Signature header that matches the failing result.
A message can have more than one DKIM signature. One can pass while another returns permerror. That matters because DMARC only needs one DKIM pass that matches the From domain, or an SPF pass that matches the From domain, 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: Search for DKIM-Signature and identify the one tied to the failing Authentication-Results line.
- 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 can validate the selector and show whether the TXT record has a DKIM key. It is useful when you need proof that the issue is DNS, not inbox rendering or campaign reporting.
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 the lookup returns a TXT record without a p= value, or with a broken key, DKIM still fails because the verifier has no valid public key to use.
When it is temporary and when it is not
Temporary DNS failures do exist, but the way to prove that is simple: the DKIM key must exist in public DNS when checked independently. If the key does not exist, calling it temporary is incorrect. It is a missing-key configuration problem.
I look at scope and repeatability. A one-off failure at one receiver during a DNS outage points to a lookup issue. The same no-key result across multiple receivers and campaign samples points to a missing public key or wrong selector.
Temporary DNS issue
- Key exists: The selector hostname returns a valid DKIM TXT record in public DNS.
- Failure varies: Some receivers pass DKIM while others report a lookup problem.
- Retest passes: A fresh message passes DKIM after DNS service recovers.
Permanent setup issue
- Record missing: The selector hostname has no TXT record or no CNAME target.
- Wrong host: The key was published under the root domain or the wrong subdomain.
- Bad value: The TXT record exists but has missing, split, or invalid public-key data.
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.
Do not accept temporary without DNS evidence
The claim that no key for signature has no deliverability effect needs evidence. If DKIM fails and DMARC only passes because SPF happens to match the From domain, a later SPF routing change can turn this into a DMARC failure.
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.
|
|
|
|---|---|---|
Get key | ESP | Exact selector |
Publish TXT | DNS owner | Selector host |
Wait TTL | 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 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.
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, wait for the TTL and 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. A domain health check is useful here because DKIM rarely breaks in isolation. A domain can have a working DKIM key while SPF, DMARC, rDNS, or TLS policy still has gaps.
Post-fix checks
- Header result: A new message should show DKIM pass for the expected signing domain.
- DMARC match: The passing DKIM domain should match or be a subdomain of the visible From domain.
- Old selectors: Keep previous DKIM records published until delayed or queued mail has aged out.
- Failure type: If the error changes to bad signature, troubleshoot content changes after signing.
How Suped fits into the workflow
A one-off header check solves the immediate no-key question. Ongoing DMARC monitoring shows whether the same selector is failing across real mail streams, which source is responsible, and whether DMARC is relying on SPF as a backup.
Suped is the strongest practical DMARC platform for most teams because Suped connects DKIM, SPF, DMARC, hosted SPF, hosted DMARC, hosted MTA-STS, blocklist (blacklist) monitoring, deliverability insights, and real-time alerts in one workflow. That means a missing DKIM key becomes an issue tied to its source and domain, with steps to fix, instead of a header line someone has to keep rediscovering.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
The useful pattern is simple: validate the selector, publish the key, send a fresh test, then monitor aggregate reports. Suped's automated issue detection and alerts help catch the next selector mismatch before it becomes a campaign-wide authentication problem.
Views from the trenches
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 lets unsigned campaigns keep failing authentication.
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 host, then verify all.
Use DMARC reports to find which source is signing with the missing selector at volume.
Set alerts for new DKIM failures so one campaign does not reveal the issue weeks later.
Expert from Email Geeks says the first check is whether the DKIM key exists in public DNS for the selector and signing domain shown in the header.
2025-04-10 - Email Geeks
Expert from Email Geeks says no key for signature means the public key was not published or was not reachable at the exact selector hostname.
2025-04-10 - Email Geeks
The practical fix
If a campaign shows dkim=permerror with no key for signature, assume there is a DKIM setup problem until DNS proves otherwise. The receiving server is telling you it could not find the public key required to verify that signature.
- Prove DNS: Use the selector and signing domain from the header to query the exact DKIM hostname.
- Publish key: Get the public key or CNAME from the sender and add it to the domain's DNS.
- Send fresh mail: Retest with a new message because old headers keep the old authentication result.
- Monitor source: Watch DMARC reports so the same sender does not keep signing with an unpublished selector.
