A mailing list receives one message and creates a new delivery path. The author's original SPF result does not automatically transfer to that path, and a footer or subject change can invalidate an original DKIM signature. Treat Mailman DMARC mitigation as a change to message handling, not as a universal DNS repair.
Identify the installed behaviour
Record the Mailman Core version, administrative interface, outbound MTA and existing list settings. The cited current documentation is the 3.3.11b1 development documentation branch; compare it with the documentation shipped for your installed release. Its rule inspects the From domain when mitigation is enabled and flags eligible messages for handling. The handler provides From rewriting and message wrapping. A documented setting is not proof that your host exposes it in its management interface.
Keep receiving authentication separate from redistribution authentication. A message accepted at the list can fail at a subscriber after redistribution. Likewise, a successful list subscription confirmation does not test ordinary posts with footers and subject prefixes.
Choose a mitigation deliberately
References: RFC 9989 §4.4, RFC 6376 §3.7.
Start with a private test list whose configuration matches production. Preserve a configuration export or screenshots and a sample post before changing anything. In the available list settings, review the DMARC mitigation action and whether it applies conditionally or unconditionally. In the cited implementation, unconditional mitigation does not make reject or discard apply to all posts; that setting applies only when the action is neither reject nor discard. Do not copy a Mailman 2 setting name into Mailman 3 without checking the interface or API for that installation.
From rewriting moves the visible author address to an identity controlled by the list. Wrapping puts the original message inside another message. These approaches have different consequences for reply targets, address books, archives and accessibility. Rejecting or discarding a post changes participation rather than repairing its eventual authentication. Choose the least disruptive option that meets the list's documented delivery requirements.
Arrange aligned signing at the outbound MTA for the identity the subscriber will actually see. Mailman mitigation alone is not evidence that the outbound server signs mail correctly. Where author identity is preserved, determine whether an aligned author signature survives every modification; do not assume a new list-domain signature aligns with an unrelated author domain.
Run a small acceptance matrix
Send controlled posts from domains with different authentication and policy configurations. Include plain text, HTML, attachments and a signed message with the production footer enabled. At a mailbox you control, retain the original received source, trusted receiver authentication results, visible From, envelope domain and each DKIM signing domain. Check reply-to-author and reply-to-list separately. Review archive presentation using non-sensitive synthetic content. Mailman documents these mitigations for individual member deliveries, not digests, archives or NNTP; test those other outputs separately rather than assuming they are rewritten too.
Illustrative comparison: a post arrives from writer@example.org and leaves with From set to list@lists.example.net. A passing DKIM signature for lists.example.net can align exactly with the new From domain. It does not authenticate the original writer as the owner of example.net. The example describes identities only; it is not a live Mailman test or a delivery guarantee.
Deploy and maintain the decision
Pilot one low-risk list with an announced reply-behaviour change. Record the chosen action, scope, outbound signing owner and known client limitations. Watch bounces and subscriber complaints alongside authentication results. If reply behaviour becomes unacceptable, restore the saved list configuration while investigating an alternative route; avoid weakening an author's unrelated domain policy.
After a Mailman upgrade, MTA change or footer redesign, repeat the matrix. Keep the author-facing explanation short: what recipients will see, where replies go and who to contact. Successful authentication remains only one input to a recipient's delivery decision.