ARC (Authenticated Received Chain)
ARC is a way for a mail server that modifies a message in transit to record what authentication result it saw before the change. A mailing list that rewrites a subject line breaks the original DKIM signature; ARC lets the list state, under its own signature, that the message did pass when it arrived. A receiving server can then choose to trust that record.
At a glance
- Category
- Authentication
- Specified in
- RFC 8617, Experimental
- Adds headers
- ARC-Seal, ARC-Message-Signature, ARC-Authentication-Results
- Added by
- Intermediaries: mailing lists, forwarders, gateways
- Trust model
- Advisory — a receiver decides whether to honour the chain
How it works
An intermediary that is about to alter a message first records the authentication result it observed, then adds three headers: one holding that result, one signing the message as it stands, and a seal that binds this hop to every hop before it. Each further intermediary adds its own set, so the headers form a chain with an instance number per link. A receiving server can validate the chain, see which intermediaries vouched for the message, and decide for itself which of them it is willing to believe.
Why it matters
Forwarding is where email authentication breaks in practice. A mailing list that appends a footer invalidates the DKIM signature, and the forwarding server is not on the sender's SPF record, so a message that was perfectly authentic when it was sent fails both checks on arrival and a strict DMARC policy tells the receiver to reject it. ARC gives the receiver a second story to weigh, which is what lets a domain publish a strict policy without losing every message that passes through a list.
Example
A newsletter from example.com is signed and passes DMARC. A subscriber's address forwards to another mailbox provider, and the forwarding host rewrites the subject to add a tag. The DKIM signature no longer verifies. Because the forwarder added an ARC set recording the original pass and sealed it, the receiving server can see that the message authenticated correctly one hop earlier and deliver it rather than reject it, provided the forwarder is one it already trusts.
Common mistakes
- 01Treating a valid ARC chain as proof of authenticity: it only proves an intermediary claimed a result, and a chain from a host you do not trust is worth nothing.
- 02Expecting ARC to repair a message that never authenticated in the first place — it records history, it does not create it.
- 03Publishing a strict DMARC policy and assuming ARC will cover forwarding everywhere, when honouring the chain is entirely the receiver's choice.
Related terms
Frequently asked questions
Do I need to do anything to use ARC?
As an ordinary sender, no. ARC headers are added by intermediaries that modify your mail, not by you, so your job is still to sign with DKIM and publish SPF and DMARC correctly.
Does ARC replace DMARC?
No. DMARC is still what tells a receiver what to do with mail that fails authentication. ARC is extra evidence a receiver may consult before applying that policy, and it is optional at every step.
Why is RFC 8617 marked Experimental?
The specification was published on the experimental track so that deployment could inform it, and it has stayed there while large receivers gathered data. Several major mailbox providers validate ARC chains in production regardless of the track.
Sources
Last updated 16 September 2026.
Start sending this morning
Verify a domain and send your first email in minutes.