DKIM Fail: No Key for Signature - How to Fix

DKIM failing with "no key for signature"? Something signed the message, but the receiving server could not find a public key in DNS to verify it against. This is a DNS problem, not a cryptography or content problem.

The Error

Authentication-Results: mx.google.com;
       dkim=permerror (no key for signature) header.i=@example.com
       header.s=selector1 header.b=Qm9keUhhc2;
       spf=pass (google.com: domain of bounce@example.com designates
       203.0.113.10 as permitted sender) smtp.mailfrom=bounce@example.com;
       dmarc=fail (p=NONE) header.from=example.com

Other verifiers word it differently for the same fault:

dkim=fail reason="key not found in DNS"
dkim=temperror (no key for signature)
dkim=neutral (public key: DNS query failed)

The two fields that matter are header.s= (the selector) and header.i= or d= (the domain). Together they tell you the exact DNS name the verifier queried.

Why This Happens

DKIM verification is a DNS lookup. Given a signature with s=selector1 and d=example.com, the verifier queries:

selector1._domainkey.example.com

and expects a TXT record containing the public key. "No key for signature" means that query returned nothing usable. In practice:

1. The record was never published — DKIM was enabled at the sending platform but the DNS side was skipped
2. It is published at the wrong host name — the most common single mistake
3. The selector changed after a key rotation, and only the old selector exists in DNS
4. DNS has not propagated yet, or is still serving a cached negative answer
5. The record is malformed or truncated — usually a 2048-bit key that was not split into quoted strings correctly
6. The signer is a third party using its own selector, which was never delegated on your domain

Note the difference from the other common DKIM failure. "No key for signature" means the key could not be found. "Body hash did not verify" means the key was found and used, but the message body changed after signing. They are unrelated faults.

Fix 1: Query the Exact Name from the Signature

Do not guess the selector. Take it from the failing message's DKIM-Signature header:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com;
 s=selector1; t=1754956800; bh=...; h=from:to:subject:date; b=...

Then query that exact name:

# selector from s=, domain from d=
dig +short TXT selector1._domainkey.example.com

# Some providers publish a CNAME that points at the real key
dig +short CNAME selector1._domainkey.example.com

A healthy TXT answer looks like:

"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

Empty output is your answer: the record is missing or is at a different name. Our DNS lookup tool will resolve it if you do not have dig to hand, and our email header analyzer will pull the selector and domain out of a pasted header block for you.

Fix 2: Publish at the Correct Host Name

The record always belongs at selector._domainkey.yourdomain.com. The classic failure is entering the fully qualified name at a DNS provider that already appends the zone, which silently creates:

selector1._domainkey.example.com.example.com

That resolves for nobody. After publishing, always verify by querying the name rather than trusting the control panel display.

Watch for these too:

• A trailing dot where the provider does not expect one, or a missing one where it does
• The underscore in _domainkey being stripped or rejected by a provider that dislikes underscores
• Quoting: a 2048-bit key exceeds the 255-character limit for a single DNS character string, so it must be split into multiple quoted strings that the resolver concatenates. Most providers handle this automatically; some require you to do it, and a truncated key produces exactly this error.
• The p= value must be the public key as issued, with no line breaks or spaces introduced by copy-paste.

Fix 3: Complete Activation in Google Workspace

DKIM signing for a custom domain is not on by default in Google Workspace, and the final step is the one most often missed.

1. Sign in to the Google Admin console.
2. Go to Apps > Google Workspace > Gmail > Authenticate email.
3. Select the domain and click Generate new record. Choose 2048-bit.
4. Publish the supplied TXT record at the host google._domainkey on your domain.
5. Wait for DNS to propagate — usually under an hour.
6. Return to the same page and click Start authentication.

Step 6 is what actually turns signing on. Publishing the record without it leaves DKIM inactive, and mail goes out unsigned rather than signed-and-unverifiable — a different symptom, but the same root cause of a failing DMARC result.

Confirm afterwards:

dig +short TXT google._domainkey.example.com

Fix 4: Handle Selectors and Key Rotation

A signer can only use a selector that exists in DNS. Rotations break DKIM when the order is wrong.

The safe sequence is always:

1. Publish the new selector's key in DNS.
2. Confirm it resolves from an external resolver.
3. Only then switch the signer to the new selector.
4. Leave the old selector's record published until no mail in flight is still signed with it.

Microsoft 365 sidesteps this by having you publish CNAMEs at selector1._domainkey and selector2._domainkey that point into Microsoft's infrastructure, so Microsoft can rotate the underlying key without you touching DNS. Note that Microsoft changed the CNAME target format in May 2025 — newer custom domains use a different target than older ones, and the two formats cannot coexist for the same selector. Always read the current values from the Defender portal or Exchange Online PowerShell rather than copying an example.

Fix 5: Third-Party Senders Need Their Own Selector on Your Domain

If the failing signature has d=example.com but a selector you do not recognise, a marketing platform or CRM is signing as your domain and its selector was never published — or was published and later removed.

Every such vendor needs its own selector delegated on your domain. There is no conflict: selectors are namespaced, so mailer1._domainkey, google._domainkey and selector1._domainkey coexist happily on one domain. Get the records from each vendor's domain-authentication screen and publish them all.

What Not To Do

Do not delete the DKIM record or disable signing to make the error stop. DKIM is the authentication method that survives forwarding, and removing it leaves DMARC dependent on SPF alone — which breaks on the first forwarded message.

Do not weaken DMARC to p=none as the fix. It stops the enforcement, not the failure, and leaves your domain spoofable while the key is still missing.

Do not publish a placeholder or empty p= value. A record with an empty public key is the documented way to revoke a key, so publishing one tells receivers that mail signed with that selector should be treated as unsigned — the opposite of what you want.

Verify the Fix

Confirm DNS first, from outside your own network:

dig +short TXT selector1._domainkey.example.com @8.8.8.8

You should get back a string starting v=DKIM1; and containing a long p= value. If the answer is empty, nothing else will work yet — negative DNS answers are cached, so allow the TTL to expire.

Then send a live message to a mailbox you control and read the results. In Gmail use Show original; in Outlook on the web use View message details:

DKIM: 'PASS' with domain example.com

Confirm the s= value in the delivered message's DKIM-Signature matches the selector you published. If the signer is using a different selector than the one you fixed, publish that one too.

Test from every system that sends as your domain — mail platform, CRM, application server — because each may sign with its own selector.

Prevention

• Publish the DNS record before enabling signing at the provider, and verify it resolves externally before flipping the switch.
• Keep an inventory of which selector belongs to which sending service. Records get deleted during DNS cleanups precisely because nobody remembers what _domainkey entries are for.
• During key rotation, publish new before switching and retire old only after the change has fully propagated.
• Publish DMARC with rua= aggregate reporting and read it monthly — reports show DKIM pass rates per source, so a missing key surfaces as a trend well before anyone notices missing mail. Build the record with our DMARC generator.
• Re-check selectors after any migration between mail platforms; the old provider's selector stops being used and the new one is easy to forget.

Summary

1. Read s= and d= from the DKIM-Signature header to get the exact DNS name queried
2. Query that name directly — empty output confirms the record is missing or misplaced
3. Check for a doubled domain in the host name; it is the most common publishing mistake
4. In Google Workspace, click Start authentication after publishing google._domainkey
5. Rotate keys in the safe order — publish new, verify, switch signer, then retire old
6. Give every third-party sender its own selector; selectors do not conflict