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.

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