A mailing list often does more than copy a message to another address. It may change the envelope, add a subject prefix, append a footer, rewrite the visible author or add its own signature. These choices affect different authentication paths and user expectations. Diagnose the list as a redistribution service with documented behavior, not as an unexplained exception to DMARC.
Inventory the list transformations
References: RFC 7960 §3.2.3.
Obtain an authorized original submission and one redistributed copy. Record the list software and configuration, subscription or moderation state, envelope identity and relevant message headers. Compare the body and signed headers before and after processing. Identify which changes are necessary for the community and which are incidental defaults that can be removed.
RFC 7960 describes interoperability challenges in indirect flows. Use it for the problem analysis, while applying the current DMARC specification in RFC 9989. A historical discussion of mitigation does not certify that a particular current provider accepts the list's implementation.
Separate author and redistributor identities
References: RFC 9989 §4.4, RFC 7960 §4.1.3.1.
A list envelope can support bounce handling under the list's domain. That SPF identity usually differs from the original author's From identity. A list-domain DKIM signature can authenticate the redistributed message but likewise does not automatically align with the author domain. If an original aligned DKIM signature survives unchanged, it may still supply the required path.
Rewriting the visible From into a list-controlled domain changes the identity against which DMARC is evaluated. It also changes what the recipient sees. Review reply behavior, attribution, accessibility and the handling of Reply-To rather than treating rewriting as only a DNS trick. Do not imply that the list owns or can sign for the author's domain.
Compare controlled outcomes
References: RFC 9989 §5.3.5.
The checkpoint model contains a preserved-forwarding case, a footer-modification case and a list-rewritten case. In the last case, visible From, authenticated envelope and signing domain all use list.example, so strict identity comparison passes. The result says nothing about whether a real list performed cryptographic signing or whether users find the resulting presentation acceptable.
The raw sample messages and hash comparison are synthetic. They do not contain a real list submission, a production bounce trace or a receiver-generated authentication result. The retained evidence includes a historical direct-versus-list local delivery pair below; production list behavior remains unverified. Keep that gap explicit when reviewing a proposed rollout.
Choose a supported operating mode
References: RFC 7960 §4.1.3.3, RFC 8617 §7.2.1.
First test whether the list can preserve signed content without removing required community features. If it cannot, assess supported author rewriting or provider-specific handling with the list owner. ARC may carry earlier assertions, but chain validity alone does not create trust or require acceptance. RFC 8617 remains Experimental while an active draft proposes Historic reclassification and recommends against reliance between disparate senders and receivers. Review that proposal before adding a new dependency; it is not completed retirement. Do not introduce a universal allowlist as the default repair.
Pilot changes with consenting list participants and reversible configuration. Test replies, moderation notices, digests, attachments and unsubscribe flows, not just a plain-text post. Retain the original configuration and identify who can revert it. Measure delivery separately from alignment and user-visible attribution.
Document the chosen identity policy so support staff can explain it without claiming that a list signature proves the original author's approval of modified content. Revisit the decision when software, recipient-provider behavior or authentication specifications change. An acceptable community workflow needs both reliable operation and an honest account of which organization authenticated the redistributed message.
Retained laboratory evidence
References: RFC 6376 §6, RFC 9989 §4.4.
The retained 7 November 2026 local list experiment rewrote visible From to Alice via list at list.example, appends the footer, then signs using list.example. Actual SMTP carries this message from 127.0.0.3 with list@list.example as the envelope. The receiver observes SPF and DKIM pass and computes strict alignment with list.example. In contrast, the footer appended after the original author signature invalidates that signature. Raw direct and list outputs preserve the visible attribution change. No production mailing-list software or subscriber usability test was exercised.
The retained runner and 7 November 2026 capture were inspected; no network experiment was rerun for this review. The original experiment used loopback only and sent no Internet mail. Its receiver creates Authentication-Results from its own checks, giving those fields known laboratory provenance. Authentication outcome and disposition remain separate: all six SMTP samples receive 250 under an explicit capture policy, including failing samples. The trust boundary is this controlled laboratory, not a production mailbox provider. The DNS adapter supplies retained fixture answers rather than querying public DNS, and the DMARC evaluator uses strict domain equality only. Full organizational-domain discovery, production policy parsing and live deployment outcomes remain untested.