Email authentication

Usage of discussion lists and DMARC

Discussion lists can pose a ‘challenge’ while implementing DMARC. The reason for this is that discussion lists typically distribute the message to the list members. In doing so, impersonating the initial sender of the message. While this is (and has been for a long time) the intended workflow for discussion lists, this can introduce issues 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 discussion list forwards your message to their members and impersonates your address, authentication will fail for these messages.

Some discussion lists have already changed their behaviour, by no longer using the ‘From’ header of the initial sender, but creating a ‘customized’ From header. This results in emails which are sent from (for example): ‘[email protected]’ with proper authentication for the ‘’ domain.

Furthermore, some discussion lists are set up to rewrite messages only in certain scenarios. For example, Google Groups will rewrite the message only if the sending domain is enforcing DMARC. This means that when your domain has a p=none policy, you will still see this volume in the DMARC data. Google will not rewrite the message and maintain the original ‘From’ header. However, if you update your policy to p=quarantine or p=reject, they will rewrite the message.

This results in a DMARC compliant message with a different ‘From’ header which also removes these messages from your DMARC data.

How can I track this?

You can see examples of this situation (Google Groups specific) if you check the ‘Per sending source’ overview within the DMARC Analyzer Suite. The ‘Forwarding’ category will show the volume for these emails. The contents of this group has some specifics:

  • The SPF domain for these emails are Google Suite using domains
  • The DKIM domain for these emails is the same as the ‘SPF domain’ OR it defaults to the ‘’ domain preceded by a normalized version of the SPF domain (for example
  • A ‘local policy’ was applied to these emails optionally indicated with ‘arc=pass’


What should I do?

When working with discussion lists you need to take into account that the setup for the resulting emails can change in some situation when enforcing DMARC (for instance when working with Google Groups as specified above). Enforcing DMARC to p=quarantine or p=reject could result in:

  • your users losing messages from their discussion lists
  • their messages not reaching all subscribers on the lists
  • possibly causing the users to be unsubscribed from these lists as well
  • Or the messages could arrive from a different sender (From header) due to rewriting


Can I fix it?

Not really at this point. There is a new specification which solves issues regarding email forwarding and DMARC which is called ‘ARC’. This specification is all about adding the initial authentication results of a message to that message while forwarding it. The next receiving server 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 intermediate servers and use that in the final judgement of the message. Please note that ARC should be implemented at ISP level, so you can’t implement this yourself.