dkim-signature header stripped by outbound relay so verification fails downstream

Not specified by the original author.

TL;DR

Find the hop that removes the header and stop it removing authentication headers: check gateway and connector settings for header stripping, disclaimer, or hygiene rules that drop unknown or X- headers, confirm with before and after copies of the same message, exempt the DKIM-Signature and related authentication headers, and retest so the signature that leaves your signer is the signature the receiver verifies.

"dkim-signature" header stripped by outbound relay so verification fails downstream

Use this when

• Mail is signed at source, confirmed in logs, but arrives with no DKIM-Signature header.
• Receivers report dkim=none or neutral and DMARC then relies on SPF alone.
• One gateway, relay, or list in the path is known to rewrite or strip headers.

Not for this skill when

• The signature is present on arrival but fails verification. That is content modification, not stripping.
• Mail was never signed because the signing service was down. Restore signing first.

Steps

1. Capture the message immediately after signing and as delivered, and compare the full header lists. Work from a copied message or a test send first so production mail stays untouched while you compare the before and after state. Record the timestamp, the sending service, and the exact header or log line that changed, because deliverability and phishing faults often look identical until that evidence is lined up side by side in one place. Verify: the hop after which DKIM-Signature disappears is isolated
2. Review that hop configuration for header removal rules, hygiene filters, and any strip or anonymise features. Do not change more than one setting at a time here. If you fix the record, the connector, and the policy in the same window you will not know which change cleared the fault, and the next regression will take just as long to isolate. Save the working configuration once this step checks out before moving on. Verify: the rule or feature that removes the header is named in the config
3. Exempt DKIM-Signature, ARC headers, and Authentication-Results handling as appropriate for that hop, following the product guidance. Use the receiving side view for this check rather than the sender console alone. Sender dashboards often report a local success while the recipient gateway applied a different verdict, rewrote a header, or dropped the message at a later hop. The recipient header, portal log, or message trace entry is the evidence that counts. Verify: the saved config no longer lists the authentication headers for removal
4. Send a test through the identical path and compare headers again at delivery. Keep any exception you create narrow and time boxed. Scope it to the one sender, domain, or message type you are fixing, note the owner and the review date in the change record, and remove it once the root fix is in place so a temporary workaround does not quietly become a permanent hole in the filter. Verify: the delivered copy carries the original DKIM-Signature unchanged
5. Check receiver verdicts on the test at an external mailbox. Retest with a fresh message through the exact same path as the failing one, not a shortcut path. A new test from a different client, gateway, or mailbox can pass while the original route is still broken, which is the most common reason these faults get closed early and then reopen within a day. Verify: the external copy shows dkim=pass and dmarc evaluation uses the aligned signature

Why it happens

Some relays strip headers they do not recognise as a hygiene or privacy measure, and older gateway rules sometimes remove headers matching broad patterns. DKIM-Signature looks like metadata a cleaner might drop, but it is the proof the signature exists at all. Once it is gone, no receiver can verify the message, and if SPF alignment is also lost in forwarding, DMARC fails outright on otherwise perfectly legitimate mail.

Variants and edge cases

dkim-signature header stripped by outbound relay verification fails

The exact header name phrasing from the comparison.

signed mail arrives unsigned gateway removes dkim header

The symptom phrasing used before the stripping hop is known.

dkim header missing after exchange connector gateway hop

The connector variant for Microsoft 365 hybrid and gateway paths.

Compatibility: RFC 6376 DKIM, RFC 8617 ARC, Exchange transport rules, cloud email gateway header policies.

Edge cases to check:

• A hop that strips and re-signs is acceptable if the re-signing domain is understood; silent stripping with no replacement is the fault.
• Check antivirus and DLP appliances in the path; several strip headers during message reconstruction.

Provenance

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

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

Thread query: "dkim-signature" header stripped by outbound relay so verification fails downstream

TL;DR: Find the hop that removes the header and stop it removing authentication headers: check gateway and connector settings for header stripping, disclaimer, or hygiene rules that drop unknown or X- headers, confirm with before and after copies of the same message, exempt the DKIM-Signature and related authentication headers, and retest so the signature that leaves your signer is the signature the receiver verifies.

Not specified by the original author.

TL;DR

Find the relay that edits the message after it was signed and stop the edit or re-sign after it. Compare the message as it left the signer with the copy the verifier saw, looking for header rewrites, line re-wrapping, encoding changes, or added disclaimers at each hop, then move signing to after the last modifying hop or disable the modification, and retest through the full relay chain.

opendkim "signature verification failed" on legitimate relayed mail

Use this when

• OpenDKIM logs signature verification failed for mail that arrives through a relay or gateway.
• The same sender verifies fine when mail comes direct.
• A disclaimer, banner, or header rewrite is applied somewhere in the relay path.

Not for this skill when

• Your own signing milter is down. That produces unsigned mail, not a verification failure downstream.
• The sender key record is wrong in DNS. That fails on every path, not just the relayed one.

Steps

1. Collect the failing message and a passing direct message from the same sender and compare their signed headers and body formatting. Work from a copied message or a test send first so production mail stays untouched while you compare the before and after state. Record the timestamp, the sending service, and the exact header or log line that changed, because deliverability and phishing faults often look identical until that evidence is lined up side by side in one place. Verify: the difference between the relayed and direct copies is documented
2. List every hop in the relay path and note which systems are known to add disclaimers, rewrite headers, or convert encoding. Do not change more than one setting at a time here. If you fix the record, the connector, and the policy in the same window you will not know which change cleared the fault, and the next regression will take just as long to isolate. Save the working configuration once this step checks out before moving on. Verify: each hop is marked as modifying or pass-through
3. Disable or move the modification for a test, or move signing after it, and send through the identical relay path. Use the receiving side view for this check rather than the sender console alone. Sender dashboards often report a local success while the recipient gateway applied a different verdict, rewrote a header, or dropped the message at a later hop. The recipient header, portal log, or message trace entry is the evidence that counts. Verify: the test message content reaching the verifier matches what was signed
4. Re-enable the intended design cleanly: either the relay re-signs with its own key after modifying, or it stops modifying signed mail. Keep any exception you create narrow and time boxed. Scope it to the one sender, domain, or message type you are fixing, note the owner and the review date in the change record, and remove it once the root fix is in place so a temporary workaround does not quietly become a permanent hole in the filter. Verify: the chosen design is in the saved configuration, not just in a live test
5. Send a final relayed test and check the OpenDKIM and receiver verdicts. Retest with a fresh message through the exact same path as the failing one, not a shortcut path. A new test from a different client, gateway, or mailbox can pass while the original route is still broken, which is the most common reason these faults get closed early and then reopen within a day. Verify: verification passes on the relayed path and is logged as pass

Why it happens

DKIM covers selected headers and the body exactly as signed. Relay hygiene features were mostly built before DKIM mattered, so gateways happily append legal disclaimers, re-wrap long lines, convert 8-bit content, or rebuild MIME parts, and each edit invalidates the signature. The verifier is correct to fail the message; the design fault is signing before a hop that is known to edit, without re-signing afterwards.

Variants and edge cases

opendkim signature verification failed relayed mail disclaimer added

The disclaimer variant naming the most common modifying hop.

dkim fails through gateway but passes direct relay changes message

The path-comparison phrasing admins use once the pattern is clear.

inbound dkim verification failed legitimate mail mime conversion

The encoding conversion variant for gateways that rebuild MIME.

Compatibility: OpenDKIM 2.11 verifying mode, Postfix and Sendmail relays, Exchange and cloud gateway disclaimer rules.

Edge cases to check:

• A relay that adds a header not covered by the signature is harmless; only changes to signed headers or the body break verification.
• Check line length re-wrapping on plain text mail from older systems; it is an invisible but signature breaking edit.

Provenance

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

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

Thread query: opendkim "signature verification failed" on legitimate relayed mail

TL;DR: Find the relay that edits the message after it was signed and stop the edit or re-sign after it. Compare the message as it left the signer with the copy the verifier saw, looking for header rewrites, line re-wrapping, encoding changes, or added disclaimers at each hop, then move signing to after the last modifying hop or disable the modification, and retest through the full relay chain.

Not specified by the original author.

TL;DR

Forwarding breaks DKIM when the forwarder changes anything the signature covers: the body, a signed header, or line endings and encoding. List servers that add footers, gateways that rewrite subject lines, and mailing software that re-wraps MIME are the classic causes. Find what changed by comparing the message as signed with the message as received, then use a forwarding method that preserves the body or adds ARC.

dkim signature verification failed after mail forwarding

Use this when

• DKIM passes on direct mail but fails after a mailing list, helpdesk or forwarding hop.
• Only recipients behind one particular forwarder report dkim=fail.

Not for this skill when

• DKIM fails on the first hop before any forwarding. That is a signing fault, not a forwarding fault.
• SPF fails after forwarding but DKIM holds. That is expected SPF behaviour handled by alignment.

Steps

1. Take one failing forwarded message and one passing direct message from the same sender and compare their DKIM-Signature headers and signed header lists. Verify: you know which headers were signed.
2. Diff the bodies: look for an added footer, disclaimer, tracking rewrite or MIME re-encoding introduced by the forwarder. Verify: any body change is identified by name.
3. Check whether the forwarder added ARC headers and whether the receiver honoured the ARC chain. Verify: ARC presence and receiver handling are known.
4. Remove the modification where you control the forwarder: disable footer insertion and subject tagging for signed mail, or configure the list to leave the body intact. Verify: a test forwarded message arrives byte-identical in its signed parts.
5. If you do not control the forwarder, rely on ARC sealing at each hop and on receivers that validate it, and keep DMARC alignment on DKIM so SPF loss does not matter. Verify: forwarded test mail shows dmarc=pass via DKIM.

Variant phrasings

dkim fails after mailing list footer added

The list-server variant naming the specific body change.

arc headers forwarding dkim preservation

The fix variant for uncontrolled forwarders.

Compatibility: RFC 6376 DKIM, RFC 8617 ARC, common list and forwarding gateways.

Why it happens

A DKIM body hash is computed over the exact body bytes. Any later insertion changes the hash even when the visible text looks the same. Header signatures fail the same way when a signed header such as Subject is edited in transit.

Edge cases / pitfalls

• Relaxed canonicalisation tolerates whitespace changes but not added content. A footer still breaks it.
• SRS fixes SPF rewriting for forwarding; it does nothing for DKIM. Do not treat SRS as a DKIM fix.
• Some forwarders strip and re-sign with their own domain. That verifies, but alignment with the original From domain is lost.

Provenance

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

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

Thread query: dkim signature verification failed after mail forwarding

TL;DR: Forwarding breaks DKIM when the forwarder changes anything the signature covers: the body, a signed header, or line endings and encoding. List servers that add footers, gateways that rewrite subject lines, and mailing software that re-wraps MIME are the classic causes. Find what changed by comparing the message as signed with the message as received, then use a forwarding method that preserves the body or adds ARC.