DKIM 'No Key for Signature' / dkim=permerror: How to Fix It

Quick answer

A DKIM no key error means the receiving server tried to fetch the signer's public key from DNS and couldn't use what it got back. The key always lives at <selector>._domainkey.<domain>, built from the s= (selector) and d= (signing domain) tags of the DKIM-Signature header. Either no record exists at that name, the record can't be parsed, the key was revoked with an empty p=, or DNS didn't answer.

The fix, in order:

1. Read s= and d= from the failing message.
2. Query exactly s._domainkey.d with dig, nslookup or Resolve-DnsName.
3. Publish or repair that one record: the two Microsoft 365 selector CNAMEs, the Google Workspace google._domainkey TXT record, or your sending service's record, copied exactly.
4. Wait for DNS to update, then send a new test message and check its headers.

What the error means

RFC 6376 section 6.1.2 lists what a verifier does when it gets the public key. The parts that produce no key style errors are:

PERMFAIL is a permanent error and the signature shouldn't be reconsidered; TEMPFAIL means it couldn't be verified this time but may be tried again (RFC 6376 sections 3.9 and 6.1). The words in brackets are not fixed strings: the RFC says the explanation is not normative and is there only for clarification.

How receivers report it

Receivers write the result into the Authentication-Results header using one of the DKIM result values in RFC 8601 section 2.7.1:

The wording varies by receiver. One may show dkim=permerror, another dkim=fail or dkim=neutral with its own comment in brackets about the key, so don't search headers for one exact phrase. An illustrative example:

Authentication-Results: mx.receiver.example;
  dkim=permerror (no key for signature) header.d=example.com header.s=s2024;
  spf=pass smtp.mailfrom=example.com;
  dmarc=pass header.from=example.com

Here DMARC still passes only because SPF passed and aligned. A signature that can't be verified doesn't help DMARC, so once the message is forwarded and SPF fails, DMARC fails too.

Find the selector and domain (s= and d=)

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com;
  s=s2024; h=from:to:subject:date:message-id;
  bh=<base64 body hash>; b=<base64 signature>

• d= is the signing domain and s= the selector. Both are required, and the verifier uses them (with q=, which defaults to dns/txt) to look up the key (RFC 6376 sections 3.5 and 3.6).
• The DNS name is <s>._domainkey.<d>. With d=example.com and s=s2024 that is s2024._domainkey.example.com. A selector can contain periods, which become extra DNS labels: RFC 6376 section 3.6.2.1 gives s=foo.bar and d=example.com as foo.bar._domainkey.example.com.
• In Authentication-Results, header.d is the d= value of the signature that was checked, and many receivers also report the selector as header.s (RFC 8601 registers it as a reportable property). If header.s is missing, take s= from the matching DKIM-Signature header.
• d= isn't always your domain. A sending service that signs with its own domain keeps the key in its own DNS zone, and only the service can fix it. For DMARC you want a signature whose d= aligns with your From domain; see the DMARC alignment guide.
• Messages often carry two or more signatures. Check that the one with the key error is the one that matters.

The Email Header Analyzer lists every DKIM signature with its d= and s=, next to the receiver's results.

Common causes

• The selector record was never published, or isn't visible yet. Signing was switched on before the record went into DNS, the record went into a different DNS zone from the one your domain actually uses, or it was entered under the wrong name. Many DNS hosting panels add the domain to the host name for you, so typing the full name can create s2024._domainkey.example.com.example.com. New records also take time: Google says DKIM authentication can take up to 48 hours to start working after you add the key, and Microsoft says detecting new DKIM CNAMEs takes a few minutes or possibly longer.
• Microsoft 365 CNAMEs missing or wrong. Microsoft 365 keeps the keys itself, and your custom domain needs two CNAME records, selector1._domainkey and selector2._domainkey, pointing at Microsoft's targets. Custom domains added since May 2025 use targets like selector1-contoso-com._domainkey.contoso.n-v1.dkim.mail.microsoft (custom domain with dashes, your initial *.onmicrosoft.com prefix, and a partition character Microsoft assigns); older domains use selector1-contoso-com._domainkey.contoso.onmicrosoft.com. Both formats can't coexist for the same selector, so copy the values your tenant shows instead of building them by hand. A typo in the target, or a CNAME deleted after signing was turned on, leaves receivers with no key. See DKIM for Microsoft 365.
• Google Workspace TXT record missing or wrong. Google's default prefix selector is google, so the TXT record name is google._domainkey and the value has the form v=DKIM1; k=rsa; p= followed by the key generated in the Admin console. If the domain already had a google key for another service, you may have chosen a different prefix; the selector in s= tells you which. See SPF, DKIM and DMARC for Google Workspace.
• Long keys split or quoted wrongly. A single TXT string can hold up to 255 characters, so a 2048-bit key won't fit in one. Google's instructions are to split the key into several strings, put each string in quotes, and enter them one after another in the same record. RFC 6376 section 3.6.2.2 says the strings are joined with no space between them before use. A key that was cut short, has a piece missing, has pieces in the wrong order, or has quote characters stored inside the value instead of around each string no longer decodes, which shows up as a key syntax error or no usable key.
• Revoked key (empty p=). RFC 6376 section 3.6.1 says an empty p= means the key has been revoked; verifiers return PERMFAIL (key revoked), and there is no defined difference between a revoked key and a removed one. That is correct for a retired selector, but if mail is still being signed with it, the signer needs a new key and selector.
• Wrong k= or malformed tag syntax. The key record is a tag list (RFC 6376 sections 3.2 and 3.6.1): v=, if present, MUST be DKIM1 and the first tag, and records with any other v= value are discarded; k= defaults to rsa and must match the kind of key in p= and the algorithm in the signature's a=; tag names are case-sensitive; a tag that appears twice makes the whole tag list invalid; and a semicolon can't appear inside a value. A record that breaks these rules is ignored as malformed.
• More than one TXT record at the selector. RFC 6376 says TXT records must be unique for a selector name and the result is undefined if there are several. A wildcard TXT record covering the name also returns something that is unlikely to be a valid key. Keep exactly one key record per selector.
• A DNS error rather than a missing record (temperror). If the receiver's query times out or your DNS servers return an error for the name, it can't tell whether a key exists. That is a temporary failure: RFC 6376 allows TEMPFAIL (key unavailable), reported as dkim=temperror. If it keeps happening, check that every name server for the domain answers for the _domainkey name.
• Key rotated or removed while mail was still in transit. RFC 6376 section 3.1 describes keeping both the old and the new public keys published for a transition period while signed mail may still be in transit, and removing the old key only at the end of it. Microsoft 365 key rotation takes four days (96 hours) before the new key starts signing, and the current key is used until then, so don't remove either selector CNAME during a rotation. Removing a sending service's selector while it still signs with it causes the same error.

Step 1: Read s= and d= from the failing message

Open the received copy (view the original or the message source) and paste the headers into the Email Header Analyzer. Note the DKIM result and comment from the receiver's own Authentication-Results line, and the d= and s= of the signature that failed. Build the record name <s>._domainkey.<d>.

Step 2: Query that exact name

# Linux or macOS
dig +short TXT s2024._domainkey.example.com
dig TXT s2024._domainkey.example.com +noall +comments +answer
dig +short CNAME selector1._domainkey.contoso.com
dig @1.1.1.1 +short TXT google._domainkey.example.com
dig @8.8.8.8 +short TXT google._domainkey.example.com

# Windows (Command Prompt or PowerShell)
nslookup -type=TXT google._domainkey.example.com
Resolve-DnsName -Name selector1._domainkey.contoso.com -Type CNAME
Resolve-DnsName -Name selector1._domainkey.contoso.com -Type TXT

The second dig command prints the response status (NOERROR, NXDOMAIN or SERVFAIL). For a Microsoft 365 selector, the CNAME query shows where the name points and the TXT query follows the CNAME to the key. How to read the result:

Step 3: Publish or repair the record

• Microsoft 365: get the exact values with Get-DkimSigningConfig -Identity contoso.com | Format-List Name,Enabled,Status,Selector1CNAME,Selector2CNAME in Exchange Online PowerShell, or from the domain's DKIM details in the Defender portal (a status of CnameMissing means Microsoft can't see them yet). Create both CNAMEs, selector1._domainkey and selector2._domainkey. The DKIM for Microsoft 365 guide has every step.
• Google Workspace: in the Admin console go to Apps, Google Workspace, Gmail, Authenticate email, copy the DNS host name and TXT record value, publish the TXT record at your DNS host, then click Start authentication. Split a 2048-bit key into quoted strings if your DNS host needs it. The Google Workspace guide walks through it.
• Other sending services: copy the host name and value from the service's DKIM setup page character for character, publish one record per selector, and complete any verification step the service asks for.
• Your own mail server: publish the public key that matches the private key the server signs with, under the selector it puts in s=.
• Then decode the published record with the DKIM Record Explainer to catch an empty p=, a wrong v= or k=, duplicate tags or a truncated key.

Step 4: Wait for DNS, then re-test

1. Check the record from many public resolvers with the DNS Propagation Checker (record type TXT, or CNAME for Microsoft 365 selectors). Resolvers may keep an earlier answer, including a name does not exist answer, cached for a while.
2. Run the domain through the DKIM Checker and add the selector from s= as an extra selector (or enter the full selector host name). It shows whether a key is published, its length, and whether it was revoked.
3. Send a new message to an outside mailbox. A message that already arrived keeps the result it was given, so re-checking its old headers won't show the fix.

Avoid it next time

• Rotate keys with a new selector: publish the new key first, switch the signer, and remove the old record only after mail signed with it has had time to be delivered (RFC 6376 section 3.1). In Microsoft 365, leave both selector CNAMEs in place.
• When you retire a sending service, stop it signing for your domain before you delete its selector, or publish an empty p= to revoke the key on purpose.
• Keep a list of which service uses which selector. DMARC aggregate reports show the DKIM result for each source, and often the selector; review them in the DMARC Report Analyzer.

Verify the fix

1. Confirm the key with the DKIM Checker and decode it with the DKIM Record Explainer.
2. Confirm the record is visible everywhere with the DNS Propagation Checker.
3. Paste a new test message's headers into the Email Header Analyzer and look for dkim=pass with header.d set to your domain, and dmarc=pass. If DKIM now fails with body hash did not verify, the key is fine and something changed the message in transit: see how to fix DKIM body hash did not verify.
4. Check your DMARC policy with the DMARC Record Checker. If DKIM passes but DMARC still fails, the signing domain isn't aligned: see DMARC fail with SPF pass.

Audit hundreds of domains at once

Need SPF, DMARC and MX checks across a whole client list? Run the Bulk SPF / DMARC / MX Auditor on Apify ($2 per 1,000 domains).

Related tools and guides

Find published selectors with the DKIM Checker, decode a key record with the DKIM Record Explainer, read s=, d= and DKIM results with the Email Header Analyzer, check a new record across resolvers with the DNS Propagation Checker or query it with DNS Lookup. Related guides: DKIM for Microsoft 365, SPF, DKIM and DMARC for Google Workspace, DKIM body hash did not verify and DMARC fail with SPF pass (alignment).

FAQ

What does DKIM no key for signature mean?

The receiver looked up the public key at the selector._domainkey name built from the s= and d= tags of the DKIM-Signature header and found no key record there. RFC 6376 calls this PERMFAIL (no key for signature). Receivers report it as dkim=permerror, or as fail or neutral with a comment.

Is dkim=permerror the same as dkim=fail?

Not quite. In RFC 8601, fail means the signature was checked and failed verification, while permerror means it could not be verified at all because of an unrecoverable error, such as a missing or broken key record. Either way the signature does not count toward DMARC.

How long does a new DKIM record take to work?

It depends on the provider and DNS caching. Google says DKIM authentication can take up to 48 hours to start working after you add the key, and Microsoft says detecting new DKIM CNAME records takes a few minutes or possibly longer. Resolvers may also keep an earlier answer cached for a while.

What does an empty p= in a DKIM record mean?

The key has been revoked. RFC 6376 says verifiers must treat a signature that uses it as failed and return PERMFAIL (key revoked), and there is no defined difference between a revoked key and a removed one. Sign with a different selector that has a live key.

Why do I see dkim=temperror instead of permerror?

temperror means the receiver could not fetch the key because of a temporary problem, such as a DNS timeout or server error, and a later attempt may work. permerror means the lookup gave a final answer that cannot be used. Repeated temperror results point to a problem with the domain name servers.

Want the full kit?

Runbooks, checklists and helpdesk templates: IT Admin Packs on Gumroad.