ARC Email Protocol Experiment Ends as Industry Shifts to DKIM2 Standard

If you’ve been following email authentication news lately, you may have seen a quiet but significant announcement come through the IETF mailing lists on April 22, 2026. The DMARC working group published a new Internet-Draft — draft-ietf-dmarc-arc-to-historic-00.txt — formally proposing to reclassify ARC, the Authenticated Received Chain protocol, as “Historic.” That’s IETF-speak for “this experiment is over, stop building on it.” For email marketers, list managers, and deliverability teams, this is worth understanding — not because it breaks anything today, but because it clarifies something many of us have suspected for a while: ARC was never as reliable a safety net as we hoped it would be.

Let’s back up and talk about what ARC was supposed to do, because that context matters a lot for understanding where your mail might be quietly failing right now.

When a message passes through an intermediary — a mailing list processor, a forwarding rule, a security appliance that rewrites links or tags subject lines, a partner syndication system — the original DKIM signature can break. The body or headers change, the cryptographic hash no longer matches, and suddenly a message that was perfectly authenticated when it left your ESP arrives at the receiving mailbox provider looking like it failed DKIM. If your domain publishes a DMARC policy of p=quarantine or p=reject, that failure can mean your mail goes to spam or gets dropped entirely — even though the message was completely legitimate.

ARC was designed to solve this. The idea was that each intermediary in the chain would sign a record of what the authentication status looked like when the message arrived at that hop. A receiving mailbox provider could theoretically look at that chain of signed records, decide the intermediaries were trustworthy, and honor the original authentication result even if DKIM itself had broken. It was an elegant concept. The problem, as the new draft openly acknowledges, is that it didn’t work well enough in practice. Most receivers have told the industry they can’t use or trust ARC signatures reliably. The operational experience just wasn’t there to make it a dependable mechanism between disparate senders and receivers.

So what does this mean if you’re running a newsletter program, managing a community mailing list, syndicating content through partner systems, or relying on corporate forwarding rules for employees? It means you should not assume ARC is quietly rescuing your mail when authentication breaks in transit. In many cases, it probably isn’t.

Signs that ARC is not saving your mail

The honest answer is that most senders have no easy visibility into whether ARC is helping or not, which is part of the problem. But there are signals worth watching. If you’re seeing unusual complaint rates or deliverability drops specifically on messages that pass through intermediaries — forwarded mail, list-exploded campaigns, messages routed through a security gateway — ARC is unlikely to be the thing bailing you out. DMARC aggregate reports (rua) can show you authentication pass/fail rates, but they won’t tell you whether a failed result was partially rescued by ARC at a specific receiver. If your DMARC reports are showing failures on mail you know is legitimate and forwarded, that’s a strong indicator that ARC isn’t providing the protection you might have assumed.

Security appliances that rewrite links for click-tracking or add subject line tags are a particularly common culprit. Many organizations deploy these without fully realizing they break DKIM, and many IT teams assume ARC is handling the fallout. In reality, whether any given receiving mailbox provider honors those ARC signatures has always been inconsistent — and the new draft signals that the working group has concluded the inconsistency is fundamental, not fixable with more deployment.

What’s coming next: DKIM2 and why it matters here

The draft explicitly notes that the lessons learned from the ARC experiment are being incorporated into DKIM2, the emerging successor to the current DKIM standard. This is important context. ARC isn’t being deprecated because the problem it tried to solve doesn’t matter — it’s being deprecated because a better approach is being built.

As Laura Atkins at Word to the Wise explains in her detailed breakdown of DKIM2, the new protocol takes a fundamentally different approach to the intermediary modification problem. Instead of an intermediary simply asserting “this message was authenticated when I received it” (the ARC model), DKIM2 requires each intermediary to cryptographically record exactly what changes it made to the message. Any downstream handler can then unwind those changes and verify the message all the way back to the original sender’s signature. Nobody has to trust the intermediary’s word — the changes are verifiable and auditable. That’s a much stronger foundation than ARC ever provided.

DKIM2 also addresses DKIM replay attacks, where a spammer sends a single legitimate-looking message to an address they control and then redistributes it at scale without modification, riding the reputation of the original sender’s DKIM signature. DKIM2 records envelope recipient and sender information in the signature and includes flags that can prevent or mark message explosion. And it tackles the backscatter problem by enabling mailbox providers to return delayed bounces directly and securely to the actual intermediary that last handled the message — rather than to a potentially forged return address.

That last point has significant operational implications for anyone sending at volume. If major mailbox providers begin using DKIM2-enabled delayed bounces to return spam-foldered mail back to senders rather than silently dropping it into the junk folder, your reported delivery rates could look different 24 hours after a send than they did at the moment of transmission. Infrastructure and compliance teams will need to be ready for that shift. It also means compliance signals will get sharper — providers will be able to send precise, reliable feedback about which messages hit the spam folder, which is a much cleaner signal than current feedback loops.

Working code for DKIM2 already exists, and the expectation from those close to the development is that some major mailbox providers could begin deploying it in testing mode before the end of 2026. For brand senders using an ESP, much of this will happen behind the scenes — DKIM2 reuses existing DKIM keys, so you may not need to make any immediate changes to your DNS or signing configuration. Your sending infrastructure provider will need to update their signing libraries and handle dual-signing (both DKIM and DKIM2) during the transition period, similar to how the industry handled the overlap between DomainKeys and DKIM years ago.

What to ask your IT and security teams before tightening DMARC policy

Given all of this, here’s the practical conversation you should be having with your IT and security teams — especially if you’ve been considering moving your DMARC policy from p=none to p=quarantine or p=reject, or if you’re already at reject and seeing authentication failures you can’t explain.

• Which systems in our mail flow modify messages in transit? Get a complete list: security gateways, link-rewriting appliances, subject-line tagging tools, mailing list processors, forwarding rules, and any partner or syndication systems that touch your outbound mail. Each one is a potential DKIM breakage point.
• Are we currently relying on ARC to handle authentication failures from those systems? If the answer is yes, or “we think so,” that’s a risk. The new IETF draft makes clear that ARC’s reliability between different senders and receivers has not been sufficient to depend on.
• What does our DMARC aggregate reporting actually show for forwarded and intermediary-routed mail? If you’re not reviewing rua reports regularly, now is the time to start. Look specifically for authentication failures on mail streams you know are legitimate.
• What’s our plan for DKIM2 adoption? If you’re using an ESP or managed sending infrastructure, ask your provider what their DKIM2 roadmap looks like. If you run your own mail infrastructure, start watching the IETF datatracker and the libraries being developed by the DKIM2 working group.
• How will our bounce handling and reporting change if major providers start sending delayed bounces at higher volume? This is a forward-looking question, but it’s worth getting on the radar now rather than being surprised when delivery rate reporting starts behaving differently than expected.

The deliverability bottom line

The reclassification of ARC as Historic is a signal that the email authentication ecosystem is moving on — not abandoning the problem ARC tried to solve, but solving it better with DKIM2. For email marketers, the near-term practical reality is straightforward: do not assume ARC is protecting your mail when it passes through intermediaries that modify it. Audit your mail flow, review your DMARC reports, and be cautious about tightening DMARC policy to reject without first understanding every place in your infrastructure where DKIM might break. The longer-term shift to DKIM2 will eventually make authentication more robust and forwarding-friendly than anything we have today — but we’re in a transition period, and the old safety net is being officially retired before the new one is fully in place.

Stay close to your deliverability data, keep the conversation going with your IT and infrastructure teams, and watch how the major mailbox providers begin rolling out DKIM2 support over the coming months. This is one of those foundational shifts that will quietly reshape how authentication works across the entire industry — and the senders who understand it early will be much better positioned when the changes start showing up in their metrics.