Mailing lists and DMARC: why they break it, and how ARC picks up the pieces

The list-side countermeasures: rewrite the From, or stop touching anything

Faced with that wall, list operators converged on two broad strategies with opposite philosophies.

The first: From rewriting. The list stops presenting itself as a mere relay and becomes the official author of the message. The header turns into something like From: "Marie Dupont via discussion" <discussion@lists.example.com>, with the author's real address moved into Reply-To. DMARC now evaluates the list's domain — which DKIM-signs its own messages and aligns its own SPF — and everything passes. GNU Mailman, ubiquitous on technical lists, offers this behavior as an option, often triggered only when the author's domain publishes a restrictive policy. The price is semantic: replying privately to the author becomes a gamble, address books memorize the list's address instead of the person's, and the author's real identity survives only in the display name.

The second: non-modification. The list gives up the subject prefix, the footer, any retouching of the MIME body. The original DKIM signature then remains intact and verifiable on arrival — and since DMARC requires only one aligned mechanism, that surviving DKIM is enough: the SPF misalignment no longer weighs anything. It is the cryptographically cleanest route, adopted by a growing number of technical lists. Its cost is ergonomic: the familiar markers disappear from the visible content, the information migrating into the standardized List-Id, List-Post and List-Unsubscribe headers — invisible to the eye but consumed by modern mail clients. A third, historical route — wrapping the original message as an attachment inside a fresh message emitted by the list — preserves everything but degrades reading so badly that it has practically vanished.

ARC, the chain of custody for authentication results

Both countermeasures above fix the symptom by sacrificing something: the author's identity, or the list's habits. ARC (Authenticated Received Chain, RFC 8617, published in 2019 with experimental status) attacks the problem from another angle: rather than avoiding the breakage, it documents the chain of custody, like a signed evidence log at every link.

The principle: each intermediary that handles the message stamps three numbered headers onto it (i=1, i=2…). ARC-Authentication-Results records the authentication results observed on arrival at that intermediary — for instance spf=pass, dkim=pass, dmarc=pass at the moment the list received the message from the author. ARC-Message-Signature signs the message as retransmitted, modifications included. ARC-Seal seals the whole chain, guaranteeing no link was tampered with after the fact. The final receiver, confronted with a DMARC failure, can then walk back up the chain: if it is intact and the seal comes from an intermediary deemed trustworthy, the receiver knows the message was properly authenticated before the list — and may choose to deliver it despite the policy. The protocol is taken apart in detail in how ARC works.

The limit sits in that last sentence: deemed trustworthy. ARC authenticates a testimony, not the honesty of the witness. Any server can seal a formally valid ARC chain asserting that everything was fine at the origin — including a spammer sealing its own garbage. The value of a chain therefore depends entirely on the reputation the receiver grants the sealer, and no public registry of trusted intermediaries exists: every large receiver maintains its own. Gmail and Microsoft 365 both seal and honor ARC at scale; a small self-hosted list on an anonymous VPS will see its seals politely ignored. ARC thus rescues a large share of the legitimate breakage at the big providers, but it is neither a universal guarantee nor a reason to abandon good list-side practice.

What a RUA report shows

For the owner of the author's domain, all of this leaves a recognizable fingerprint in the aggregate reports. The typical signature of list traffic: a source IP belonging to the list's server, SPF failing or passing without alignment (the envelope domain is the list's), DKIM failing — or passing for the list's domain, hence unaligned too — and a disposition that follows the published policy. When a receiver has honored an ARC chain, the row says so explicitly:

<policy_evaluated>
  <disposition>none</disposition>
  <dkim>fail</dkim>
  <spf>fail</spf>
  <reason>
    <type>local_policy</type>
    <comment>arc=pass</comment>
  </reason>
</policy_evaluated>

That block reads as follows: the policy called for a sanction, but the receiver overrode it (local_policy) because the ARC chain attested sound authentication upstream. Knowing how to recognize these rows changes everything about interpreting a report. Counting them as spoofing attempts artificially inflates the perceived threat and can trigger needless panic; conversely, under p=reject, the same rows without an ARC override represent real messages, written by real users, permanently lost. An analysis tool that names the sources — this IP is a well-known list operator, that one a university server — shortens the diagnosis from hours to minutes.

Recommendations: list operator versus domain owner

The two roles do not hold the same levers, and confusing them leads to impossible remediation plans.

On the list-operator side, the priority order is clear. First comes an end to message modification: without a subject prefix or a footer, the original DKIM survives and the problem essentially disappears — the List-* headers carry the unsubscribe information perfectly well. Where the list's culture insists on visible markers, From rewriting is the fallback, ideally conditional (applied only to authors whose domain publishes a strict policy). In every case, the baseline stands: DKIM signing with the list's own domain, aligned SPF and DMARC for that domain, ARC seals wherever the platform supports them, and bounce processing audited so that innocent subscribers never again get purged by someone else's policy.

On the domain-owner side, everything depends on the population behind the addresses. A purely application-driven domain — transactional mail, notifications, marketing — has no humans posting to lists: the problem is marginal there and justifies no delay on the road to a strict policy. A domain carrying real human mailboxes, by contrast, demands observation of the reports before any hardening: identifying the list traffic, measuring its volume, warning the teams involved. The choice between quarantine and reject takes on a very concrete meaning here: p=quarantine leaves list messages a chance to land — in spam, but recoverable — where p=reject destroys them outright at receivers that do not honor ARC. DMARCbis's test mode t=y additionally makes it possible to evaluate a policy's effect without enforcing it, buying time to map the domain's real exposure to mailing lists.

In summary

A mailing list breaks DMARC twice over: its edits to the content invalidate the author's DKIM signature, and its re-sending from its own servers leaves SPF unaligned — neither mechanism survives, and the legitimate message fails. The founding incident of 2014 forced two countermeasures onto lists, From rewriting and content non-modification, each with its own sacrifice. ARC adds a third path: a sealed chain testifying to the original authentication, letting the receiver rehabilitate the message — provided the sealer is trusted, which today reserves the benefit for large, well-known intermediaries. In RUA reports, this traffic is recognizable by its characteristic fingerprint and by local_policy overrides; reading it correctly avoids both the false alarm and the silent loss.

The practical starting point costs nothing: running the domain through a free DMARC analysis reveals the state of the authentication mechanisms and how the current policy would treat relayed traffic. To see it through — identifying the lists inside the reports, tracking ARC overrides, hardening the policy without losing a single legitimate message — creating an account opens continuous report monitoring, with the history needed to tell list breakage from genuine impersonation, week after week.