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

URL: https://iblockspam.com/blog/dmarc-and-mailing-lists
Last updated: 2026-10-10
Published: 2026-10-10
Topic: SPF, DKIM & DMARC
Author: iBlockSpam Team

> Why mailing lists break DMARC, how list software rewrites From or wraps posts, where ARC fits, and what RFC 9989 says about p=reject when your users post to lists.

## Short answer

A mailing list resends your post from its own servers, so SPF can't align with your domain, and subject tags or footers break your DKIM signature. With nothing aligned, DMARC fails. Most list software now rewrites From to the list's domain. RFC 9989 says domains whose users post to lists should avoid p=reject, or stage it using reports first.

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](https://iblockspam.com/blog/email-forwarding-breaks-spf-dmarc-arc).

## 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](https://www.rfc-editor.org/rfc/rfc7960.html), 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:

| List behavior | What it breaks |
|---|---|
| Adding a tag such as `[club]` to the Subject | The signed Subject header |
| Adding a footer with list or unsubscribe details | The body hash (`bh=`) |
| Removing MIME parts or converting to plain text | The body hash |
| Encrypting the body for each recipient | The body hash |
| Rewriting banned words | The body hash |
| Moderator comments added to the post | The body hash |

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](https://iblockspam.com/blog/dkim-signature-header-explained) 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](https://www.rfc-editor.org/rfc/rfc9989.html), 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](https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/handlers/docs/dmarc-mitigations.html) page defines the `dmarc_mitigate_action` setting, applied to "messages From: a domain publishing a DMARC policy of reject or quarantine":

| Value | What Mailman does |
|---|---|
| `no_mitigation` | "Make no transformation to the message." |
| `munge_from` | "Change the From: header and put the original From: in Reply-To: or in some cases Cc:." |
| `wrap_message` | "Wrap the message in an outer message with headers from the original message as in munge_from." |
| `reject` | "Bounce the message back to the sender" with a default or custom reason |
| `discard` | "Silently discard the message." |

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)](https://www.rfc-editor.org/rfc/rfc8617.html) 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](https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/config/docs/config.html) 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](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-arc-configure), and our [forwarding guide](https://iblockspam.com/blog/email-forwarding-breaks-spf-dmarc-arc) 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](https://iblockspam.com/tools/dmarc-report-analyzer) groups these rows by source in your browser. Our guide on [how to read DMARC reports](https://iblockspam.com/blog/how-to-read-dmarc-reports) explains each field.

To confirm with a single message, open a list copy in the [Email Header Analyzer](https://iblockspam.com/tools/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](https://iblockspam.com/tools/dmarc-checker).
2. If you're still at `p=none`, follow our [p=none to p=reject guide](https://iblockspam.com/blog/dmarc-none-to-reject-small-business) and watch for list sources at each step.
3. Read [why DMARC fails](https://iblockspam.com/blog/why-dmarc-fails) for the other common causes you'll see in the same reports.

Browse our other [SPF, DKIM and DMARC guides](https://iblockspam.com/blog/topic/authentication).

## Frequently asked questions

### Why do my emails to a mailing list fail DMARC?

The list sends your post from its own servers, so SPF checks the list's domain, not yours. Most lists also add a subject tag or footer, which breaks your DKIM signature. DMARC needs at least one aligned pass, so with SPF unaligned and DKIM broken, it fails, and a p=reject policy can get your post rejected by subscribers' mail servers.

### What is From munging on a mailing list?

From munging means the list replaces the From address on a post with its own address, so the message aligns with the list's domain instead of yours. The author's name usually stays in the display name, for example 'Anne Person via Ant', and the original address moves to Reply-To or Cc so replies still reach the author.

### Can p=reject get people unsubscribed from mailing lists?

Yes. When subscribers' servers reject list copies of your post, the list sees bounces. Many list managers count bounces and automatically unsubscribe addresses that keep bouncing. RFC 9989 and RFC 7960 both describe this: subscribers can be removed from lists because of someone else's DMARC policy.

### Does ARC fix DMARC for mailing lists?

Only partly. ARC lets a list record that your post passed authentication when it arrived, and seal that record. Receivers that trust the list can use it to override a DMARC failure. But RFC 8617 is experimental, receivers decide which sealers to trust, and RFC 9989 says no such method has become widely used.

### Should my company publish p=reject if staff use mailing lists?

RFC 9989 says domains with users who might post to mailing lists should not publish p=reject, and those that do should first check the impact. Spend at least a month at p=none and an equal period at p=quarantine, compare the reports, and tell staff that list participation may be affected. Most modern list software rewrites From, which reduces the risk.

## Sources

- [RFC 9989: DMARC, section 7.4 (Interoperability Considerations)](https://www.rfc-editor.org/rfc/rfc9989.html)
- [RFC 7960: Interoperability Issues between DMARC and Indirect Email Flows](https://www.rfc-editor.org/rfc/rfc7960.html)
- [RFC 8617: The Authenticated Received Chain (ARC) Protocol](https://www.rfc-editor.org/rfc/rfc8617.html)
- [GNU Mailman 3 documentation: DMARC Mitigations](https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/handlers/docs/dmarc-mitigations.html)
- [GNU Mailman 3 documentation: Configuration ([ARC] section)](https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/config/docs/config.html)
- [Microsoft Learn: Configure trusted ARC sealers](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-arc-configure)

## Free tools for this guide

- [DMARC Checker](https://iblockspam.com/tools/dmarc-checker): Check your policy, reporting and the safe path from p=none to reject.
- [DMARC Report Analyzer](https://iblockspam.com/tools/dmarc-report-analyzer): Read DMARC aggregate reports (XML, gzip or zip): see who sends as your domain and what fails — runs in your browser.
- [Email Header Analyzer](https://iblockspam.com/tools/email-header-analyzer): Trace hops and authentication results — runs entirely in your browser.
- [DKIM Checker](https://iblockspam.com/tools/dkim-checker): Validate DKIM keys by selector, including key type and strength.

---

Source: iBlockSpam, https://iblockspam.com/blog/dmarc-and-mailing-lists (this is a Markdown copy; the HTML page is canonical). Quote with attribution and a link. Site index for AI assistants: https://iblockspam.com/llms.txt