Mailing lists, DMARC and ARC

23 June 2026 · 5 min read

Mail you post to a mailing list often fails DMARC at the subscribers' servers, although it was authenticated when you sent it. The list re-sends it from its own servers, so SPF no longer aligns with your domain, and it usually edits the subject or body, which breaks your DKIM signature. With both gone, a domain at p=quarantine or p=reject asks receivers to junk or refuse the list copies. The current DMARC standard therefore says domains whose users post to mailing lists SHOULD NOT publish p=reject. List operators can limit the damage by not modifying messages, by rewriting the From header, or by adding ARC.

What a list does to your message

RFC 7960, the IETF's account of DMARC and indirect mail, lists the changes list software commonly makes:

• adding a tag such as [dev-team] to the Subject;
• adding a footer, such as unsubscribe instructions, to the body;
• stripping attachments or MIME parts, or converting to plain text;
• adding moderator comments.

It concludes that any of these invalidates a DKIM signature. On top of that, the list sends from its own IP addresses, usually with its own bounce address as the envelope sender.

Why both SPF and DKIM fail

• SPF. If the envelope sender is still yours, SPF fails because the list's servers are not in your SPF record. If the list uses its own bounce address, SPF passes for the list's domain, which does not align with your From address. Either way SPF does nothing for your DMARC result.
• DKIM. A changed Subject or body no longer matches the hash in your signature, so it fails. If the list changes nothing you signed, DKIM survives and DMARC still passes.

So the outcome depends on the list. A list that relays posts untouched keeps your mail passing; one that tags subjects or adds footers does not.

What happens when you enforce

At p=none, list failures only appear in your aggregate reports. At p=quarantine or p=reject, subscribers' servers act on your policy. RFC 7960 describes the knock-on effect: subscribers whose domains publish p=reject may stop receiving list mail, and list software can mistake the resulting bounces for dead addresses and unsubscribe people. That can hit anyone posting from your domain, and other subscribers of the same lists.

This is why RFC 9989, the current DMARC standard, says domains that host users who might post to mailing lists SHOULD NOT publish p=reject, and that domains wanting p=reject anyway should first use their aggregate report data to judge the impact.

What to do as a domain owner

1. Find out whether your users post to lists. List traffic shows up in your aggregate reports as SPF failing, or passing for the list's domain, from list server IP addresses, often with DKIM failing too. The DMARC report analyser groups it by source.
2. Choose your end point. If people post to lists from your main domain, p=quarantine is a defensible place to stop. If list use is confined to a few addresses, consider moving them to a subdomain with its own policy; a DMARC record on a subdomain overrides the parent's.
3. Make sure your own DKIM is aligned. Lists that do not modify messages, and ARC, can only help if your mail passed DMARC when it reached the list. The DMARC checker and DKIM checker confirm your setup.
4. Use t=y to trial a stricter policy. RFC 9989 removed pct=; t=y asks receivers to apply one level less while you watch the reports.

p=none vs quarantine vs reject explains the trade-offs of each level.

What to do as a list operator

Stop breaking DKIM where you can

If the list does not tag the Subject, add a body footer or alter MIME structure, the poster's signature survives and their mail passes DMARC. Put unsubscribe and archive information in List-Unsubscribe and List-Id headers rather than the body. RFC 7960 notes some lists already run this way.

Rewrite the From header for enforcing domains

If you must modify messages, list software can rewrite the From header to the list's address so DMARC is judged against the list's domain. GNU Mailman's DMARC mitigations offer munge_from, which shows the poster "via" the list and moves their address to Reply-To:, and wrap_message, which sends the original message inside a new one from the list. By default Mailman applies them only to posters whose domains publish p=quarantine or p=reject.

The cost, as RFC 7960 puts it, is that this may to some extent defeat the purpose of DMARC: the poster's domain is no longer authenticated, replies behave differently between mail clients, and wrapped messages display poorly in some clients.

Add ARC

The Authenticated Received Chain (RFC 8617) lets the list record the authentication results it saw when the post arrived, and seal them with its own signature before modifying and re-sending. A receiver that trusts the list can then deliver a post that now fails DMARC. ARC does not oblige anyone to accept the message, and it only helps with receivers that check it; Microsoft 365, for example, lets administrators list trusted ARC sealers. ARC explained walks through the headers.

Handle DMARC bounces carefully

Do not unsubscribe members because of rejections caused by your own modifications to their posts.

Related reading

For how other intermediaries rewrite messages, including SRS and gateways, read DMARC and header rewriting. If you want list traffic separated from spoofing in your reports, DMARC analytics groups forwarded mail apart from suspected spoofing.