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:
-
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.
-
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.
I write about a deliverability issue I have been running into when posting to
internals@lists.php.netfrom 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 theFrom: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:
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:
From-munging for DMARC-restrictive senders: rewrite the
From:header to something likeSebastian Bergmann via internals <internals@lists.php.net>and move the original address intoReply-To:. In Mailman 3 this isdmarc_mitigate_action = munge_from, applied conditionally when the sender's domain publishesp=quarantineorp=reject.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.