ARC and Mailing List Noise: Why DMARC Breaks on Forwarding – and How RFC 8617 Fixes It

The Problem: DMARC Breaks on Mailing Lists

You’ve set up DMARC properly. SPF and DKIM are aligned, your policy is p=reject. Everything works — until someone forwards your email through a mailing list. Suddenly, legitimate messages land in spam or get rejected outright. What happened?

Mailing list software like Mailman, Listserv, or Google Groups modifies messages before distributing them to subscribers. New List-* headers are added, the subject often gets a prefix like [ListName], and sometimes the body is slightly altered. That’s enough to break the original sender’s DKIM signature. On top of that, the mailing list sends from its own IP address, which isn’t in the sender domain’s SPF record. Result: SPF fails, DKIM is invalid — DMARC sees an unauthenticated message and acts accordingly.

What ARC Is — and What It Isn’t

ARC stands for Authenticated Received Chain and is specified in RFC 8617. It doesn’t solve a security problem in the traditional sense — it solves a trust problem in forwarding chains.

The idea: every intermediary (mailing list, forwarder, security gateway) adds and signs three new headers when forwarding a message:

• ARC-Authentication-Results — the authentication status of the message as the intermediary saw it
• ARC-Message-Signature — a DKIM-like signature over the message content at that point in time
• ARC-Seal — a signature over the entire ARC chain up to that point

The receiving mail server can unwind this chain. If it trusts the first link in the chain — the mailing list software — it can decide to deliver the message despite a failed DMARC check.

Important: ARC does not replace DMARC. It gives the receiving server additional information to make an informed decision. Whether it acts on that information is entirely up to that server.

What the Chain Looks Like in Practice

A concrete example: [email protected] sends an email to a mailing list hosted at list.example.org. The list forwards it to [email protected].

1. Gmail receives the message from list.example.org.
2. SPF for example.com fails — the sending IP belongs to the mailing list.
3. DKIM for example.com is invalid — the subject line was modified.
4. DMARC would normally trigger reject or quarantine.
5. But: list.example.org set and signed ARC headers. Gmail evaluates the ARC chain, sees that the mailing list observed a valid DMARC result on receipt, and trusts that information.

Gmail, Microsoft 365, and Fastmail actively evaluate ARC chains today. That’s not a delivery guarantee, but it prevents legitimate mailing list messages from being blanket-rejected.

What You Can Do as a DMARC Operator

ARC is primarily a task for mailing list operators and intermediaries, not for the original sender. That said, there are concrete steps you can take.

If you run a mailing list: Make sure your software sets ARC headers. Mailman 3 supports ARC natively. Postfix needs the opendkim package with ARC support, or a dedicated tool like arc-milter. Also check whether your mailing list domain has its own DKIM key — many mailing lists re-sign messages with their own domain, which establishes DMARC alignment for the list domain.

If you’re the original sender: You can’t control ARC directly, but you can make your DKIM signature more resilient. Avoid signing headers that mailing lists typically modify (e.g., Subject). Instead, sign the body and stable headers. Some senders use l= tags to sign only part of the body — that’s a double-edged sword and should be used carefully.

If you’re reading DMARC reports: ARC-related failures show up in your DMARC aggregate reports. Messages that came through mailing lists and failed DMARC appear as fail entries with the mailing list’s sending IP. If you recognize those IPs as legitimate forwarders, you can document them as a known pattern — even if you can’t fix it directly.

The Limits of ARC

ARC isn’t a silver bullet. A few limitations worth knowing:

Trust is not universal. Whether a receiving server trusts an ARC chain depends on its own policy. There’s no central registry of trusted ARC intermediaries — every provider decides for itself.

ARC doesn’t prevent abuse. An attacker could theoretically forge their own ARC chain. That’s why trust in the first intermediary is critical — and that trust is based on reputation, not cryptography alone.

Not all mailing list software supports ARC. Older installations of Mailman 2, Listserv, or proprietary systems often don’t set ARC headers. This is a deployment problem that’s slowly improving but isn’t solved yet.

DMARC Reports as an Early Warning System

The most practical step for any DMARC operator: look closely at your aggregate reports. If you’re regularly seeing failures from known mailing list IPs, that’s a clear signal that ARC is either not configured or not taking effect.

DMARCPulse surfaces exactly these patterns — which sources are consistently failing, whether they look like forwarding scenarios, and whether the failures point to an ARC issue or a fundamental configuration problem.

Check how your domain is set up right now: Free domain check at DMARCPulse