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 thrown away. 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. The final receiver validates the chain and records a chain-validation result: cv=pass, cv=fail, or cv=none.

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 (Gmail, Microsoft, Yahoo) has to evaluate the chain and decide whether to honor it.

The major mailbox providers participate: Google, Microsoft, and Yahoo both seal and evaluate 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 deliver the message even though SPF and DKIM now fail. But:

• It is a local policy decision. ARC never forces delivery. 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. 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 a spoofer. The fix is rarely to weaken your policy.
• Tell forwarding from spoofing. In trustyourinbox, the forwarding breakdown splits your failing mail by authentication path: a DKIM-only pass is the signature of a forward that survived, and the source view labels a known forwarder versus an unknown sender, 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 parses the Authentication-Results and any ARC sets in plain English, so you can see exactly what each hop recorded.