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.
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. SPF, DKIM, and DMARC 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.
| Header field | What it carries |
|---|---|
| ARC-Authentication-Results (AAR) | A snapshot of the standard Authentication-Results at this hop — the SPF, DKIM, and DMARC verdicts the intermediary saw when it received the message. |
| ARC-Message-Signature (AMS) | A DKIM-style signature over the message headers and body as they looked when this hop forwarded them. It captures the message state at this point in the chain. |
| ARC-Seal (AS) | A signature over the ARC header fields of all previous sets plus this set's AAR and AMS. This is the link that chains the sets together so they can't be reordered or selectively removed. |
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. — The practical limit of any chain-of-custody scheme
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.
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.
Where Haven Fits
Haven runs the full modern authentication stack — SPF, DKIM, DMARC, DNSSEC — so mail leaving the platform is verifiable, and we honor authentication signals on inbound mail rather than guessing. But our position on email is that authentication and confidentiality are separate problems that both deserve real answers. ARC can tell a receiver that your message is genuinely from you; it does nothing to stop a provider in the middle from reading it.
That is why Haven pairs standards-based email deliverability with client-side encryption, and why for conversations that need true end-to-end protection we lean on the MLS protocol rather than email at all. Authentication keeps your identity honest. Encryption keeps your contents yours. You want both.