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.

"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.