IETF calls for end of ARC experiment: What it means for email authentication

TL;DR:

The IETF has published a draft recommending that ARC (Authenticated Received Chain) be marked "Obsolete" after a 10-year experiment. ARC was designed to preserve email authentication when intermediaries like mailing lists and forwarders modified messages, but failed to deliver a scalable solution due to the lack of an internet-wide reputation system. The experiment's learnings will be incorporated into DKIM2, the next-generation successor to DKIM.

For organizations, this means continuing to focus on SPF, DKIM, and DMARC as the foundation of email security, which remain mandatory requirements from major inbox providers.

Red Sift OnDMARC helps organizations achieve full DMARC enforcement in 6-8 weeks, protecting against spoofing and phishing whilst maintaining email deliverability across all intermediaries and forwarding scenarios.

The Internet Engineering Task Force (IETF) has published a draft calling for the conclusion of the ARC (Authenticated Received Chain) experiment and recommending that RFC8617 be marked "Obsolete." This marks the end of a decade-long effort to solve one of email authentication's most persistent challenges: what happens when legitimate intermediaries modify messages and break DMARC.

After DMARC's deployment, which aligned SPF and DKIM with author domains and provided policy enforcement, a critical gap emerged: forwarding and mailing list modifications frequently broke authentication, causing legitimate emails to fail DMARC checks.

ARC was introduced as an experimental protocol to address this problem by creating a cryptographic "chain of custody" for emails. The concept was simple: each intermediary that handled a message (mailing lists, forwarders, gateways) could:

1. Record the authentication results they observed
2. Sign those observations cryptographically
3. Create a verifiable chain showing what happened along the message's path

The goal was to let downstream receivers see that whilst current authentication might be broken, the message was legitimate when originally sent.

ARC defined three header fields that intermediaries could add to messages:

• ARC-Authentication-Results: What authentication results the intermediary observed
• ARC-Message-Signature: A signature of the message and previous ARC headers
• ARC-Seal: A signature binding the entire chain together

Each handler would add its own set of these headers, building a chain that downstream evaluators could verify. If the chain was valid, receivers could potentially trust that the message was legitimate despite current authentication failures.

After 10 years of operational experience, the IETF draft identifies several critical reasons why ARC didn't achieve its goals:

ARC could verify that intermediaries participated in the chain, but it couldn't convey trust. Without a way to determine which of thousands of potential intermediaries are trustworthy, receivers couldn't safely override DMARC failures based on ARC alone. Ad hoc allow-lists proved insufficient and expensive to maintain.

ARC showed that a message was modified but not what was changed or why. This left interpretation entirely up to evaluators and their ability to assess intermediary reputation—a burden that proved operationally impractical at internet scale.

The separation of "verification" from "trust" created risks. Attackers could route messages through permissive or compromised intermediaries to gain favorable treatment, effectively gaming the system.

The number of potential forwarders and intermediaries is vast and constantly changing. Maintaining reputation records for all of them proved unrealistic, and after 10 years, no internet-scale reputation system emerged—nor is one planned.

The forwarding problem that motivated ARC remains real. When messages are forwarded through mailing lists or auto-forward rules:

• SPF fails because the forwarding infrastructure appears as the sending IP
• DKIM often fails when forwarders modify headers or bodies
• DMARC fails as a result, potentially blocking legitimate emails

However, the IETF draft makes clear that ARC's approach—relying on intermediary reputation without a scalable trust framework—isn't the solution.

Instead, the useful elements of ARC (signed assertions about handling) will be incorporated into DKIM2, the proposed successor to DKIM. DKIM2 aims to address replay attacks, modern routing patterns, and intermediary handling more comprehensively, without requiring parallel signature chains or hop-by-hop reputation systems.

• Continue focusing on SPF, DKIM, and DMARC: The fundamentals haven't changed. SPF, DKIM, and DMARC remain the foundation of email authentication and are required by major inbox providers including Google, Yahoo, and Microsoft for bulk senders.
• Don't deploy new ARC implementations: The IETF draft recommends that ARC no longer be deployed or relied upon between disparate senders and receivers. Any residual ARC processing should be treated as diagnostic only. Note: Unless your organization is building mail infrastructure, this is unlikely to to be relevant.
• Prepare for DKIM2: As DKIM2 develops and incorporates learnings from the ARC experiment, organizations should stay informed about the evolution of email authentication standards.
• Maintain strong DMARC enforcement: Regardless of the forwarding problem, DMARC at enforcement (p=reject or p=quarantine) remains the most effective protection against exact-domain spoofing and phishing attacks.

Red Sift OnDMARC focuses on what organizations need today: rapid, reliable deployment of SPF, DKIM, and DMARC to protect against spoofing and maintain deliverability.

• Rapid deployment: Most organizations reach full DMARC enforcement in 6-8 weeks with automated guidance and real-time testing via Red Sift Investigate
• Dynamic SPF: Bypass the 10-lookup limit without macros, ensuring deliverability even across complex sending infrastructures
• Automated management: Control SPF, DKIM, DMARC, BIMI, and MTA-STS records from a single dashboard with one DNS change
• DNS Guardian: Continuous monitoring for DNS misconfigurations and subdomain attacks that bypass DMARC
• AI-powered troubleshooting: Red Sift Radar resolves authentication issues 10x faster with LLM-driven insights
• Clear visibility: Real-time dashboards transform complex DMARC reports into actionable intelligence

Why organizations choose Red Sift

Red Sift OnDMARC is the #1-rated DMARC solution in EMEA with a 4.9/5 G2 rating, trusted by 1,200+ organizations including Save the Children, ZoomInfo, Wise and Holland & Barrett.

Our award-winning customer success team guides you through every step, from implementation to full enforcement, ensuring you achieve protection quickly without disrupting legitimate email delivery.

The conclusion of the ARC experiment reinforces what security teams already know: effective email authentication starts with properly implemented SPF, DKIM, and DMARC.

Red Sift OnDMARC makes this achievable for organizations of all sizes, with enterprise-grade automation, expert guidance, and best-in-class technology.