DKIM PermError: No Key for Signature Fix

What this DKIM error means

One missing DNS record can make every signed message fail before the receiver even reads the subject line.

dkim=permerror (no key for signature) means the message has a DKIM signature, but the receiver could not find a usable public key for it in DNS. The message says which key it wants. Look at the DKIM-Signature header for s=, the selector, and d=, the signing domain. The public key should be a TXT record at selector._domainkey.signing-domain.

For example, if the header says s=google and d=example.com, the receiver looks up google._domainkey.example.com. If that record is missing, empty, pasted into the wrong zone, copied with a broken key value, or left behind after a selector change, DKIM fails with a permanent error. Sending the same broken message again will fail the same way until DNS or signing is fixed.

Fix it in the right order

Start with the selector in the failed message. Guessing from your provider name wastes time.

• Open the full message headers from a failed email and copy the DKIM s= selector and d= domain.
• Query the exact TXT name: s._domainkey.d. Use your DNS host, dig, Google Admin Toolbox, or another DNS checker.
• If there is no TXT record, publish the public key from the service that signs your mail. Google Workspace, Microsoft 365, Amazon SES, Mailchimp, and most ESPs each issue their own selector and key.
• If the record exists, compare it to the provider value character by character. Keep the full p= key. Do not add spaces inside the key. Do not paste it at the root domain.
• Check for DNS host quirks. Some hosts want only the selector part as the name. Others want the full host name. A record at selector._domainkey.example.com.example.com is a common mistake.
• If the provider rotated DKIM, turn signing off and back on or generate a new selector, then publish the new record before sending again.
• Wait for DNS to publish, then send a fresh test message. Old messages still contain the old signature.

A quick domain scorecard can show the live DKIM, SPF, DMARC, and MX state from DNS, which is useful when you do not control every sender using the domain.

Why it hurts delivery

Gmail, Outlook, Yahoo, and other receivers use authentication as a trust check before they score content.

DKIM lets a receiver verify signed message fields against a public key published under the signing domain. A pass means the covered parts of the message were not changed after signing and the signer had the private key for that selector. When the key is missing, that proof is gone. The receiver may still accept the mail, but the failure raises risk. If DMARC depends on DKIM for that stream, the message can be quarantined or rejected.

DMARC passes when either SPF or DKIM passes and aligns with the visible From domain. A policy of p=none monitors only. p=quarantine asks receivers to place failing mail in spam or otherwise treat it as suspicious. p=reject asks them to reject failing mail. If DKIM is broken and SPF is also failing or uses a different return-path domain, DMARC fails.

SPF still matters. Publish one SPF TXT record, keep DNS lookups under the SPF limit of 10, and end with ~all while testing or -all when you are sure every sender is covered. Too many includes, more than one SPF TXT record, or a loose +all can damage trust. MX records do not fix this DKIM error, but broken MX can stop replies and bounces, and it is another sign that the domain DNS needs review. Public blocklists are worth checking after authentication is clean, especially if the domain or a sender was abused.

Check every sender, not one mailbox

The selector that fails may belong to a marketing app, billing system, CRM, or help desk.

List every service that sends as your domain. For each one, confirm that DKIM signing is enabled, the published selector matches the service, SPF includes the service only when needed, and DMARC reports show aligned pass results. If you receive DMARC aggregate reports, use a DMARC report reader to find the source that still fails after the main mailbox is fixed.

• Google Workspace often uses a selector chosen in the admin console.
• Microsoft 365 commonly uses CNAME selectors that point to Microsoft-hosted DKIM keys.
• Email platforms may use branded selectors per account, region, or sending domain.
• Subdomains can have separate DKIM keys, SPF records, and DMARC policy inheritance. Check the exact domain in the DKIM d= tag.

For the formal rules, use RFC 6376 for DKIM, RFC 7208 for SPF, and RFC 7489 for DMARC, plus the current Google sender guidelines and Microsoft sender requirements. For setup background, see the related guides at InboxRadar guides.

If your fix page must show in AI search

Some senders publish internal help pages or public setup docs for customers. Those pages need to be readable by crawlers.

The crawlers that decide whether you appear in AI answers are OAI-SearchBot for ChatGPT search, Claude-SearchBot for Claude, PerplexityBot for Perplexity, Googlebot for Google AI Overviews through the normal Search index, and Applebot for Apple Intelligence. Disallowing these in robots.txt removes you from that engine. There is no separate Google AI Overviews opt-out crawler.

GPTBot, ClaudeBot, CCBot, Google-Extended, and Applebot-Extended are training or opt-out controls. Blocking them does not affect live AI-search visibility. Google-Extended and Applebot-Extended are robots-only control tokens with no separate crawl user-agent. robots.txt is a stated policy, not proof of behavior. Perplexity-User and Bytespider have been reported to ignore it, so treat crawl logs as evidence only of what reached your server.

Only Googlebot documents JavaScript rendering. If the key fix, DNS names, or SPF and DMARC steps live only in client-side JavaScript, that is an undocumented risk for other AI crawlers. Put the main text in server-rendered HTML, then test crawl access with the AI visibility checker.