Why do mailing lists break DMARC, and how do you fix it?

Mailing lists are the oldest headache in DMARC. A post that left your server fully authenticated can arrive at every subscriber looking like a forgery, and with p=reject it may not arrive at all. This guide explains why, what list software does about it, and how to decide on your policy if your staff post to lists. For forwarding and aliases more generally, see why forwarding breaks SPF and DMARC.

Why do mailing lists break DMARC?

DMARC passes when SPF or DKIM passes for a domain that aligns with the visible From address. A mailing list usually breaks both.

SPF. The list receives your post and sends a fresh copy to each subscriber from its own servers, usually with its own bounce address. SPF is checked against the list's domain and may well pass, but that domain doesn't align with yours, so it doesn't count for DMARC.

DKIM. Your signature covers the body and key headers. RFC 7960, which documents DMARC's problems with indirect mail, says lists "very commonly modify headers or message content in ways that will cause DKIM to fail". Its list of typical changes:

RFC 7960 sums it up: "Any such modifications would invalidate a DKIM signature." If you want to see which tag failed, our guide to the DKIM-Signature header shows how to read it.

So a list post from you@example.com typically arrives with SPF passing for the list's domain (unaligned) and DKIM failing for example.com. DMARC fails. What happens next depends on your policy and on each subscriber's mail server.

What happens to list posts when your domain has p=reject?

RFC 9989, the current DMARC standard, describes two kinds of damage in section 7.4:

1. Your posts don't reach subscribers. RFC 9989 says that in practice "mail forwarded through mailing lists with unmodified From: header lines is frequently rejected due to a 'p=reject' policy."
2. Other people get unsubscribed. When a subscriber's server rejects your post, the list sees a bounce. The RFC explains that list software can then cancel that subscriber, because "it looks to the list manager as though the recipient's email address is no longer working". RFC 7960 adds that subscribers can be "inadvertently suspended or removed from the Mailing List".

The second effect is the one people miss. Your policy can cost unrelated subscribers their list membership.

RFC 9989 also tells receivers not to do this: they "MUST NOT reject incoming messages solely on the basis of a 'p=reject' policy" and, without other evidence, "MUST treat such failing mail as if the policy were 'p=quarantine'". But the same section admits that "few Mail Receivers apply any mitigation techniques" for indirect mail. Plan for receivers that reject.

What does mailing list software do about DMARC?

List operators have had a decade to adapt. RFC 9989 notes that "mailing list software has all adopted workarounds to make the From: header line DMARC aligned." RFC 7960 section 4.1.3.3 lists the options.

Rewriting the From address (From munging)

The list replaces your address in From with an address it controls, then signs the post with its own domain. The message now aligns with the list's domain, so DMARC checks the list's policy instead of yours. RFC 7960 describes three variants:

1. Use the mailing list's own address.
2. Use a locally defined address that forwards back to the author. RFC 9989 gives the example of bob@example.com becoming bob=example.com@user.somelist.example.
3. Break the domain, for example by adding .invalid. RFC 7960 warns this "may create issues because it is an invalid domain name".

The author's name usually survives in the display name. RFC 7960 cautions that it must not look like an email address or domain, and admits these changes "may to some extent defeat the purpose of DMARC itself."

Wrapping the message

The list sends a new message from its own address, with your original post attached as a MIME message/rfc822 part. Your DKIM signature stays intact inside. The drawback, per RFC 7960, is that many clients, "especially mobile clients, have difficulty reading such messages".

Other approaches

• Don't modify the post at all. No subject tag, no footer. Your DKIM survives and DMARC passes on it. Some lists run this way; it's a big change for lists that rely on tags.
• Refuse posts from strict domains. Reject posts from domains with any policy other than p=none. Members may see that as unfair exclusion.
• Ignore DMARC bounces. Don't count authentication rejections toward automatic unsubscribes.

How GNU Mailman 3 does it

Mailman is widely used and documents its settings publicly. The Mailman 3 DMARC mitigations page defines the dmarc_mitigate_action setting, applied to "messages From: a domain publishing a DMARC policy of reject or quarantine":

A second setting, dmarc_mitigate_unconditionally, applies the action to every post regardless of the author's policy, but only when the action is neither reject nor discard. In Mailman's own example, Anne Person <aperson@example.com> becomes Anne Person via Ant <ant@example.com>, with the original address moved to Reply-To. The docs note that these transformations apply to individual messages, not digests or archives.

Other list platforms have their own equivalents. Check your platform's documentation for its exact setting names.

Where does ARC fit?

ARC (RFC 8617) is the attempt to let lists keep From unchanged. The list checks your SPF, DKIM and DMARC on arrival, records the results in ARC headers and seals them with its own signature. A receiver that trusts the list can then use those recorded results instead of the broken ones.

Mailman 3 supports ARC signing, but its configuration reference shows it ships with enabled: no, so the operator must turn it on. On the receiving side, Microsoft 365 lets admins add trusted ARC sealers, and our forwarding guide walks through that setup.

Keep expectations modest. RFC 8617 is an Experimental RFC and states that "ARC is not a trust framework". RFC 9989 says that, as of its publication, none of the methods to keep lists working without changing From "have become widely used". From rewriting remains the workaround you can count on.

Should you publish p=reject if your users post to lists?

RFC 9989 is direct about this. Domains "that host users who might post messages to mailing lists SHOULD NOT publish Domain Owner Assessment Policies of 'p=reject'." If you want p=reject anyway, it sets out a process:

1. Publish p=none "for at least a month" and read your aggregate reports.
2. Publish p=quarantine "for an equally long period of time" and compare the results.
3. Then decide. If you go to p=reject, RFC 9989 says you should have policies "that their users not post to Internet mailing lists and/or inform their users that their participation in mailing lists may be hindered."

In practice, many organizations do reach p=reject, because most active lists now rewrite From. The risk is concentrated in older or self-hosted lists. Your reports show which ones matter to you.

How to spot list traffic in your DMARC reports

Look for rows where:

• the source IP belongs to a list host or a forwarding service, not one of your senders;
• SPF passed for a domain that isn't yours, and DKIM for your domain failed;
• the volume is small and steady, matching how often your staff post.

The DMARC Report Analyzer groups these rows by source in your browser. Our guide on how to read DMARC reports explains each field.

To confirm with a single message, open a list copy in the Email Header Analyzer. A List-Id header, a dkim=fail with a body hash error and ARC headers from the list's domain point to list damage rather than spoofing.

A checklist for each role

If you own the sending domain:

1. Sign all mail with DKIM using your own domain. It's what survives lists that don't edit posts.
2. Stage your rollout as RFC 9989 describes, and read the reports at each stage.
3. Tell staff which lists are known to fail, and suggest they post from an address on a domain with a looser policy if participation matters.

If you run a list:

1. Turn on From rewriting for authors whose domains publish p=quarantine or p=reject, or for everyone.
2. Sign outgoing posts with DKIM for the list's domain and keep its SPF accurate.
3. Turn on ARC signing if your software supports it.
4. Don't unsubscribe members for DMARC-related bounces.

If you receive list mail:

1. Consider trusting the ARC seals of lists your users rely on.
2. Avoid allow-listing a whole list host; it lets spoofed mail through too.

Next steps

1. Check your current policy with the DMARC Checker.
2. If you're still at p=none, follow our p=none to p=reject guide and watch for list sources at each step.
3. Read why DMARC fails for the other common causes you'll see in the same reports.

Browse our other SPF, DKIM and DMARC guides.