ARC is being retired: what the IETF draft means for DMARC teams

I genuinely don't know how to feel about this one. After seven years of real-world deployment, the IETF DMARC working group recently published a new draft. It proposes marking the Authenticated Received Chain protocol as "Historic". That essentially means the experiment is over, and we should stop building new systems around it.

When you look at the daily email traffic we process at Suped, forwarding is the biggest headache. A company sends a perfectly authenticated email. It hits a recipient's inbox. That recipient has an auto-forward rule set up to send everything to their personal Gmail account. Suddenly, the sender IP changes. The Sender Policy Framework (SPF) fails. The forwarding server tacks on a "Forwarded by" footer. DomainKeys Identified Mail (DKIM) fails. DMARC fails, and the message drops into the spam folder.

ARC was supposed to be the answer to this exact problem. The idea was simple. If an intermediary server handles a message, it checks the authentication. Then it slaps its own cryptographic signature on the email to attest to what it saw. It defined three specific headers to capture the initial authentication state, sign the message, and seal the headers to prevent tampering.

When the final receiving server gets the message, it looks at the chain of signatures. It can say that the original signature broke, but a trusted server in the middle confirmed it was fine earlier.

Except, it turns out that signatures are not trust.

The authors of the new IETF draft, Trent Adams and John Levine, lay out the operational realities clearly. Verifying a cryptographic signature is necessary, but it does not tell you whether you should trust the entity that signed it.

For ARC to work across the open internet, every receiving mail server needs to know the reputation of every forwarding server. Operating and sharing reputation scores for thousands of random intermediaries is expensive. Nobody built a global reputation system for ARC. Instead, large mailbox providers relied on static allow lists for a few major mailing lists. That works for closed consortiums, but it completely falls apart for the millions of tiny, dynamic forwarding rules scattered across the web.

There is another blind spot. When a server adds an ARC signature, it verifies that the message passed through its systems. It does not record what it actually changed. If the final receiver sees a broken DKIM signature and a valid ARC chain, they still have to guess. Did the middle server just add a harmless footer, or did it inject malicious links? You simply cannot know.

Because of these unknowns, receiver policies fractured. Every mail administrator had to decide how many hops to trust and what to do with conflicting chain links. That lack of predictability meant senders could never actually rely on ARC to ensure deliverability. We saw this constantly in the logs. Senders would hope ARC would save their forwarded mail, but the final recipient servers simply ignored the ARC chain and rejected the mail anyway.

The protocol did find some use inside single administrative domains. If a large corporate network routed mail through five different internal spam filters, they could use ARC to track the message internally. They already trusted their own servers. But that was never the main goal. The goal was open internet interoperability. When that failed, the entire premise of ARC as a broad deliverability solution collapsed.

While ARC is stepping down, the underlying problem of email forwarding still needs a fix. The community is taking everything learned from the ARC experiment and pouring it into the next generation of email security. That successor is DKIM2.

DKIM1 is over a decade old. It proves that an email came from your domain. DKIM2 tracks the entire route an email takes from sender to recipient.

When a message passes through a forwarder today, DKIM1 breaks if the content changes. DKIM2 operates differently. It standardizes how headers are signed and requires intermediaries to document the exact changes they make. DKIM2 achieves this by calculating a hash value on the current contents of the message. If a server adds a line of text, it records that specific modification and calculates a new hash. The final receiving server can then virtually undo the change to verify the original signature.

This approach is much better for security. It removes the need for a massive, parallel reputation system. Mail servers can verify the exact path and the exact modifications without needing to blindly trust the intermediary.

DKIM2 also tackles replay attacks. Cybercriminals frequently capture a legitimate, signed email and resend it to thousands of people months later. Because the original DKIM1 signature is still technically valid, the mail servers accept it. DKIM2 introduces timestamps and recipient-specific details. If an attacker tries to replay a six-month-old email, the receiving server immediately sees the discrepancy and rejects it.

Backscatter is another issue that DKIM2 addresses. Right now, if someone spoofs your domain and the email bounces, the failure notice goes to your inbox. You end up with thousands of bounce messages for emails you never sent. DKIM2 fixes this by directing delivery status notifications to the exact server that last handled the message.

The new draft is clear. If you operate receiving mail servers, you can still parse ARC headers for forensic data. You should not use them to override DMARC enforcement without a highly controlled, internal trust policy.

For senders, this means you need to focus on strict DMARC compliance and monitor your traffic closely. You cannot rely on intermediaries to patch your authentication gaps. I spend a lot of time looking at delivery logs, and the domains that succeed are the ones with clean, aligned infrastructure. If your basic SPF and DKIM setup is flawed, no experimental protocol is going to save your deliverability. Send authenticated mail, and stop chasing experimental workarounds.

DKIM2 is still in the draft phase at the IETF. It will take time before major mailbox providers adopt it fully. The transition from DKIM1 to DKIM2 will likely span years. You cannot just wait around for a new standard to fix your bounce rates.

Until DKIM2 becomes the universal standard, you need visibility into what happens to your emails after they leave your servers. Set up proper monitoring. Review your failure reports. Fix your alignment issues at the source.

We built Suped to give you that exact visibility. The email security protocols are changing, but the core rule remains the same. You need to send properly authenticated mail and watch your data closely. Stop hoping for a magic bullet, and start looking at what your reports are actually telling you.