draft-ietf-dmarc-arc-to-historic-00 - Reclassifying ARC as Historic
Skip to main content
Javascript disabled? Like other modern websites, the IETF Datatracker relies on Javascript.<br>Please enable Javascript for full functionality.
Reclassifying ARC as Historic
draft-ietf-dmarc-arc-to-historic-00
Status
IESG evaluation record
IESG writeups
Email expansions
History
Versions:
Document<br>Type
Active Internet-Draft<br>(dmarc WG)
Authors
J. Trent Adams
John R. Levine
Last updated
2026-04-22
Replaces
draft-adams-arc-experiment-conclusion
RFC stream
Internet Engineering Task Force (IETF)
Intended RFC status
(None)
Formats
txt
html
xml
htmlized
bibtex
bibxml
Additional resources
Mailing list discussion
Stream
WG
state
WG Document
Document shepherd
(None)
IESG
IESG state
I-D Exists
Consensus boilerplate
Unknown
Telechat date
(None)
Responsible AD
(None)
Send notices to
(None)
Email authors
Email WG
IPR
References
Referenced by
Nits
Search email archive
draft-ietf-dmarc-arc-to-historic-00
Network Working Group T. Adams<br>Internet-Draft Proofpoint<br>Obsoletes: 8617 (if approved) J. Levine<br>Intended status: Informational Taughannock Networks<br>Expires: 24 October 2026 22 April 2026
Reclassifying ARC as Historic<br>draft-ietf-dmarc-arc-to-historic-00
Abstract
This document calls for a conclusion to the experiment defined by<br>“The Authenticated Received Chain (ARC) Protocol” [RFC8617], and<br>recommends that ARC no longer be deployed or relied upon between<br>disparate senders and receivers. The document summarizes what ARC<br>set out to do, reports on operational experience, and explains how<br>the experience gained during the experiment is being incorporated<br>into the proposed DKIM2 work as the successor to DomainKeys<br>Identified Mail [RFC6376]. To avoid any future confusion, it is<br>therefore requested that ARC [RFC8617] be reclassified as “Historic”.
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<br>Task Force (IETF). Note that other groups may also distribute<br>working documents as Internet-Drafts. The list of current Internet-<br>Drafts is 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 24 October 2026.
Copyright Notice
Copyright (c) 2026 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 (https://trustee.ietf.org/<br>license-info) in effect on the date of publication of this document.<br>Please review these documents carefully, as they describe your rights
Adams & Levine Expires 24 October 2026 [Page 1]<br>Internet-Draft Reclassifying ARC as Historic April 2026
and restrictions with respect to this document. Code Components<br>extracted from this document must include Revised BSD License text as<br>described in Section 4.e of the Trust Legal Provisions and are<br>provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2<br>2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3<br>2.1. Problem Space: DMARC Breakage at Intermediaries . . . . . 3<br>2.2. ARC Overview . . . . . . . . . . . . . . . . . . . . . . 3<br>2.3. Scope and Non-Goals of ARC . . . . . . . . . . . . . . . 4<br>3. Analysis of the ARC Experiment . . . . . . . . . . . . . . . 4<br>3.1. Operational Experience . . . . . . . . . . . . . . . . . 4<br>3.2. ARC’s Core Lesson: Signatures Are Not Trust . . . . . . . 6<br>3.3. No Indication of Modifications . . . . . . . . . . . . . 6<br>3.4. Reputation at Each Hop Is Operationally Heavy . . . . . . 6<br>3.5. Favoring the DKIM2 Approach . . . . . . . . . . . . . . . 6<br>3.6. Conclusions of the ARC Experiment . . . . . . . . . . . . 7<br>4. Guidance to Implementers and Operators . . . . . . . . . . . 7<br>5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7<br>6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7<br>7. Security Considerations . . . . . . . . . . . . . . . . . . . 8<br>8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8<br>8.1. Normative References . . . . . . . . . . . . . . . . . . 8<br>8.2. Informative References . . . . . . . . . . . . . . . . . 8<br>Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
Following the deployment of DMARC [RFC7489] that aligned author<br>domains with SPF [RFC7208] / DKIM [RFC6376] and provided a method to<br>request receiver handling for authentication failures, while DKIM<br>continued to provide message-level signatures, it became clear that<br>there was a failure case that needed to...