Mailing lists can change the very content an original DKIM signature protects. A subject prefix, footer, MIME rewrite or author-header change can alter the result. Diagnose each transformation and the list's own signing behavior before deciding whether the problem is cryptographic verification, alignment or receiver handling.
Capture the list boundary
Use a controlled message sent both directly and through the list. Obtain the original submission where authorized, the list's redistributed message and the final receiver's trusted authentication result. Record the visible From domain before and after redistribution and every DKIM signing domain.
A footer can change the body hash. A subject prefix can invalidate a signature that covers Subject. MIME rebuilding can change the body representation even when displayed text is similar. Under RFC 6376 §5.4, From must be covered by a DKIM signature, so rewriting it changes protected header content for the original signature. The exact outcome still depends on canonicalization, coverage and all other checks.
Distinguish the list's signature
RFC 6376 §5.5 says a modifying list manager implementing DKIM should check an existing signature on input and must make modifications before re-signing. A new signature can authenticate the list's final content under the list's signing domain. It does not retroactively restore the original signature or automatically assert the original author's domain.
For DMARC, examine alignment against the final Author Domain under RFC 9989 §4.4.1. If the list retains the original author domain but signs only with an unrelated list domain, the new DKIM pass alone is not an aligned path. If a supported list configuration rewrites From to a list-controlled domain and signs with an aligned domain, the identities evaluated at the receiver are different. That change has user-visible reply and attribution consequences and should be reviewed, not treated as a hidden technical switch.
Walk through a controlled comparison
Illustrative case: an original message from an author domain has a valid full-body signature. The list adds a footer and signs the modified message using its own unrelated domain while preserving the original From. The original signature can fail and the list signature can pass, yet the latter does not by itself meet DKIM alignment for the original From. This explains why a generic “DKIM pass” label can be misleading.
Use a second test only if the list offers a supported alternative, such as a different modification or author-handling policy. Compare receiver results and human-facing reply behavior. Do not assume every list product has the same options or that every receiver will make the same acceptance decision.
Choose a documented list policy
Possible design choices include reducing unnecessary modifications, signing the final redistributed content, or using supported author-handling behavior with clear attribution. Each choice should be tied to the list's purpose and current product documentation. Avoid enabling partial-body coverage through l as a universal footer workaround; RFC 6376 §8.2 warns about unsigned appended-content risks.
If a receiver accepts legitimate indirect mail through a local exception or additional trusted evidence, document that decision separately from the DKIM and DMARC verdicts, consistent with RFC 9989 §5.3.6. Do not weaken the author's entire domain policy merely because one list path needs investigation.
Validate the reader experience
Test plain text, HTML and attachments, plus Reply and Reply All behavior. Preserve both authentication evidence and a human review of attribution. A completed fix shows which identity takes responsibility for the redistributed message, which original guarantees survive, and how subscribers can reply without being misled.
Evidence needed for the next decision
Use a hypothetical list run to fill one row per signature: original/list identity, signed headers, body coverage, verification result and alignment to the final Author Domain. If the original fails and the unrelated list identity passes, check SPF alignment separately before assigning a DMARC result. Capture reply behavior before approving any visible identity rewrite. These are proposed review steps, not executed tests.