What the bounce says
Exact wording as it appears in the rejection or NDR. Placeholders such as x.x.x.x and example.com stand for your own address and domain.
dkim=fail (signature verification failed) dkim=fail (body hash did not verify) dkim=neutral (no key for signature) dkim=fail reason="key not found in DNS"
A DKIM failure means the receiver could not confirm the signature matches the message. The reason text is diagnostic: body hash did not verify means the content changed; key not found means the selector is not published; signature verification failed usually means the key in DNS does not match the signing key.
Most common causes
- A gateway, list or forwarder modified the body or a signed header
- The selector record was rotated or removed while mail still used the old key
- The DNS record was truncated or corrupted when published
- The signing configuration signs headers that later change (e.g. Subject prefixes)
What to verify next
- Read the failure reason: body hash mismatch means content changed; no key means the selector is missing
- Inspect the selector with the DKIM inspector and compare the key
- Trace the route to find the hop that modified the message
- Sign fewer volatile headers and use relaxed canonicalization
Body hash mismatches
Something between the signer and the verifier altered the body: a gateway appended a disclaimer, a mailing list added a footer, a security product rewrote links, or a relay re-encoded the message. The signature is mathematically invalid afterwards.
Relaxed body canonicalization tolerates whitespace changes but not content changes. The route visualizer identifies the hop where modification happened.
- Body hash: content changed in transit.
- Key not found: selector missing or wrong.
- Verification failed: key mismatch or truncated record.
Key problems
Selector rotation without keeping the old record published fails mail still in transit. A DNS panel that truncated a long TXT value publishes a corrupt key. A platform signing with one selector while DNS carries another fails every message. The DKIM inspector shows what the selector actually publishes.
Signing configuration
Sign only headers that will not change — avoid signing Subject if lists prefix it — and use relaxed canonicalization. Keep DMARC passing by ensuring SPF alignment as a second path where possible.
Best diagnostic path
Mail Failure Doctor
Classify the complete rejection and preserve provider-specific diagnostic context.
Open analysis → Live analysisDMARC Alignment Lab
Compare visible From, envelope sender and DKIM identities without reducing the result to a pass/fail label.
Open analysis → Live analysisEmail Header Forensics
Inspect From, Sender, Reply-To, Return-Path and transport evidence in the raw message.
Open analysis →Known limits
- The verifier’s reason text varies by implementation.
- Historical failures reflect DNS at delivery time; the selector may have changed since.
Common questions
The key looks right in DNS.
Then the content was modified in transit. Find the hop that changed it.
Does DKIM fail mean rejection?
Not by itself. It removes the DKIM path for DMARC; if SPF aligns, DMARC still passes.
How do I test after a fix?
Send a message through the same platform to a mailbox you control and read Authentication-Results for dkim=pass with your selector.
Why the exact message matters
The same status family can be triggered by different conditions, and providers frequently add diagnostic text that narrows the issue. Use the complete rejection text rather than treating the numeric code as a complete diagnosis.
Provider reference
For the provider-defined meaning and current requirements, review RFC 6376 §6 — Verifier actions.