ARC is being retired: what the IETF draft means for DMARC teams
News
Michael Ko
Co-founder & CEO, Suped
Published 24 Apr 2026
Updated 22 May 2026
10 min read
Summarize with
The short answer: ARC is not disappearing overnight, but the IETF draft published on April 22, 2026 asks to end the ARC experiment, reclassify RFC 8617 as Historic if approved, and stop relying on ARC between unrelated senders and receivers. For DMARC teams, the practical answer is direct: keep DMARC, SPF, and DKIM as the control plane, remove ARC as a dependency for enforcement, and treat ARC headers as diagnostic evidence unless there is a strict trust policy around the signer.
I read the draft as a warning against using a valid ARC chain as a delivery override. ARC can show what an intermediary claimed to see before forwarding changed the message. It does not prove that the final message is safe, that the intermediary should be trusted, or that a DMARC failure should be ignored.
- Immediate impact: Do not start new Internet-wide ARC deployments as a DMARC workaround.
- Policy impact: Do not use ARC pass alone to bypass quarantine or reject decisions.
- Monitoring impact: Separate forwarded-mail noise from real authentication failures in DMARC reports.
- Migration impact: Plan around stronger DKIM and DMARC operations, not an ARC rescue path.
What changed in the IETF draft
The draft says the ARC experiment has run its course. ARC was published as Experimental, not as a permanent replacement for DMARC, SPF, or DKIM. The new draft asks the standards process to mark RFC 8617 as Historic, which signals that the protocol should not be the basis for new deployments across the open Internet.
The key detail is the phrase "between disparate senders and receivers." ARC can still have narrow value inside one administrative domain, or inside a tightly controlled partner relationship where every signer has a known policy and audit trail. That is different from accepting ARC assertions from arbitrary forwarders and using those assertions to override DMARC.
Draft status
On May 22, 2026, the document was an active Internet-Draft. It has not made every ARC header invalid, and it has not forced receivers to delete ARC parsing. It tells implementers and operators that ARC should not be treated as the future path for open Internet DMARC breakage.
- RFC status: RFC 8617 is targeted for Historic status if the draft is approved.
- Deployment signal: New broad ARC deployments are discouraged.
- Receiver signal: ARC verification should not be a trust decision by itself.
- Future signal: The useful ideas move into DKIM2 discussions instead of a separate ARC trust system.
That distinction matters because some teams treated ARC as a missing piece that would let them move to p=reject without cleaning up forwarding and indirect mail paths. The draft points in the opposite direction: ARC is not the escape hatch. DMARC teams need better source inventory, clearer routing policy, and better failure triage.
Why ARC struggled with DMARC enforcement
ARC tried to solve a real problem. A message can pass DKIM and DMARC when it leaves the sender, then fail after forwarding because the forwarder changed the body, added a footer, rewrote headers, or sent the message from infrastructure outside the original SPF record. ARC gave intermediaries a way to stamp what they saw before those changes.
The protocol did that through three main headers. If you want a primer on the moving parts in forwarded mail, the related explanation of ARC and DMARC failures is the useful companion topic.
Simplified ARC header settext
ARC-Seal: i=1; a=rsa-sha256; d=forwarder.example; s=arc; cv=none; b=... ARC-Message-Signature: i=1; a=rsa-sha256; d=forwarder.example; s=arc; bh=... ARC-Authentication-Results: i=1; mx.forwarder.example; dkim=pass header.d=sender.example; spf=pass smtp.mailfrom=sender.example; dmarc=pass header.from=sender.example
The weakness was not the cryptography. A receiver can verify whether the chain is intact. The weakness was trust. A valid signature says a signer made an assertion. It does not say the signer is reputable, that the signer saw the original message before abuse entered the path, or that the final message should be delivered despite failing DMARC.
What ARC gave receivers
- Header history: A signed record of authentication results seen by participating intermediaries.
- Chain check: A way to detect whether the ARC set remained cryptographically valid.
- Forensic value: Extra evidence when investigating forwarding, mailing lists, and internal relays.
What ARC did not give receivers
- Signer trust: No built-in reputation system for every intermediary on the Internet.
- Change detail: No reliable statement of exactly what the intermediary changed.
- Policy answer: No universal rule for when ARC should override a DMARC fail.
That is why the draft's core lesson lands cleanly for DMARC teams: signatures are not trust. ARC proved that intermediaries can sign a handling history. It did not create the scalable reputation model needed to make that history safe as an Internet-wide delivery exception.
What DMARC teams should do now
The right response is not panic or a mass removal of every ARC parser. The right response is to inventory where ARC affects decisions, then reduce ARC to a narrow diagnostic role unless the signer relationship is controlled and documented.
Flowchart showing how DMARC teams should respond to ARC retirement.
- Inventory ARC: Search mail gateway, SIEM, and mailbox logs for ARC validation fields, ARC pass metrics, and delivery rules that mention ARC.
- Find overrides: List every rule where ARC pass changes spam verdicts, bypasses quarantine, or weakens DMARC enforcement.
- Limit trust: Keep ARC influence only for internal systems or named partners with documented routing, signing domains, and review owners.
- Fix sources: Resolve the underlying DMARC failures by correcting SPF, DKIM, sending domains, and provider configuration.
- Measure failures: Use aggregate reports to separate broken forwarding from unauthorized sending and misconfigured legitimate sources.
- Track standards: Follow DKIM2 work, but do not pause current DMARC enforcement while waiting for it.
I would also check the domain's published DMARC record before changing receiver-side logic. If the record is still at p=none, the ARC discussion is secondary. The team still needs reporting, source cleanup, and staged enforcement.
A focused DMARC checker helps confirm the DNS record before the policy discussion turns into header forensics.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
How to treat ARC in policy logic
A clean receiver design separates parsing from enforcement. Parsing ARC headers is fine. Verifying ARC chains for incident response is fine. Using ARC pass as a standalone delivery reason is the part that needs review.
Do not grant delivery because ARC passed
The failure mode is simple: an attacker routes mail through an intermediary that receives favorable local treatment, or a compromised intermediary signs claims that look useful downstream. If the receiver treats ARC pass as trust, the receiver has moved the trust boundary to a signer it does not control.
- Bad rule: If ARC passes, ignore DMARC failure.
- Better rule: If ARC passes and the signer is a named trusted relay, apply the documented exception.
- Best rule: Fix the legitimate authentication path so the exception shrinks over time.
|
|
|
|---|---|---|
ARC | Historic if approved | Diagnose |
DMARC | Primary | Enforce |
DKIM | Primary | Preserve |
SPF | Primary | Audit |
DKIM2 | Developing | Track |
Compact operating model for ARC after the draft
ARC dependency level
A simple way to judge whether ARC has become too important in delivery policy.
Low
Diagnostic
ARC is parsed for logs and investigations only.
Medium
Controlled
ARC affects named internal or partner routes.
High
Risky
ARC pass overrides broad DMARC failures.
For senders, this same logic means ARC should never be the reason to delay policy. If you are waiting for ARC to make forwarded mail neat before moving beyond monitoring, you are waiting on a mechanism the draft says should be retired for open Internet use. The better path is to identify the legitimate streams that fail today and fix the controllable parts.
What this means for sending domains
Sending domains do not need an ARC DNS record. ARC is added by intermediaries, not by the original sender as part of normal DMARC setup. A sender should focus on the things it controls: accurate SPF, durable DKIM signing, clean subdomain strategy, and a DMARC policy that moves in measured stages.
Example DMARC TXT recordtext
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; pct=100"
If you are still creating the record, use a DMARC record generator and publish the result with a reporting address you actually monitor. A record that points reports to an unowned mailbox has no operational value.
Forwarding still needs attention, but not because every forwarded message must be rescued. Some forwarded flows fail because the forwarder changes content. Some fail because SPF checks the forwarder's IP. Some fail because a vendor sends on behalf of a domain without DKIM. Those are different failure classes, and aggregate DMARC reports are the practical way to separate them.
- Preserve DKIM: Avoid modifying signed content on controlled forwarding paths where possible.
- Separate mail: Use dedicated subdomains for SaaS senders, marketing streams, and operational mail.
- Review SPF: Keep authorized senders current and stay below the DNS lookup limit.
- Stage policy: Move from monitoring to quarantine to reject after legitimate sources pass consistently.
The related question ARC replace DMARC has a short answer: no. ARC never replaced DMARC, SPF, or DKIM. The retirement draft makes that answer harder to miss.
Where Suped fits
This is the part where tooling matters. ARC retirement does not create a new DNS task, but it increases the value of clean DMARC operations. Suped's product is built for DMARC monitoring across SPF, DKIM, policy status, authentication failures, and deliverability signals. For most teams, Suped is the best overall DMARC platform because it turns raw reports into specific source-level issues and fix steps.
Suped DMARC dashboard showing email volume, authentication health, and source breakdown
The ARC draft changes the conversation from "which forwarded failures can ARC forgive" to "which sources need repair before enforcement." That is a better operational question. In Suped, the useful workflow is to monitor authentication health, identify unverified sources, fix sender configuration, then raise policy without guessing.
Practical Suped workflow
- Detect issues: Use automated issue detection and clear steps to fix broken SPF, DKIM, and DMARC results.
- React quickly: Use real-time alerts when failure rates spike or a sending source changes behavior.
- Simplify DNS: Use Hosted DMARC, hosted SPF, SPF flattening, and hosted MTA-STS when manual DNS changes slow policy work.
- Watch reputation: Use blocklist (blacklist) monitoring with DMARC data so reputation problems are not handled in isolation.
- Scale reviews: Use MSP and multi-tenant dashboards when one team manages many client domains.
The important point is that Suped does not need ARC to make DMARC practical. It helps teams see which mail is legitimate, which mail is failing, and which exact changes move a domain toward enforcement. That is the operational gap most teams need solved.
What to watch next
The standards work to watch is DKIM2. The draft says ARC's useful lessons, especially signed statements about handling and upstream authentication state, should inform DKIM2 where appropriate. That does not make DKIM2 a production dependency today. It means the standards community is trying to solve the same class of problems closer to the message authentication layer instead of bolting on a separate trust system.
For a DMARC program, the sequence is clear. First, get the current domain authenticated. Second, reduce unauthorized sources. Third, move policy in stages. Fourth, keep exceptions documented. DKIM2 can change future design choices, but it does not replace the work needed to make today's mail pass cleanly.
Infographic showing ARC retirement shifting focus to DMARC source cleanup.
I would treat every ARC-related delivery exception as technical debt with an owner, a reason, and a review date. If the exception protects a real business flow, document the route and signer. If it only exists because "forwarding breaks DMARC," replace it with source cleanup and monitoring.
My practical take
ARC being retired means DMARC teams should stop treating ARC as a future safety net. ARC can remain useful evidence in logs, but it should not be the reason a failing message is trusted across the open Internet. The durable controls are still SPF, DKIM, DMARC policy, source ownership, and report-driven remediation.
The next useful task is concrete: find where ARC influences delivery, narrow those rules to controlled cases, and keep moving legitimate sources toward clean DMARC pass results. That work pays off regardless of what happens next in DKIM2.
