dkim=fail signature did not verify

TL;DR

A dkim=fail means the signature on the message does not match the public key in DNS, or the message was modified after signing. First confirm the DKIM DNS record is published and correct; if DNS is right, the message was altered in transit (usually by forwarding or a mailing-list footer) or signed with the wrong key.

dkim=fail signature did not verify

Use this when

• Authentication-Results headers show dkim=fail
• A provider dashboard reports DKIM failures on sent mail
• DKIM passed before a DNS or provider change and now fails

Not for this skill when

• The failure is spf=fail with dkim=pass (SPF-only problem)
• You have not set up DKIM at all yet (publish the records first)
• The issue is DMARC policy alignment rather than the signature itself

Steps

1. Look up the DKIM record: query [selector]._domainkey.[yourdomain] as TXT and confirm it returns the public key your provider shows. Expected: the DNS value matches the provider's expected value exactly.
2. Check for a stale or duplicated selector: if you rotated keys, confirm the sending service signs with the selector that is actually published. Expected: one active selector, matching on both sides.
3. Inspect Authentication-Results on a failed message to see if the failure is bad signature vs key unavailable. Expected: the reason names DNS vs crypto.
4. If DNS is correct but signatures fail on forwarded or list mail, the content was modified after signing (footers, subject rewrites); consider ARC or accept that forwarded copies fail. Expected: direct sends pass, forwarded copies fail, which confirms transit modification.
5. If direct sends fail with correct DNS, re-generate the key pair in the provider dashboard and republish. Expected: fresh signatures verify.

Variant phrasings

dkim signature did not verify

Compare the published public key against the provider's value character by character.

dkim fail bad signature

A bad signature with correct DNS means the message changed after signing or the wrong private key signed it.

Tool/version compatibility

Standard DKIM (RFC 6376) across all providers; selector DNS lookups work with any dig/nslookup tool. Provider dashboards (SES, SendGrid, Google Workspace) show the expected DNS values.

Why it happens

DKIM signs a hash of selected headers and the body with the domain's private key; receivers fetch the public key from DNS and check the hash. Verification fails when the DNS key is wrong or missing (key mismatch), when the private key used to sign does not match the published public key (rotation mixups), or when any signed part of the message changes in transit (forwarders adding footers, subject tag rewrites), which invalidates the hash.

Edge cases / pitfalls

• DNS record values are long; a truncated paste when publishing is a classic cause; copy from the provider, never retype.
• Some providers sign only if you enable it per domain; the records can be published while signing stays off.
• Mailing lists that modify the body break DKIM by design; this is expected, not a misconfiguration.
• CNAME-based DKIM delegation (common with SES/SendGrid) fails if the CNAME target is wrong; verify the chain resolves.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_YHYuPbNm4G73eHr4sdPAfg