MailDingo

dkim=fail

dkim=fail

The message was signed, but it no longer matches its signature, usually because something changed it on the way or the published key is wrong.

dkim=fail means the message had a signature the receiver was prepared to check, it fetched the key, and the arithmetic didn't work out. Either the body has changed since it was signed, or the signed headers have, or the key in DNS doesn't belong to the private key that made the signature. A fail is not proof of forgery. Legitimate mail fails DKIM all the time.

What the RFC says

RFC 8601 §2.7.1 defines fail as a signature that was acceptable to the receiver but failed verification. RFC 6376 §6.1.3 lists the two places it can go wrong: the body hash doesn't match bh= ("body hash did not verify"), or the header signature in b= doesn't validate ("signature did not verify"). Many receivers put one of those phrases in a comment. The RFC is also clear about what to do with a failure: treat the message like one that was never signed, and don't penalize it beyond that (RFC 6376 §6.1 and §6.3).

Authentication-Results: mx.example.org;
       dkim=fail (body hash did not verify) header.d=example.com header.s=sel2026;
       spf=pass smtp.mailfrom=lists.example.net;
       dmarc=fail header.from=example.com;
       arc=pass
List-Id: <members.lists.example.net>

Usual causes

Body hash mismatch: the body was changed.

  • A mailing list added a footer, rewrote the subject or re-encoded attachments (RFC 7960 §2.3). That is what the snippet shows.
  • A security gateway rewrote links for click-scanning, or added an "external sender" banner.
  • The sender's own system appended a disclaimer or tracking pixel after signing.
  • A relay converted 8-bit text to quoted-printable along the way.

Signature mismatch: headers changed, or the wrong key.

  • A relay edited a signed header such as Subject, or a header was re-folded and the signer used simple canonicalization.
  • The DNS record under the selector holds a different public key from the private key in use, often after a botched key rotation. In that case every message fails, including mail sent straight to a test mailbox.

If you received this message

Check the path. If the Received chain shows a list server or a forwarding hop, a failure is expected, and an arc=pass from the intermediary may be how your provider decided to accept it anyway (RFC 8617 §7.2.1). If the message came straight from the claimed sender, has no other valid signature, and DMARC failed, be wary.

If you own the domain

Send a test message to a mailbox you control and read the comment. If even direct mail fails with "signature did not verify", compare the selector's DNS record with your provider's current key. If only mail through lists or gateways fails, nothing on your side is broken. Make sure DKIM, not SPF alone, carries your DMARC result, and ask list operators to seal with ARC.

See it in your own message

Paste the headers into the analyser to see which domain DKIM checked and whether it lines up with the From address.

Open the analyser

Related

DKIM explainedHow a DKIM signature is built (d=, s=, bh=, b=), what canonicalization tolerates, what a pass really proves about the sender, why lists and footers break signatures, and how keys rotate. Forwarding and mailing listsWhy plain forwarding breaks SPF (and how SRS works around it), why mailing lists break DKIM and DMARC, why lists rewrite the From line ('via'), where ARC fits, and how each case looks in the headers. ARC explainedHow the Authenticated Received Chain records authentication results across intermediaries, how to read ARC-Seal, ARC-Message-Signature and ARC-Authentication-Results, and why a valid chain only matters if the receiver trusts the sealer. dkim=neutralThe message had a signature, but the receiver couldn't use it, so it treats the message as if it had not been signed. arc=passThe servers that relayed this message, such as a mailing list or forwarder, recorded what they saw, and their records arrived intact.