An email authentication protocol that preserves the original sender’s authentication results as a message passes through intermediary servers. These intermediaries , such as mailing lists or forwarding services , often break traditional SPF and DKIM checks. ARC solves this by having each intermediary add a signed set of headers, creating a verifiable chain of custody.
How ARC Works
ARC operates by appending a series of signed headers to an email as it traverses intermediary servers. These headers include ARC-Seal, ARC-Message-Signature, and ARC-Authentication-Results. Each set is numbered sequentially (i=1, i=2, etc.), and the cv= field indicates whether the prior chain validated successfully. This allows receiving servers to trust forwarded messages that would otherwise fail authentication.
- ARC-Seal: Authenticates the ARC headers themselves, ensuring they have not been altered.
- ARC-Message-Signature: Signs the entire email, including the ARC-Seal and any previous ARC headers.
- ARC-Authentication-Results: Records the authentication results at each intermediary step.
History and Status
ARC was defined in RFC 8617, published in July 2019, as an "Experimental" protocol. However, the IETF has suggested that ARC should no longer be used. Some parts of ARC might be incorporated into DKIMv2, but as of now, ARC is considered deprecated. The protocol did not solve the problems with email reputation, leading to its eventual discontinuation.
Alternatives and Future Directions
Given the deprecation of ARC, organizations relying on email authentication should explore alternative solutions. DKIMv2 is one potential successor, aiming to address the limitations of the original DKIM protocol. Additionally, other email authentication methods like SPF and DMARC continue to evolve, offering robust alternatives for securing email communications.