ARC Explained: How Email Survives Mailing Lists Without Failing DMARC

You set up SPF, DKIM, and a strict DMARC policy. Then a member of your team posts to a mailing list, the list software appends a footer and rewrites the subject, and the message lands in everyone's spam folder — rejected by your own authentication rules. ARC is the standard built to fix exactly this, and it does it in a way that quietly depends on trust.

Modern email authentication rests on three layers that work well together until something in the middle touches the message. SPF checks that the sending server is authorized for the envelope sender's domain. DKIM cryptographically signs selected headers and the body so a recipient can verify nothing was altered. DMARC ties them together and tells receivers what to do when both fail. For a message that travels straight from sender to recipient, this chain is robust. The trouble starts the moment an intermediary stands between them.

Why Forwarders Break Authentication

Mailing lists, forwarding services, and some corporate gateways do not just relay a message — they modify it. A discussion list might prepend [list-name] to the subject, add an unsubscribe footer to the body, or strip an attachment. Each of those edits invalidates the DKIM signature, because the signature covered the exact bytes that just changed.

SPF fares no better. When a list re-sends your message to its subscribers, the connecting server is the list's server, not yours. SPF evaluated against the list's IP for your domain fails, and even when the list rewrites the envelope sender to its own domain, that breaks alignment — the property DMARC requires between the authenticated domain and the visible From: address.

The core failure: A legitimate message, sent by a real author, relayed by a legitimate mailing list, arrives looking exactly like a forgery: DKIM broken, SPF unaligned, DMARC fail. Strict p=reject policies then bounce mail that everyone involved actually wanted delivered.

For years the workaround was for receivers to maintain hand-tuned exceptions for known mailing lists, or for list operators to rewrite the From: header entirely so authentication evaluated against the list's own domain. Both are ugly. The header rewrite, in particular, hides the real author behind the list's identity. Email authentication needed a way to carry trustworthy authentication results across a hop that legitimately altered the message.

What ARC Actually Does

The Authenticated Received Chain, specified in RFC 8617 (published as Experimental in 2019), lets each intermediary record the authentication results it observed and cryptographically vouch for them. The idea: if your message passed DKIM when the mailing list received it, the list can seal that fact into the message. The final receiver then sees "this message failed DMARC now, but a chain of intermediaries I trust attest that it passed when it entered the chain."

ARC does not force the receiver to accept anything. It supplies evidence. The receiver still decides whether the sealing intermediaries are trustworthy enough to override a DMARC failure. That distinction — evidence, not command — is the whole reason ARC is safe to deploy and also the reason it is not a silver bullet.

The Three Header Fields

Each participating intermediary adds an ARC set: three header fields stamped with an instance number (i=1 for the first hop, i=2 for the second, and so on). Together the sets form the chain.

The final validator computes a chain validation status, cv=, which is pass, fail, or none. A cv=pass means the entire seal chain verified intact: no set was tampered with, and the message's authentication history is internally consistent. The receiver can then look at the earliest AAR — what authentication looked like before any forwarder touched the message — and use it to make a delivery decision the broken current-state DMARC check can't.

ARC Runs on Trust, and That Is the Catch

Here is the part that gets glossed over. A valid ARC chain proves the chain was not modified after the fact. It does not prove the intermediaries told the truth. A malicious or compromised forwarder can seal a completely fabricated "DKIM=pass" result into a forged message, and the seal will validate perfectly — because the seal only attests "I, this intermediary, claim I saw this."

ARC moves the question from "did this message survive forwarding intact?" to "do I trust the parties that forwarded it?" That is a better question, but it is still a trust question — not a cryptographic guarantee about the original sender.

So receivers apply ARC selectively. They override DMARC failures only when the sealing domains appear on a curated trust list — large, reputable mailing-list operators and forwarding providers with a track record. An ARC seal from an unknown domain carries little weight. This makes ARC genuinely useful between established players and largely inert for the long tail, which is an honest trade-off rather than a flaw: it fails closed.

Where ARC Sits in the Stack

ARC is not a replacement for SPF, DKIM, or DMARC — it is a repair layer that only activates when a message has passed through intermediaries. Most mail never needs it. It complements transport-level protections like MTA-STS and TLS-RPT, which secure the connection between servers rather than the provenance of the message. And like all of these mechanisms, it protects metadata and authenticity, not confidentiality — none of them stop the mail provider from reading your message, which is why zero-knowledge email and end-to-end encryption address a different problem entirely.

If you run a domain: You generally don't need to generate ARC seals unless you operate a forwarding service or mailing list. You benefit from ARC automatically when major receivers honor seals from the lists your mail passes through. The deployment work falls on intermediaries, not ordinary senders.

The Takeaway

Authentication and confidentiality are separate problems that both deserve real answers. ARC can tell a receiver that your message is genuinely from you, even after a mailing list mangled it; it does nothing to stop a provider in the middle from reading it. Run the full modern stack — SPF, DKIM, DMARC, DNSSEC — so your mail is verifiable, and reach for end-to-end encryption when the contents themselves need protecting. Authentication keeps your identity honest. Encryption keeps your contents yours. You want both.

Originally published at havenmessenger.com