Reclassifying ARC as Historic
draft-ietf-dmarc-arc-to-historic-00

Network Working Group                                           T. Adams
Internet-Draft                                                Proofpoint
Obsoletes: 8617 (if approved)                                  J. Levine
Intended status: Informational                      Taughannock Networks
Expires: 24 October 2026                                   22 April 2026

                     Reclassifying ARC as Historic
                  draft-ietf-dmarc-arc-to-historic-00

Abstract

   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 [RFC6376].  To avoid any future confusion, it is
   therefore requested that ARC [RFC8617] be reclassified as “Historic”.

Status of This Memo

   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 24 October 2026.

Copyright Notice

   Copyright (c) 2026 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

Adams & Levine           Expires 24 October 2026                [Page 1]
Internet-Draft        Reclassifying ARC as Historic           April 2026

   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Background  . . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Problem Space: DMARC Breakage at Intermediaries . . . . .   3
     2.2.  ARC Overview  . . . . . . . . . . . . . . . . . . . . . .   3
     2.3.  Scope and Non-Goals of ARC  . . . . . . . . . . . . . . .   4
   3.  Analysis of the ARC Experiment  . . . . . . . . . . . . . . .   4
     3.1.  Operational Experience  . . . . . . . . . . . . . . . . .   4
     3.2.  ARC’s Core Lesson: Signatures Are Not Trust . . . . . . .   6
     3.3.  No Indication of Modifications  . . . . . . . . . . . . .   6
     3.4.  Reputation at Each Hop Is Operationally Heavy . . . . . .   6
     3.5.  Favoring the DKIM2 Approach . . . . . . . . . . . . . . .   6
     3.6.  Conclusions of the ARC Experiment . . . . . . . . . . . .   7
   4.  Guidance to Implementers and Operators  . . . . . . . . . . .   7
   5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   7
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   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.

Adams & Levine           Expires 24 October 2026                [Page 2]
Internet-Draft        Reclassifying ARC as Historic           April 2026

   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.

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.  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.

2.2.  ARC Overview

   To address these failure modes, ARC defines header fields ( ARC-Seal,
   ARC-Message-Signature, ARC-Authentication-Results) that allow each
   intermediary to:

Adams & Levine           Expires 24 October 2026                [Page 3]
Internet-Draft        Reclassifying ARC as Historic           April 2026

   *  capture its input authentication assessment (typically DMARC-
      related),

   *  indicate that some transformation happened but not what changed,
      and

   *  sign its contribution, forming a verifiable chain that subsequent
      receivers can validate.

   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.

2.3.  Scope and Non-Goals of ARC

   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.

3.  Analysis of the ARC Experiment

3.1.  Operational Experience

   This section summarizes widely reported deployment observations from
   operators and implementers during the ARC experiment.

   *  Data-center and intra-domain utility: Early effective use of ARC
      occurred inside single administrative domains or tightly
      controlled data centers, where messages traversed multiple
      internal hops.  Operators applied ARC to ensure messages were not
      modified unexpectedly between their own servers.  In these cases,
      operators already had implicit trust and operational control.

Adams & Levine           Expires 24 October 2026                [Page 4]
Internet-Draft        Reclassifying ARC as Historic           April 2026

   *  Internet-scale dependency on reputation: For broad
      interoperability, ARC required evaluators to run a reputation
      system for ARC signers.  Verifying the cryptography was necessary
      but insufficient; evaluators needed to decide whether to trust
      each signer in the chain before using their assertions to override
      DMARC outcomes.  This created a parallel trust infrastructure,
      separate from (but interacting with) existing domain or IP
      reputation.

   *  Limited reputation deployment:Even early deployers that validated
      ARC chains did not deploy robust, dynamic reputation.  Instead,
      they implemented “allow lists” of intermediaries whose ARC
      assertions were always (or mostly) accepted.  This provided
      utility in specific bilateral or consortium relationships but did
      not scale to the open Internet.

   *  Complex evaluator policy: Receivers faced policy questions: how
      many hops of ARC to honor, how to treat partial or broken chains,
      how to reconcile conflicting assessments across chain links, and
      under what conditions ARC could influence DMARC enforcement.  The
      resulting diversity limited predictable interoperation across
      receivers.

   *  Forwarding-driven breakage still dominant: Because email
      forwarding automatically changes the apparent sender
      infrastructure (for example, the forwarding system’s IP rather
      than the original domain), many well-authenticated messages fail
      DMARC at the final recipient purely due to forwarders.  Forwarding
      often results in SPF failure by design and DKIM failure due to
      header or body modifications.  This reinforces that any
      intermediary authentication or chaining mechanism (such as ARC)
      must address the uncontrolled nature of forwarding, which spans
      countless unknown and dynamic systems, rather than only known
      mailing lists or enterprise relays.

   *  Ecosystem shift to successor work: As the community prioritized
      addressing DKIM replay and strengthening end-to-end authenticity,
      the DKIM working group has initiated work on what is being called
      DKIM2.  That effort explicitly considers incorporating ARC-like
      “handling assertions” where they add value, while avoiding a
      separate global trust fabric for intermediaries.  As focus has
      shifted from ARC to DKIM2, incorporating the learning from the ARC
      experiment, there is no longer any meaningful effort to continue
      developing and deploying ARC.

Adams & Levine           Expires 24 October 2026                [Page 5]
Internet-Draft        Reclassifying ARC as Historic           April 2026

3.2.  ARC’s Core Lesson: Signatures Are Not Trust

   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.

3.3.  No Indication of Modifications

   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.

3.4.  Reputation at Each Hop Is Operationally Heavy

   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.

3.5.  Favoring the DKIM2 Approach

   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.

Adams & Levine           Expires 24 October 2026                [Page 6]
Internet-Draft        Reclassifying ARC as Historic           April 2026

3.6.  Conclusions of the ARC Experiment

   Based on community experience and the direction of the DKIM2 work:

   a.  The ARC experiment is over.  Implementers and operators should
       not rely on ARC going forward, and should cease further Internet-
       wide deployments.  Existing ARC deployers should plan to
       decommission them or confine their usage to controlled, intra-
       domain contexts where bilateral policy suffices.

   b.  Experience from the ARC experiment is informing the development
       of DKIM2.  The DKIM working group is actively developing DKIM2;
       relevant ARC insights, such as durable capture of upstream
       authentication state and intermediary handling, shall inform
       DKIM2 design where appropriate.

   c.  RFC 8617 should be marked "Historic" This document requests that
       the RFC Editor and IESG mark RFC 8617 as Historic” upon
       acceptence of this draft by the DMARC Working Group to conclude
       the experiment and discourage new deployments of it.

4.  Guidance to Implementers and Operators

   *  Receivers that still parse ARC headers may continue to verify them
      for forensic or intra-domain purposes, but should not make
      delivery decisions based on ARC chain validity without robust
      reputational trust signals and associated policies.

   *  New ARC deployments are discouraged since they are unlikely to
      provide useful information for mail processing.

   *  Anyone interested in ARC should follow the development of DKIM2 as
      it matures through the IETF process.

5.  Acknowledgements

   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.

6.  IANA Considerations

   This document has no IANA actions.

Adams & Levine           Expires 24 October 2026                [Page 7]
Internet-Draft        Reclassifying ARC as Historic           April 2026

7.  Security Considerations

   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.

8.  References

8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC6376]  Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
              "DomainKeys Identified Mail (DKIM) Signatures", STD 76,
              RFC 6376, DOI 10.17487/RFC6376, September 2011,
              <https://www.rfc-editor.org/info/rfc6376>.

   [RFC7208]  Kitterman, S., "Sender Policy Framework (SPF) for
              Authorizing Use of Domains in Email, Version 1", RFC 7208,
              DOI 10.17487/RFC7208, April 2014,
              <https://www.rfc-editor.org/info/rfc7208>.

   [RFC7489]  Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based
              Message Authentication, Reporting, and Conformance
              (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015,
              <https://www.rfc-editor.org/info/rfc7489>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8617]  Andersen, K., Long, B., Ed., Blank, S., Ed., and M.
              Kucherawy, Ed., "The Authenticated Received Chain (ARC)
              Protocol", RFC 8617, DOI 10.17487/RFC8617, July 2019,
              <https://www.rfc-editor.org/info/rfc8617>.

8.2.  Informative References

   [ARC-SPEC] "ARC Specification site, background and history", 2019,
              <https://arc-spec.org/>.

Adams & Levine           Expires 24 October 2026                [Page 8]
Internet-Draft        Reclassifying ARC as Historic           April 2026

   [I-D.ietf-dkim-dkim2-motivation]
              Gondwana, B., Clayton, R., and W. Chuang, "DKIM2 - signing
              the source and destination of every email", Work in
              Progress, Internet-Draft, draft-ietf-dkim-dkim2-
              motivation-02, 2 November 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-dkim-
              dkim2-motivation-02>.

Authors' Addresses

   J. Trent Adams
   Proofpoint
   105 Edgeview Drive, Suite 440
   Broomfield, CO 80021
   United States of America
   Email: tadams@proofpoint.com

   John Levine
   Taughannock Networks
   PO Box 727
   Trumansburg, NY 14886
   United States of America
   Email: standards@taugh.com

Adams & Levine           Expires 24 October 2026                [Page 9]