Forwarding is structurally hostile to email authentication. A mailing list, an alias, or a university forwarder re-sends a message from a different server with a different envelope sender, so SPF fails at the final destination through no fault of the original sender. ARC exists to carry the earlier verdict forward.
The problem in one sentence
SPF authenticates the envelope sender, and the envelope sender is whoever is sending now. When a forwarder re-sends, that is the forwarder. DMARC binds alignment to the From header, which did not change, so the message fails alignment and gets quarantined — even though it was perfectly authenticated at the first hop.
DKIM survives forwarding better, because it signs content rather than transport, but a forwarder that rewrites a subject line, adds a footer, or re-encodes the body breaks the body hash. So the three classic mechanisms all degrade in the presence of a legitimate intermediary.
What ARC actually does
RFC 8617 defines the Authenticated Received Chain as a set of headers a participating intermediary adds at each hop. Rather than re-authenticating, the chain records what was known at the point of receipt, cryptographically sealed, so the final receiver can evaluate a sequence of prior verdicts instead of only the current hop.
Three header groups form a set: ARC-Authentication-Results, ARC-Message-Signature, and ARC-Seal. Each hop that participates adds one of each, and the seal chains the current hop's headers to the previous seal, so removing or altering an earlier entry invalidates the chain from that point onward.
The architectural point is that ARC does not assert "this message is authentic." It asserts "at hop N, this is what the authentication state was," signed by the hop that observed it. The final receiver decides how much to trust a given intermediary.
Why trust is the whole difficulty
A sealed chain from a domain you have never heard of is worth approximately nothing. ARC's value depends entirely on whether the final receiver has a reason to trust the sealer. This is why the specification spends as much space on trust relationships as on the header format, and why ARC in practice works for known forwarders — large mailing list providers, established alias services — rather than as a general-purpose fix.
It also means ARC is not a mechanism you can adopt unilaterally. A sender can sign with DKIM; a sender cannot force a receiver to trust a chain. Publishing ARC headers from an unvetted forwarder can, in the worst case, look like an attempt to launder a failing message.
What to check when forwarded mail is being quarantined
- Does the forwarder preserve DKIM? Many break the body hash by appending a footer. Suppressing that footer restores DKIM and often makes ARC unnecessary.
- Is the forwarder rewriting
From? A list that rewritesFromto itself is doing the right thing for deliverability, and DMARC alignment is evaluated on the rewritten domain. - Does the forwarder participate in ARC? If yes, the question becomes whether the receiving side trusts it.
- Is the original message actually authentic? An ARC chain that carries a
dmarc=failfrom hop one is honest information, not a repair.
The testing angle
Forwarding behaviour is one of the hardest things to test because it involves two independently operated systems. The practical approach is to hold one side constant: send through your own pipeline to a real address behind a known forwarder, capture the raw message at the final destination, and inspect the headers rather than the verdict. You want to see whether Authentication-Results at the final hop reports the original DKIM as pass, and whether any ARC set survived intact.
A disposable inbox with a raw-message endpoint is enough for the capture half. The forwarder still has to be real, because the failure you are looking for only happens in transit.
The takeaway
Forwarding breaks SPF by design and DKIM by accident. ARC carries the earlier authentication verdict across the break, sealed and chained, and its usefulness is bounded entirely by whether the final receiver trusts the sealer. When forwarded mail is being quarantined, check the DKIM-preservation behaviour of the forwarder before reaching for ARC, and when you do reach for ARC, understand that you are asking for trust rather than proving authenticity.