Mailinglists can form a ‘challenge’ while implementing DMARC. The reason for this is that mailinglists typically forward the message to the list members while pretending to be the initial sender of the message. While this is (and has been for a long time) the intended workflow for mailinglists, this does introduce an issue when working with DMARC.
For DMARC it is very important that your domain (which is used in the ‘From’ header) equals the domain used in the SPF and/or DKIM authentication. When a mailinglist forwards your message to their members and mimics your address, authentication will fail for these messages.
Some mailinglists have already changed their behaviour on this by no longer using the ‘From’ header of the initial sender, but creating a ‘customized’ From header. This results in mails which are sent from (for example): ‘[email protected]’ with proper authentication for the ‘mailinglist.com’ domain.
Furthermore some mailinglist are setup to re-write messages only in certain scenarios. For example Google Groups will re-write the message only if the sending domain is enforcing DMARC. This means that when your domains has a p=none policy, you will still see this volume in the DMARC data as Google will not rewrite the message and maintain the original ‘From’ header. However if you update your policy to a p=quarantine or p=reject, they will rewrite the message.
How can I track this?
You can see examples of this situation (Google Groups specific) if you checkout the ‘Per sending sources’ page in the DMARC Analyzer Suite. The ‘Forwarding’ category will show the volume for these mails here. The contents of this group has some specifics:
– The SPF domain for these mails are Google Suite using domains
– The DKIM domain for these mails is the same as the ‘SPF domain’ OR it defaults to the ‘gappssmtp.com’ domain preceded by a normalized version of the SPF domain (for example domain-com.gappssmtp.com)
– A ‘local policy’ was applied to these mails
What should I do?
When working with mailinglists you will need to the into account that the setup for the resulting mails will change while enforcing DMARC. Enabling DMARC could result in your users losing messages from their mailinglists or their messages not reaching all subscribers on the lists and possibly causing the users to be unsubscribed from these lists as well.
Is there a better solution?
Not really at this point. There is a new specification which tries to solves issues with regards to mailinglists and DMARC which is named ‘ARC’. This specification is all about adding the initial authentication results of a message to that message while forwarding it. The next hop in the process can validate the results of the initial receiver. This does require the final recipient of the message to be able to judge the reputation for the hops which were visited ‘in transit’ and also base the final judgement on the message on their reputation for these hops.