Mailing lists, DMARC and ARC

9 June 2026 · 14 min read

Mailing lists are one of the few places where correct, well-behaved email authentication still breaks for reasons that are nobody's fault. You publish a clean SPF record, sign your mail with DKIM, set a DMARC policy, and everything passes when you test it. Then someone on your team posts to a discussion list, or a customer subscribes to your announcements list, and the messages that come back out the other side fail DMARC at the recipient's server. Nothing was forged. Nothing was misconfigured. The list software simply did what list software does: it took your message, changed it, and re-sent it from its own infrastructure. That act of rewriting is what collides with DMARC, and it is the reason mailing lists deserve their own discussion separate from ordinary forwarding.

This article explains exactly why mailing lists break DMARC, what a well-run list operator does to limit the damage, why the common "From rewrite" workaround exists and what it costs, and how ARC, the Authenticated Received Chain, lets a receiving server trust a legitimate list message even after SPF and DKIM have been destroyed in transit. If you are moving a domain from p=none towards p=reject and you are nervous about list traffic, this is the failure mode to understand before you enforce.

What a mailing list actually does to your message

A mailing list manager (Mailman, Sympa, Google Groups, a Discourse mailing-list mode, or any of the SaaS equivalents) is not a passive relay. When you send a message to list@example.org, the list software receives it, processes it, and then re-distributes a modified copy to every subscriber. The modifications are the whole point of the product, and almost all of them touch parts of the message that authentication depends on.

Typical changes a list makes:

It adds a subject tag. Most lists prepend something like [dev-team] or [Announcements] to the Subject: header so subscribers can filter list mail. The Subject is almost always one of the headers a DKIM signature covers.
It appends a footer to the body. Unsubscribe links, list archives, posting guidelines and legal disclaimers get added to the bottom of the message body. Any change to the body breaks the DKIM body hash.
It rewrites or adds headers. Lists insert List-Id, List-Unsubscribe, List-Post and similar headers, and may strip or reorder others.
It re-sends from its own servers. The message leaves the list's IP addresses, not yours. The envelope sender (the Return-Path, also called the envelope-from or MAIL FROM) is usually changed to a list bounce address so the list can handle delivery failures.

Each of these is sensible behaviour for a mailing list. Together they are catastrophic for the two mechanisms DMARC relies on.

Why SPF and DKIM both fail through a list

DMARC does not have its own cryptography. It is a policy layer that sits on top of SPF and DKIM, and it passes only when at least one of those two both passes and aligns with the visible From: domain. A mailing list manages to break both at once.

SPF breaks because the sending IP changes. SPF authorises the connecting IP address against the SPF record of the envelope-from domain. When the list re-sends your message, the connecting IP is now the list server, and the envelope-from is usually the list's own bounce domain. So one of two things happens. Either the envelope-from is the list's domain and SPF passes for that domain, which does not align with your From: domain and therefore does nothing for your DMARC; or the envelope-from is still yours, in which case SPF fails outright because the list's IP is not in your SPF record. You cannot fix this by listing the list's IPs, because you do not control which lists your mail passes through, and listing them all would gut the value of SPF anyway. For a refresher on how SPF authorisation is scoped to the connecting IP, see what is SPF and test a record with the SPF checker.

DKIM breaks because the message is modified. A DKIM signature is a hash over selected headers and the body, verified against a public key in DNS. Because the signature travels inside the message, it can survive a relay that touches nothing. That is why plain forwarding often keeps DKIM intact even when SPF dies. But a mailing list does not leave the message alone. The moment it prepends [list-name] to a signed Subject, or appends a footer to the body, the hash no longer matches and the signature fails to verify. The signature was perfectly valid when the message left you; the list invalidated it by editing signed content. Our piece on DKIM alignment and forwarding walks through the hash mechanics, and you can inspect a live signature with the DKIM checker.

Now combine them against DMARC alignment:

SPF either fails or passes only for the list's domain, which does not align with your From:.
DKIM fails because the body and Subject were changed.
DMARC therefore fails, because neither authenticated, aligned identifier survives.

The message is genuinely from you, was authenticated correctly at origin, and still earns a DMARC fail at every subscriber's server. The deeper background to alignment is in DMARC alignment explained, and the closely related plain-forwarding case is covered in the DMARC forwarding problem and forwarding and DMARC.

Why this only became a real problem at enforcement

For years this failure mode was invisible to most senders, because most domains sat at p=none. At p=none, a DMARC failure changes nothing about delivery: the receiver still delivers the message, and the only trace is a line in an aggregate report. List traffic failed DMARC quietly and harmlessly, and nobody noticed.

The picture changes the instant you move to p=quarantine or p=reject. Now a DMARC failure has teeth. A subscriber's mail server, seeing your From: domain on a message that fails DMARC, applies your published policy: it sends the list copy to spam, or rejects it outright. The list operator then sees bounces from your domain's subscribers, and depending on the list software, those bounces can get the affected subscribers automatically disabled or removed from the list. So a domain that tightens DMARC without thinking about lists can quietly knock its own people off the discussion lists they depend on, and annoy every other list whose members happen to use that domain. This is one of the specific fears that kept organisations parked at p=none and its false sense of security for far too long. The reassuring news, covered in will enforcing DMARC break my email, is that with the right preparation it does not have to.

What list operators do about it

If you run a mailing list, the breakage is partly yours to mitigate, because some of it comes from choices in how the list modifies mail. There is a spectrum of options, from "stop breaking DKIM" to "rewrite the author entirely".

Stop breaking DKIM where you can

The least invasive fix is to leave the signed parts of the message alone. If a list does not add a Subject tag and does not append a body footer, the original DKIM signature can survive intact, which means DKIM still passes and aligns, which means DMARC still passes even though SPF is broken by the IP change. DKIM only needs to survive for DMARC to survive. Concretely, a list operator can:

Turn off Subject prefixing, or accept that prefixing will break DKIM for any author domain at enforcement.
Turn off body footers, or move unsubscribe and archive information into headers like List-Unsubscribe rather than the body.
Avoid re-encoding or content-transfer-encoding changes that alter the body bytes.
Preserve, rather than strip, the original DKIM-Signature header.

Many modern lists offer exactly these settings precisely so they can stay DMARC-friendly. The trade-off is a plainer subscriber experience: no convenient [list] tag in the Subject, no footer. For lots of lists that is an easy trade once the alternative is understood.

Apply ARC as an intermediary

The more complete answer, and the one the standards intend, is for the list to participate in ARC: to record the authentication results it saw on arrival, sign them, and pass that sealed record forward so the receiver can trust the original verdict even after the list's edits. ARC is what makes "the list changed the message but here is proof it was authentic when it arrived" a statement a receiver can verify. We come back to how this works below, and it is covered in depth in ARC explained.

Rewrite the From header

When a list cannot or will not preserve DKIM, and cannot rely on ARC being honoured, the blunt instrument is to rewrite the author. This is the workaround that deserves its own section, because almost everyone running a list at scale has met it.

The From-rewrite workaround

The From-rewrite (sometimes called "From munging") is the list operator's nuclear option for surviving a strict DMARC policy. The idea is simple. DMARC alignment is checked against the domain in the visible From: header. If the list changes that header so it no longer shows the original author's domain, then DMARC is evaluated against the list's domain instead, and the list can make that pass cleanly.

A rewritten message looks roughly like this. The original was:

From: Jane Author <jane@yourbrand.com>

After the list rewrites it, subscribers see:

From: Jane Author via Dev List <dev-list@example.org>
Reply-To: jane@yourbrand.com

The list now owns the From: domain (example.org), signs the outgoing message with its own DKIM key and sends from its own SPF-authorised IPs, so SPF and DKIM both pass and align with example.org. DMARC passes. The original author's address is usually preserved in Reply-To: or in the display name so replies still reach the right person.

This works, and it is widely deployed, but it is genuinely a workaround and it has real costs:

It damages the user experience. The author's real address disappears from the most prominent field. Recipient-side rules that filter or file by sender break. Address-book matching and avatars break. "Reply to author" versus "reply to list" gets confusing.
It launders identity. The message no longer cryptographically asserts the author's domain at all. Anyone could have posted as "Jane Author" to a list that does not verify membership, and the rewritten header would look the same.
It only triggers when needed, which is inconsistent. Good list software rewrites the From only for authors whose domains publish an enforcing DMARC policy, leaving everyone else's From intact. So the same list shows two different sender formats depending on each author's DMARC posture, which is confusing for subscribers and fiddly for operators.
It does nothing for your domain's reputation. Mail that should have built sending reputation for your domain now builds it for the list's domain instead.

From-rewrite is best understood as the compromise list operators reach for when the better mechanisms are unavailable. It keeps mail flowing, at the price of throwing away the author's authenticated identity. If your subscribers are mostly on big consumer mailboxes that honour ARC, a list can often avoid rewriting at all and let ARC carry the original verdict instead. That is the better outcome for everyone, and it is what ARC was built to enable.

How ARC helps the receiver

ARC, the Authenticated Received Chain, exists to solve precisely the mailing-list case: a legitimate intermediary modifies a message in ways that break SPF and DKIM, and we need the final receiver to be able to tell that the message was authentic before the intermediary touched it. ARC is defined in RFC 8617 and sits alongside, not instead of, SPF, DKIM and DMARC.

The core idea is a chain of custody for authentication. When a message reaches an ARC-aware list, the list records three things into the message as an ARC set:

ARC-Authentication-Results (AAR): a frozen snapshot of the SPF, DKIM and DMARC verdicts the list saw on arrival, before it made any changes. This is where the original "DKIM passed, DMARC passed" verdict is captured and preserved.
ARC-Message-Signature (AMS): a DKIM-like signature over the message as the list forwards it onward, using the list's own key, so a later receiver can confirm nothing was altered after the list sealed it.
ARC-Seal (AS): a signature over the ARC headers themselves, including every earlier ARC set, which binds the chain into an ordered, tamper-evident whole.

When the final receiver gets the message, SPF and DKIM still fail on the message as delivered, exactly as before. But the receiver can now also read the ARC chain, verify the seals, and see that the first ARC-aware hop reported a clean DMARC pass for your domain. If the receiver trusts that intermediary, it can choose to deliver the message despite the surface-level DMARC failure, because it has cryptographic evidence that the failure is an artefact of legitimate list processing rather than a forgery.

Two points matter and are easy to get wrong:

ARC is informational, not authoritative. It never forces delivery. It hands the receiver a trustworthy account of "here is what authentication looked like before the list got involved, and here is who is vouching for it". The receiver still decides, based on whether it trusts the intermediaries in the chain. A reputable list's ARC seal carries weight; an unknown forwarder's seal carries little.
It is the receiving and forwarding infrastructure that implements ARC, not you. As the original author, there is nothing you configure to "turn on ARC" for your outbound mail. ARC is added by the intermediary (the list) and honoured by the final receiver (the subscriber's mailbox provider). The large consumer providers do add and check ARC, which is why list mail to them survives enforcement far better than it used to.

The full header-by-header walkthrough, including the cv= chain-validation status and how multiple hops nest, is in ARC explained. For the broader category of "my mail passed everywhere except through a forwarder", see the DMARC forwarding problem.

What you should actually do

The right response depends on whether you are a domain owner sending to lists, or the operator running one.

If you own a sending domain

You can still reach p=reject while your people use mailing lists. The key is that list breakage is expected and, on ARC-honouring receivers, handled. Practical steps:

Do not stay at p=none out of fear of lists. The list failures you see in reports are mostly delivered fine by ARC-aware receivers. Staying weak to protect list traffic leaves your domain spoofable for a problem that ARC already mitigates. Plan the move with DMARC: from none to reject safely.
Read your aggregate reports and identify list sources before you enforce. Mailing-list traffic shows up as a recognisable source: passing DKIM for the list's domain, or failing both, from list IPs. Learn to recognise it so you do not mistake it for an attacker. Our DMARC report analyzer and the guide to reading DMARC reports help you tell legitimate list mail from spoofing. Sources you cannot place are covered in DMARC reports show unknown sources.
Use a subdomain strategy if a particular workflow is heavily list-bound. You can publish a different policy on a subdomain using the sp tag or a dedicated record, so a low-risk bulk subdomain enforces differently from your primary domain. See subdomain DMARC records and the subdomain policy sp guide.
Confirm your own SPF and DKIM are aligned and healthy first. ARC only helps if the original verdict was a pass to begin with. If your mail is failing DMARC before it ever reaches a list, fix that first with the DMARC checker and the troubleshooting in DMARC fails but SPF and DKIM pass.

If you operate a mailing list

You can be a good citizen and keep author mail authenticated:

Preserve DKIM wherever possible. Drop Subject tags and body footers for messages from enforcing domains, or as a default, so the original signature survives and DMARC passes on DKIM alignment alone.
Add ARC. Sign an ARC set on every outbound message so receivers that honour ARC can trust the original verdict. This is the mechanism that lets you stop rewriting From headers.
Reserve From-rewrite for the cases that truly need it. Rewrite only for authors whose domains publish p=quarantine or p=reject and only where ARC is unlikely to be honoured, so you do not degrade everyone's experience unnecessarily.
Handle bounces gracefully at enforcement. Do not auto-remove subscribers for DMARC-driven bounces caused by your own modifications; that punishes users for an operator-side issue.

The short version

Mailing lists break DMARC because they rewrite messages: a Subject tag or a body footer invalidates DKIM, and re-sending from list servers invalidates SPF, so both of DMARC's underlying checks fail at once even though the message is genuine. List operators mitigate this by leaving signed content alone to preserve DKIM, by adding ARC so receivers can trust the pre-modification verdict, and, as a last resort, by rewriting the From header to the list's own domain, which keeps mail flowing but throws away the author's authenticated identity. ARC is the proper fix: it lets a trusted list vouch, cryptographically, for the authentication results it saw before it changed anything, so the final receiver can deliver legitimate list mail without weakening your DMARC policy.

None of this should keep you at p=none. With aligned SPF and DKIM, a clear read on your report data, and the knowledge that ARC-aware receivers already handle list traffic, you can take your domain to enforcement without breaking the lists your people rely on. If you would rather not assemble and watch all of this by hand, hosted DMARC does the staged rollout, the report monitoring and the source classification for you, and the DMARC checker will tell you in seconds where your domain stands today.