Security term · last reviewed 2026-08-31
ARC
Also known as: Authenticated Received Chain, RFC 8617
ARC (Authenticated Received Chain, RFC 8617) lets an intermediary record and sign the authentication results it saw before modifying a message, so a downstream receiver can honor the original SPF and DKIM result even though both now fail.
How it works
ARC (Authenticated Received Chain, RFC 8617) lets an intermediary that legitimately modifies a message record the authentication results it observed before modifying it, and sign that record. Each participating hop adds a set of ARC headers: the authentication results it saw, a seal over the chain so far, and a signature. A downstream receiver that trusts the intermediary can honor the original SPF and DKIM results even though both now fail against the modified message.
When it matters
It matters for mailing lists, forwarding services, and any intermediary that rewrites subject lines or appends footers, all of which break DKIM and all of which would otherwise be casualties of DMARC enforcement. You do not configure ARC as an ordinary sender; you benefit when your mail traverses infrastructure that implements it, and you implement it if you are the intermediary. See The Email Authentication Stack.
Common misconceptions
- "ARC is verified like DKIM." ARC is trust-based. The receiver decides which intermediaries to believe, and no certificate authority makes that judgment. Google and Microsoft evaluate it; many smaller receivers do not.
- "ARC fixes forwarding for everyone." Only where both the intermediary implements it and the receiver honors it.
- "Publishing ARC headers improves my deliverability." Adding ARC headers as an origin sender does nothing. It is an intermediary protocol.