DMARC mitigation on `internals@lists.php.net`, proposal to enable From-munging or ARC

I write about a deliverability issue I have been running into when posting to internals@lists.php.net from my phpunit.de address, which I suspect affects other contributors with DMARC-restrictive domains as well.

Disclaimer: I am not an expert on the subject matter. I used an LLM while researching this issue, so take this with a grain of salt.

My domain publishes a DMARC policy of p=reject, which is increasingly common for security-conscious senders. When I post to the list, the list adds the [PHP-DEV] subject prefix (and likely body modifications), which invalidates my original DKIM signature. Because the From: header is preserved unchanged, receivers evaluate DMARC against phpunit.de, find neither SPF nor DKIM aligned, and, per my policy, either reject the message or deliver it to spam for some recipients.

Here is a snippet from the authentication results of a copy I received back from the list:

dkim=fail ("headers rsa verify failed") header.d=phpunit.de header.s=MBO0001
dmarc=fail reason="SPF not aligned (strict), DKIM not aligned (relaxed)" header.from=phpunit.de (policy=reject)

This is a well-known incompatibility between traditional mailing lists and DMARC, and there are two standard fixes that list software has supported for years:

1. From-munging for DMARC-restrictive senders: rewrite the From: header to something like Sebastian Bergmann via internals <internals@lists.php.net> and move the original address into Reply-To:. In Mailman 3 this is dmarc_mitigate_action = munge_from, applied conditionally when the sender's domain publishes p=quarantine or p=reject.

2. ARC signing on outbound mail: the list server attests that it authenticated the message before modifying it, and trusted receivers (Gmail, Microsoft) honor that chain and will not penalize the DMARC failure.

Either should resolve the issue. From-munging is the more universally compatible fix; ARC is the more elegant one. Ideally both.

I understand changes to long-running infrastructure are never trivial, and I am happy to help test or provide whatever diagnostic data would be useful. Thanks for maintaining the list, it is a valuable resource for the community.

Start by inspecting the Ansible playbooks and mailing-list configuration for internals@lists.php.net, then review how the current setup handles DMARC-altering changes. Compare conditional From-munging with ARC signing, and test outbound messages from a DMARC-restrictive domain. Done means affected contributors can receive list mail without DMARC rejection or spam placement.