dkim signature verification failed after mail forwarding

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.

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

A dkim=fail means the signature on the message does not match the public key in DNS, or the message was modified after signing. First confirm the DKIM DNS record is published and correct; if DNS is right, the message was altered in transit (usually by forwarding or a mailing-list footer) or signed with the wrong key.

dkim=fail signature did not verify

Use this when

• Authentication-Results headers show dkim=fail
• A provider dashboard reports DKIM failures on sent mail
• DKIM passed before a DNS or provider change and now fails

Not for this skill when

• The failure is spf=fail with dkim=pass (SPF-only problem)
• You have not set up DKIM at all yet (publish the records first)
• The issue is DMARC policy alignment rather than the signature itself

Steps

1. Look up the DKIM record: query [selector]._domainkey.[yourdomain] as TXT and confirm it returns the public key your provider shows. Expected: the DNS value matches the provider's expected value exactly.
2. Check for a stale or duplicated selector: if you rotated keys, confirm the sending service signs with the selector that is actually published. Expected: one active selector, matching on both sides.
3. Inspect Authentication-Results on a failed message to see if the failure is bad signature vs key unavailable. Expected: the reason names DNS vs crypto.
4. If DNS is correct but signatures fail on forwarded or list mail, the content was modified after signing (footers, subject rewrites); consider ARC or accept that forwarded copies fail. Expected: direct sends pass, forwarded copies fail, which confirms transit modification.
5. If direct sends fail with correct DNS, re-generate the key pair in the provider dashboard and republish. Expected: fresh signatures verify.

Variant phrasings

dkim signature did not verify

Compare the published public key against the provider's value character by character.

dkim fail bad signature

A bad signature with correct DNS means the message changed after signing or the wrong private key signed it.

Tool/version compatibility

Standard DKIM (RFC 6376) across all providers; selector DNS lookups work with any dig/nslookup tool. Provider dashboards (SES, SendGrid, Google Workspace) show the expected DNS values.

Why it happens

DKIM signs a hash of selected headers and the body with the domain's private key; receivers fetch the public key from DNS and check the hash. Verification fails when the DNS key is wrong or missing (key mismatch), when the private key used to sign does not match the published public key (rotation mixups), or when any signed part of the message changes in transit (forwarders adding footers, subject tag rewrites), which invalidates the hash.

Edge cases / pitfalls

• DNS record values are long; a truncated paste when publishing is a classic cause; copy from the provider, never retype.
• Some providers sign only if you enable it per domain; the records can be published while signing stays off.
• Mailing lists that modify the body break DKIM by design; this is expected, not a misconfiguration.
• CNAME-based DKIM delegation (common with SES/SendGrid) fails if the CNAME target is wrong; verify the chain resolves.

Provenance

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

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

Thread query: dkim=fail signature did not verify

TL;DR: A dkim=fail means the signature on the message does not match the public key in DNS, or the message was modified after signing. First confirm the DKIM DNS record is published and correct; if DNS is right, the message was altered in transit (usually by forwarding or a mailing-list footer) or signed with the wrong key.