What is ARC (Authenticated Received Chain)?

The one-sentence version

ARC (Authenticated Received Chain) is a way for each mail server that forwards a message to record how authentication looked when it arrived, so the final inbox can still trust mail that an intermediary modified, even after SPF and DKIM have broken.

The problem ARC solves

SPF authenticates the sending IP. DKIM signs the message. DMARC passes if either one passes and aligns with your From: domain. Forwarding breaks both halves:

• A forwarder (a mailing list, a “forward all my mail” rule, a security gateway) relays from its own IP, so your SPF fails at the new hop.
• Mailing lists often rewrite the subject (adding a [list] tag) or append a footer. That changes the body, which invalidates your DKIM signature.

When both break, DMARC fails, on mail you actually sent. At p=reject, that forwarded copy can be refused. We cover the plain-English version in why forwarded mail still passes DMARC.

How ARC works

When an ARC-aware server receives a message, evaluates authentication, and then forwards it, it stamps three header fields (an “ARC set”) onto the message:

• ARC-Authentication-Results (AAR) is a frozen snapshot of the Authentication-Results at that hop: what SPF, DKIM, and DMARC said before anything downstream changed.
• ARC-Message-Signature (AMS) is a DKIM-style signature over the message as it looked at that hop, so a later server can confirm the snapshot describes this exact message.
• ARC-Seal (AS) is a signature over the entire chain of ARC headers so far, including every previous hop. This is the “seal” that makes the chain tamper-evident.

Each hop adds its own set with an instance number (i=1 for the first, i=2 for the second, and so on), so the chain reads like a numbered, signed paper trail of every server that touched the message. Each sealer records what it found in its ARC-Seal's cv= tag: cv=none (no chain yet, so this is the first hop), cv=pass, or cv=fail. The final receiver validates the whole chain and writes its own verdict as arc=pass, arc=fail, or arc=none in Authentication-Results.

ARC-Seal: i=1; a=rsa-sha256; cv=none;
  d=lists.example.org; s=arc; b=<seal-signature>
ARC-Message-Signature: i=1; a=rsa-sha256;
  d=lists.example.org; s=arc; h=from:to:subject; b=<msg-signature>
ARC-Authentication-Results: i=1; lists.example.org;
  spf=pass dkim=pass dmarc=pass

Why you mostly cannot “set up” ARC

ARC is not a record you publish. There is no DNS entry you add to turn on ARC for your domain the way you publish SPF or DMARC. Two other parties do the work:

• The intermediary (the mailing list, forwarder, or gateway) has to seal the message, adding the ARC set as it forwards.
• The final receiver (Google, Microsoft, Yahoo) has to evaluate the chain and decide whether to honor it.

The major mailbox providers take part: Google and Microsoft evaluate ARC chains (Microsoft 365 lets admins name the sealers they trust), and Yahoo's sender guidance tells anyone who forwards mail to implement ARC. The forwarder in the middle is the variable. If it does not seal, there is no chain for the receiver to trust.

When ARC helps, and when it does not

ARC passes information, not a verdict. A valid chain tells the final receiver “an earlier, trusted hop saw this pass DMARC before it was modified.” The receiver may then accept the message even though SPF and DKIM now fail. But:

• It is a local policy decision. ARC never forces acceptance. The receiver still chooses whether to trust the sealer.
• Trust is the catch. A receiver only honors a chain sealed by an intermediary it already trusts. A homemade forwarding script can seal all it likes; Gmail will not necessarily trust it.
• It is still Experimental. ARC is RFC 8617 (July 2019), published on the Experimental track. Adoption is wide among large providers but not universal.

So ARC raises the odds that legitimate forwarded mail survives p=reject. It is not a guarantee, and it is not a substitute for getting your own SPF and DKIM right.

What you should actually do

You cannot deploy ARC yourself, but you can stop it from being a mystery:

• Do not panic at forwarding failures. A burst of SPF-fail, DKIM-pass (or both-fail) mail from a mailing-list or forwarder IP is usually legitimate forwarded mail, not someone forging your domain. The fix is rarely to weaken your policy.
• Tell forwarding from spoofing. In trustyourinbox, the failure breakdown separates mail the receiver itself reported as forwarded from everything else, and the Senders page splits identified senders from unknown ones, so you do not blunt your policy over your own relayed mail.
• Lean on DKIM alignment. DKIM survives forwarding far more often than SPF: the signature travels with the message, the IP does not. A well-aligned DKIM signature is your best defense against forwarding breakage, with or without ARC.
• Read the chain. Paste a raw message into our email header analyzer and it reads the Authentication-Results in plain English, including the receiver's arc= verdict when one is present.