opendkim signature verification failed on legitimate relayed mail

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

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.