Introduction
Mailing lists represent a small percentage of all emails sent, but is a known gap when it comes to email authentication. Mailing lists will sometimes cause problems for authentication due to a mailing server and a sending domain mismatch. However, common implementations like Google Groups have workarounds for the issue.
This article covers how mailing lists work and what you can do to help mailing list deliverability.
DMARC uses the user visible "From" address, so when a member of the mailing list receives an email, the email gateway will see "@example.com." The actual sending server, however, is the mailing list server.
As an example, if an email is sent by jane.doe@example.com, the other members of the list will get an email that has a "From:" address of jane.doe@example.com. Because the mailing list server will not be listed in example.com's SPF record, it will not pass aligned SPF (and therefore will not be authenticated).
Note Because the email will have been modified when passing through the mailing list server, any DKIM signature will also be invalidated, even if the server preserves the EnvelopeFrom (which many do not).
There are two main ways to allow mailing list participation from someone whose domain is at DMARC enforcement.
Changing the "From" address
The main reason mailing list emails fail authentication is that the mailing list server is not authorized to send on behalf of the members' domains.
Some commercial mailing list applications (Mailing List Manager or MLM), see below, will auto-detect when a member's domain is at DMARC enforcement and change the "From" address without the mailing list provider needing to do anything. For those that don't, the most common way to address this is to change the "From" address of the email when sending to the members of the list. This is sometimes called 'munging.'
A new "From" address will typically be owned by the mailing list provider. This allows the provider to send authenticated emails as their own domain if they've configured SPF/DKIM. Many, including the most common open source mailing lists like Mailman, require the mailing list administrator to enable this.
Using this approach prevents members of the list from seeing the original sender in the "From" address. This is one of the reasons that ARC was created.
Authenticated Received Chain (ARC)
ARC allows the mailing list provider to verify an email, using DMARC. When a member's message is received, ARC signs the email when forwarding it to the final destination.
If the receiving gateway trusts the mailing list server, the receiver can deliver the email even if it does not authenticate via DMARC. This allows the mailing list provider to continue to send emails to members where the "From" address of the sender is preserved.
Authenticated Received Chain (ARC) is primarily intended to solve the mailing list problem in a global and open way, suitable for use by independent mailing list vendors. Increasingly, we see adoption of OpenARC.
Valimail has been extremely active in helping move this standard forward. Once ARC sees a wider rollout, this side effect should be mitigated.
Additional articles for further reading:
https://www.valimail.com/blog/arc-rfc-8617/
https://www.valimail.com/technical-articles/what-is-arc/