Cause · impact · fix
dkim=fail (signature verification failed)
The receiver found a DKIM signature on your message, fetched your public key, and the cryptographic check still did not match. Here is why it happens, what it costs you, and how to fix it.
What it means
The cause.
DKIM signs a chosen set of your headers and a hash of the body with a private key, and records the result in the DKIM-Signature header. The receiver reads the selector and domain from that header (the s= and d= tags), fetches the matching public key from DNS, and recomputes the signature. When the recomputed value does not match what you signed, it reports dkim=fail (signature verification failed) in Authentication-Results.
This result is specific: a signature was present and the public key was found. That rules out dkim=none (nothing signed the message) and a missing DNS record. What it tells you is that the message the receiver holds is not byte-for-byte the message that was signed, or that the key used to sign no longer matches the key published for that selector. The three usual culprits are content changed in transit, a key or selector mismatch, and the signed body no longer hashing to the value in the bh= tag.
Something between your signer and the recipient almost always did it. A mailing list appends a footer, a forwarder rewrites links, a security gateway re-encodes MIME parts or adds a banner — any of these alters the signed bytes after signing, and the hash no longer holds. The other common cause is key rotation: your provider began signing with a new selector before the new public key finished propagating in DNS, or an old selector kept signing after its key was retired.
Why it matters
The impact.
A failed DKIM signature removes one of your two authentication methods on that message. On its own that need not be fatal — a message can still authenticate through SPF — but it becomes serious under DMARC. DMARC passes only when SPF or DKIM passes and aligns with your From: domain, so if the message was relying on DKIM to satisfy DMARC, it now fails, and forwarded mail (where SPF usually breaks too) has nothing left to pass on.
Since 2024, Gmail, Yahoo and Microsoft require bulk senders to pass DMARC, which in practice means keeping DKIM valid end to end. Intermittent verification failures also erode domain reputation over time: receivers see a share of your mail arriving unauthenticated, and the visible symptom is messages that used to land quietly starting to hit spam or, under a strict policy, being rejected outright.
What to do
The fix, in order.
Work top to bottom, then re-check — DNS changes take a few minutes to take effect.
- 1 Confirm it is verification failing, not a missing key. Send a message through the email tester and read the DKIM line. If it says signature verification failed, a signature and key were both found and the cryptographic check did not match — a different problem from dkim=none or a key the receiver could not fetch. This tells you to look at the message and the key pair, not at whether a record exists.
- 2 Check whether the body is being modified after signing. A body hash mismatch means the message changed between signing and delivery. Look for a mailing list footer, a forwarder that rewrites links, or a security gateway that adds a banner or re-encodes MIME. If the failure only appears on forwarded or list mail, the modification — not your setup — is the cause, and relaxed body canonicalisation tolerates far more of it than simple.
- 3 Verify the published key matches the signing key. Confirm the selector in the DKIM-Signature header (s=) resolves to a public key in DNS at selector._domainkey.yourdomain.com, and that it is the exact counterpart of the private key your platform signs with. A truncated record, a stray space, or a key regenerated on the sending side without updating DNS all produce a verification failure even though a record exists.
- 4 Finish any key rotation cleanly. If you recently rotated keys, publish the new public key and let it propagate before you switch signing to the new selector, and do not retire the old selector until no live mail still carries it. Signing with a selector whose key is not yet live — or whose key has already been removed — fails on every message until the two sides line up.
- 5 Reduce what you sign, then re-test. Sign only stable headers. Signing volatile or receiver-rewritten headers, or oversigning fields a gateway will touch, invites failures you cannot control downstream. Once the signature and key agree, send another test and confirm the DKIM line reads pass before you rely on it.
Confirm the error is gone.
Run a full check on your domain — it reads SPF, DKIM and DMARC live and tells you, in plain terms, whether the thing behind this error is fixed. Free, no account.
Common questions