Concluding the ARC Experiment
Internet-Draft<br>Concluding the ARC Experiment<br>December 2025
Adams & Levine<br>Expires 5 June 2026<br>[Page]
Workgroup:<br>Network Working Group<br>Internet-Draft:<br>draft-adams-arc-experiment-conclusion-00<br>Obsoletes:
8617 (if approved)<br>Published:
2 December 2025
Intended Status:<br>Informational<br>Expires:<br>5 June 2026<br>Authors:
T. Adams
Proofpoint
J. Levine
Taughannock Networks
Concluding the ARC Experiment
Abstract
This document calls for a conclusion to the experiment defined by “The Authenticated<br>Received Chain (ARC) Protocol,” (RFC8617) and recommends that ARC no<br>longer be deployed or relied upon between disparate senders and receivers. The<br>document summarizes what ARC set out to do, reports on operational experience, and<br>explains how the experience gained during the experiment is being incorporated into<br>the proposed DKIM2 work as the successor to DomainKeys Identified Mail (DKIM). To<br>avoid any future confusion, it is therefore requested that ARC (RFC8617) be marked<br>“Obsolete” by the publication of this Internet-Draft.¶
Status of This Memo
This Internet-Draft is submitted in full conformance with the<br>provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task<br>Force (IETF). Note that other groups may also distribute working<br>documents as Internet-Drafts. The list of current Internet-Drafts is<br>at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months<br>and may be updated, replaced, or obsoleted by other documents at any<br>time. It is inappropriate to use Internet-Drafts as reference<br>material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 5 June 2026.¶
Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the<br>document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal<br>Provisions Relating to IETF Documents<br>(https://trustee.ietf.org/license-info) in effect on the date of<br>publication of this document. Please review these documents<br>carefully, as they describe your rights and restrictions with<br>respect to this document. Code Components extracted from this<br>document must include Revised BSD License text as described in<br>Section 4.e of the Trust Legal Provisions and are provided without<br>warranty as described in the Revised BSD License.¶
Table of Contents
1. Introduction
Following the deployment of DMARC [RFC7489] that aligned author<br>domains with SPF [RFC7208] / DKIM [RFC6376] and provided a method to request receiver<br>handling for authentication failures, while DKIM continued to provide<br>message-level signatures, it became clear that there was a failure<br>case that needed to be addressed. Real-world forwarding and<br>modifications performed by mailing list managers frequently broke<br>the authentication protocols that underpin DMARC, motivating the ARC experiment as a potential<br>mitigation.¶
As a response, ARC [RFC8617] was introduced as an experiment to<br>determine whether a cryptographically verifiable “chain of custody”<br>for email, as assembled by intermediaries rewriting messages, could<br>preserve the original sender’s authentication results across<br>forwarding, mailing lists, and other intermediaries. ARC’s premise<br>was that each handler could record its view of upstream<br>authentication and then sign that record, enabling downstream<br>evaluators to see what happened along the path.¶
This document reports the experiment’s results and explains why, with<br>the emergence of the proposed successor to DKIM, currently known as<br>DKIM2, the community should retire ARC and incorporate the useful<br>pieces directly into the successor to DKIM.¶
2. Background
2.1. Problem Space: DMARC Breakage at Intermediaries
DMARC relies on successful SPF and/or DKIM authentication along with alignment with the Author Domain.<br>When intermediaries modify a message (for example, subject or body<br>changes, footer insertion, MIME adjustments), DKIM signatures from<br>the originator can fail to verify; when an intermediary relays mail<br>through different IPs than are defined within the originator’s SPF<br>record, SPF authentication can fail. As a result, messages that were<br>legitimate at origination can appear unauthenticated downstream, even<br>if the intermediary handling is benign. ARC was proposed to let<br>trustworthy intermediaries attest to what they saw before the<br>breakage occurred and add a new signature to the message, essentially<br>creating a signature chain.¶
Forwarding remains one of the most pervasive sources of broken<br>authentication results. When a recipient’s mail is automatically<br>forwarded (for example, via a mailing list, auto-forward rule, or<br>redirect), the forwarding infrastructure appears as the sending IP,<br>not the IP of the original sending domain, so SPF authentication fails by<br>design. DKIM may survive only if the signature remains intact<br>through forwarding, but many forwarding systems change headers or<br>bodies (footers,...