ARC Is Heading Toward Retirement: What the IETF Draft Says and What to Do Now

An IETF DMARC working group draft, draft-ietf-dmarc-arc-to-historic, proposes reclassifying ARC (Authenticated Received Chain, RFC 8617) as Historic. It is not approved. It is a working group document, and the outcome could still change. What is already clear is the practical advice: don't build your email authentication around ARC. Rely on DKIM alignment, and use your DMARC reports to find forwarders that break it.

What the Draft Says, and Its Status

We checked the IETF Datatracker page for the draft on November 4, 2026. At that time:

• It is an active Internet-Draft in the DMARC working group, revision 01, last updated October 21, 2026.
• The working group state is "WG Document". The IESG state is "I-D Exists", meaning it has not been put in front of the IESG for evaluation.
• No intended RFC status is set on the Datatracker, though the draft header lists Informational.

In substance, the draft proposes ending the ARC experiment defined in RFC 8617. It recommends that ARC not be deployed or relied upon between unrelated senders and receivers, reviews the operational experience with ARC, and asks that RFC 8617 be moved to Historic so that new deployments are discouraged.

Drafts change, stall, and get withdrawn. Treat this as a direction, not a decision, and check the Datatracker page if the exact status matters to you. Our date above is the date of our check, not a guarantee about today.

Why ARC Never Got Broad Trust

ARC was designed to help with forwarding. A forwarder records the SPF, DKIM, and DMARC results it saw, then seals them with its own signature. We cover the mechanics in email forwarding and DMARC.

The weak point is trust. An ARC seal only helps if the receiver already believes the sealer. A seal from a forwarder the receiver has never heard of proves nothing, because anyone can add ARC headers. So in practice each large receiver keeps its own short list of sealers it trusts, and that list is not published or shared in a standard way.

That works for a few big forwarders talking to a few big mailbox providers. It does not work between unrelated senders and receivers, which is the case the draft says ARC should not be relied on for. For a small domain, the result is that you can't predict whether any given receiver will honor an ARC seal, and you can't ask for it to be honored.

What DKIM2 Is and Where It Stands

The draft points to DKIM2, a proposed successor to DKIM, as where the lessons from ARC are going. DKIM2 is also still proposal-stage work in the IETF, not a deployed standard. We are not aware of any mailbox provider you can configure around it today, so it is a reason to watch the space, not something to act on yet.

What to Do Today

ARC being retired changes little for a typical domain, because the sound advice never depended on it.

1. Make sure every sender you control signs with DKIM, aligned to your From domain. DKIM usually survives forwarding, and DMARC passes if either SPF or DKIM aligns. See what DKIM is if you need the background.
2. Don't count on ARC-aware forwarders to rescue failures. If a message fails both SPF and DKIM alignment after a hop, an ARC seal may or may not save it, depending on the receiver.
3. Spot forwarders in your reports. In your DMARC aggregate reports, forwarded mail shows up as SPF failures from IPs you don't recognize, often with DKIM still passing. Those are fine as long as the passing DKIM signature aligns with your From domain (that is what lets DMARC pass). Trouble is when DKIM fails or doesn't align, which usually means the forwarder modified the message or the original sender never signed. Our guide to why your DMARC is failing walks through the other common causes.
4. Move to p=reject only when your real mail passes through DKIM alignment. If your domain is heavily forwarded and some senders lack DKIM, staying at p=quarantine is the safer position for now.
5. Check a real forwarded message. Paste its headers into the Email Auth Checker and look at the SPF, DKIM, and DMARC results. Any ARC headers you see are informational:

ARC-Seal: i=1; a=rsa-sha256; d=forwarder.example; s=arc; cv=none; b=...
ARC-Authentication-Results: i=1; forwarder.example; spf=fail; dkim=pass header.d=yourdomain.com; dmarc=pass

If you use Cloudflare Email Routing, which adds ARC headers by default, nothing needs to change. Keep relying on the original sender's DKIM signature.

Use the Email Auth Checker to see how a forwarded message from your domain actually authenticates.