ARC (Authenticated Received Chain) is an email authentication protocol that lets each intermediary handling a message record the authentication results it observed and seal them with a cryptographic signature, so that the final receiver can see that SPF, DKIM and DMARC passed earlier in the path even if forwarding later broke them. In email infrastructure, ARC addresses the long-standing conflict between strict DMARC policies and legitimate forwarding, especially by mailing lists.
ARC is specified in RFC 8617, published in 2019 with experimental status. It does not override DMARC by itself; it supplies evidence that a receiver may choose to trust when it decides whether to accept a message that would otherwise fail.
Why forwarding breaks email authentication
SPF checks whether the sending server’s IP address is authorized by the envelope sender domain. When a message is forwarded, it leaves from the forwarder’s IP address, which the original domain never listed, so SPF fails. DKIM survives simple forwarding, but mailing lists often modify the subject line or append a footer, which invalidates the body or header hash.
When both checks fail, DMARC alignment fails as well. A domain that publishes p=reject then instructs receivers to discard the message, even though it was genuine and passed every check at the first hop. ARC was designed to carry the evidence from that first hop forward to the final mailbox provider.
How the ARC chain is built
Each participating intermediary adds an ARC set, a group of three header fields sharing the same instance number, written as i=1, i=2 and so on. The first handler that adds ARC uses i=1, and every later hop increments it. The specification limits a chain to 50 sets, although real chains rarely exceed three or four.
| Header field | Content | Purpose |
|---|---|---|
| ARC-Authentication-Results | SPF, DKIM and DMARC verdicts seen at this hop | Records the evidence |
| ARC-Message-Signature | DKIM-like signature over the message | Captures the message state at this hop |
| ARC-Seal | Signature over all previous ARC sets | Protects the chain from tampering |
The ARC-Seal carries a chain validation tag, cv=, with the value none for the first set, pass when all earlier sets verified, or fail when they did not. A receiver validates every seal and the most recent message signature; a single failure marks the whole chain as broken, and later handlers must not repair it.
Signing uses the same machinery as DKIM: a selector and domain in the header point to a public key published in a DNS TXT record. RSA keys of at least 1,024 bits, preferably 2,048, are the norm, and Ed25519 can also be used.
ARC compared with SPF, DKIM and DMARC
ARC is not a replacement for the other email authentication standards. It sits on top of them and adds a record of their results across hops.
| Standard | What it proves | Survives forwarding |
|---|---|---|
| SPF | The sending IP is authorized for the envelope domain | No |
| DKIM | Signed headers and body are unchanged since signing | Only if unmodified |
| DMARC | SPF or DKIM passed and aligns with the visible From domain | Depends on SPF and DKIM |
| ARC | Which results each intermediary saw, and the chain is intact | Yes, by design |
The decisive difference is who is vouching. SPF, DKIM and DMARC are statements by the sender domain. ARC is a statement by the intermediary, and its value therefore depends entirely on whether the receiver trusts that intermediary.
How receivers use ARC results
A receiving system that sees a DMARC failure with a valid ARC chain can look up which domains sealed the chain. If the sealer is on its list of trusted ARC signers, and the earliest ARC-Authentication-Results show a DMARC pass, the receiver may apply a local policy override and deliver the message. The override is reported in DMARC aggregate reports as local_policy with an ARC comment.
| Situation | Typical action | Reason |
|---|---|---|
| DMARC pass, any ARC state | Deliver normally | ARC is not needed |
| DMARC fail, valid chain from trusted sealer | Override and deliver | Earlier pass is credible |
| DMARC fail, valid chain from unknown sealer | Apply DMARC policy | Anyone can create a valid chain |
| DMARC fail, broken chain | Apply DMARC policy | Evidence cannot be trusted |
Large mailbox providers maintain their own trust lists, built from observed reputation of forwarders such as mailing list services, security gateways and university forwarding systems. Small receivers often use ARC only as a spam scoring signal rather than a hard override.
Deployment guidance and limitations
ARC matters most for operators who modify or redirect mail: mailing list software, inbound security gateways that rewrite links, and forwarding services. They should verify incoming authentication first, then seal, and should seal after their own modifications, not before.
- A valid chain proves integrity, not honesty; a spammer can seal its own messages perfectly.
- Sealing without checking adds meaningless results and harms the sealer’s reputation.
- Gateways that rewrite content after sealing break their own signature.
- Experimental status means support varies, and senders cannot rely on ARC to rescue mail.
- Key rotation follows the same practice as DKIM, with a new selector published before switching.
For senders, ARC requires no configuration at all. Their responsibility remains a correct SPF record, DKIM signing on every message and an aligned DMARC policy; ARC simply gives forwarded copies of that mail a better chance of reaching the inbox.
The short version
When a letter passes through several post offices, each one may open it, add a note or change the envelope. Afterwards, the final recipient can no longer check the original seal. ARC is a signed note from each post office saying what the letter looked like when it arrived there.
If the recipient trusts the post office that wrote the note, it can accept the letter even though the original seal is now broken.
Where it makes a difference
A professional association runs a discussion mailing list with 4,000 members. A member whose company domain publishes DMARC with p=reject posts a message. The list software adds a footer and a subject prefix, which breaks the DKIM signature, and it resends the message from its own servers, so SPF fails too.
Before ARC, large mailbox providers rejected the post for many members. After the list operator enables ARC, the software checks the incoming message, records a DMARC pass in ARC-Authentication-Results and seals the chain with its own domain. Receivers that recognize the list as a trusted ARC signer now deliver the post, and the list’s bounce rate for that member’s messages drops from hundreds per post to only a handful.