| Internet-Draft | Concluding the ARC Experiment | December 2025 |
| Adams & Levine | Expires 5 June 2026 | [Page] |
This document calls for a conclusion to the experiment defined by “The Authenticated Received Chain (ARC) Protocol,” (RFC8617) and recommends that ARC no longer be deployed or relied upon between disparate senders and receivers. The document summarizes what ARC set out to do, reports on operational experience, and explains how the experience gained during the experiment is being incorporated into the proposed DKIM2 work as the successor to DomainKeys Identified Mail (DKIM). To avoid any future confusion, it is therefore requested that ARC (RFC8617) be marked “Obsolete” by the publication of this Internet-Draft.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 5 June 2026.¶
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Following the deployment of DMARC [RFC7489] that aligned author domains with SPF [RFC7208] / DKIM [RFC6376] and provided a method to request receiver handling for authentication failures, while DKIM continued to provide message-level signatures, it became clear that there was a failure case that needed to be addressed. Real-world forwarding and modifications performed by mailing list managers frequently broke the authentication protocols that underpin DMARC, motivating the ARC experiment as a potential mitigation.¶
As a response, ARC [RFC8617] was introduced as an experiment to determine whether a cryptographically verifiable “chain of custody” for email, as assembled by intermediaries rewriting messages, could preserve the original sender’s authentication results across forwarding, mailing lists, and other intermediaries. ARC’s premise was that each handler could record its view of upstream authentication and then sign that record, enabling downstream evaluators to see what happened along the path.¶
This document reports the experiment’s results and explains why, with the emergence of the proposed successor to DKIM, currently known as DKIM2, the community should retire ARC and incorporate the useful pieces directly into the successor to DKIM.¶
DMARC relies on successful SPF and/or DKIM authentication along with alignment with the Author Domain. When intermediaries modify a message (for example, subject or body changes, footer insertion, MIME adjustments), DKIM signatures from the originator can fail to verify; when an intermediary relays mail through different IPs than are defined within the originator’s SPF record, SPF authentication can fail. As a result, messages that were legitimate at origination can appear unauthenticated downstream, even if the intermediary handling is benign. ARC was proposed to let trustworthy intermediaries attest to what they saw before the breakage occurred and add a new signature to the message, essentially creating a signature chain.¶
Forwarding remains one of the most pervasive sources of broken authentication results. When a recipient’s mail is automatically forwarded (for example, via a mailing list, auto-forward rule, or redirect), the forwarding infrastructure appears as the sending IP, not the IP of the original sending domain, so SPF authentication fails by design. DKIM may survive only if the signature remains intact through forwarding, but many forwarding systems change headers or bodies (footers, mailing list tags, encodings), thus invalidating DKIM and causing DMARC to fail.¶
Because the forwarding party is typically not in the author’s domain control and cannot easily be enumerated in the author’s SPF record, it becomes operationally infeasible for senders to cover every possible forwarder. As such, broken authentication at forwarders represents a structural gap in DMARC deployment.¶
The forwarder’s participation and transformations therefore form the very scenario that the ARC experiment targeted, namely intermediaries rewriting messages and breaking original authentication signals, and the hope that those intermediaries could attest to the original author’s state via a chain of custody.¶
To address these failure modes, ARC defines header fields ( ARC-Seal, ARC-Message-Signature, ARC-Authentication-Results) that allow each intermediary to:¶
ARC does not assert message authorship; it asserts a sequence of handling and observations only by those participating in ARC signing. Verification yields two outputs: (1) whether the chain is cryptographically valid, and (2) what those upstream assessments (if any) were. It makes no value assertion of the email nor if there were any intermediary handlers not participating in ARC handling or signing.¶
The experiment explicitly limited ARC’s role to signaling: it could reveal that certain intermediaries participated and re-signed messages, but a validated ARC chain was not intended to convey trust in any signer on its own. Trust decisions were left to receivers’ local policy. As such, without a robust reputation system, ARC in- and-of itself cannot convey trust in an email that fails DMARC.¶
Another limitation of the design was that the ARC signature only indicated the intermediaries handling the message, but was silent about any changes the intermediaries made to the message. As such, a fully validated ARC chain might include a modified message without the final evaluator knowing what changes were made.¶
This section summarizes widely reported deployment observations from operators and implementers during the ARC experiment.¶
ARC successfully demonstrated that intermediaries can publish a cryptographically verifiable history of handling. However, verifiable history without reputation does not enable safe override of DMARC or other enforcement policies. Any Internet-wide solution must pair verifiable signals with a scalable, abuse-resistant trust model; ad hoc allow lists are not sufficient.¶
When the content of an email was modified by an intermediary, breaking the DKIM signature, ARC was able to identify the intermediary that performed the modification via a signature, through ARC doesn't define a mechanism to identify what was modified in the message or why it was modified. This left the interpretation of whether or not the email should be accepted up to the evaluator's ability to determine the reputation of the intermediary.¶
Operating, sharing, and refreshing reputation for potentially thousands of intermediaries is expensive and complex. Without a common reputation framework, ARC yielded inconsistent receiver behavior and created incentive for attackers to infiltrate or mimic “trusted” intermediaries.¶
The forwarding problem illustrates this operational burden: the number of potential forwarders is vast and dynamic, making it unrealistic to maintain allow-lists or reputation records for all of them.¶
Attempts to create internet-scale reputation systems for ARC have not been successful during the ten years of the experiment, and it as there is no known plan for one in development, it is unlikely there will be one in the future.¶
The DKIM2 motivation identifies replay as a critical gap and proposes signing the source and destination for each message, along with mechanisms better aligned with modern routing patterns. Incorporating ARC’s useful elements (for example, signed assertions about handling) into DKIM2 avoids a parallel chain or signature stack and reduces reliance on separate hop-by-hop reputation.¶
Based on community experience and the direction of the DKIM2 work:¶
The authors of RFC8617 and the many operators who deployed and evaluated ARC provided the data and experience that made these conclusions possible. The DKIM working group’s current efforts, including the DKIM2 motivation and related drafts, informed the direction recommended here. Thanks also to those who helped review and edit this draft including (but not limited to) Todd Herr, Richard Clayton, Alex Brotman, Marc Bradshaw, and Emanuel Schorsch.¶
This document has no IANA actions.¶
ARC’s separation of “verification” from “trust” created risks when evaluators accepted chains from low-reputation or compromised intermediaries. Attackers could attempt to route through permissive handlers to gain favorable treatment. Ending the experiment and migrating learnings into DKIM2, along with explicit controls to mitigate replay and stronger binding of message context, should reduce these risks. Operators must treat residual ARC processing as diagnostic only, unless backed by robust, auditable trust frameworks.¶