DMARCGuardian Practical help for DMARC, SPF, DKIM, and BIMI.

Blog · Dmarc

Why ARC Is Being Retired in 2026 -- and What Email Operators Need to Do Before Then

By Oliver at DMARCFlow

What ARC Is and Why It Exists

ARC -- Authenticated Received Chain -- arrived in 2019 as RFC 8617. It was built to solve one specific problem: email forwarding breaks DMARC alignment. When a message passes through a forwarder, the forwarder's mail system becomes the new sending server. DMARC sees a misalignment, and legitimate forwarded mail fails authentication.

ARC added a chain of signatures that let forwarders preserve the original authentication results. The receiving mail system could see: the message was authenticated at origin, forwarded by this server, and still valid.

If you run a mailing list, a forwarded email service, or any infrastructure that re-sends mail on behalf of users, ARC has been keeping your legitimate traffic out of spam folders.

What It Means That ARC Is Being Retired

The IETF DMARC working group has proposed marking RFC 8617 as Historic. The working draft is draft-ietf-dmarc-arc-to-historic-00. Historic status means the protocol is no longer considered current best practice. This is a standards-level retirement, not a bug fix or a security patch.

The exact timeline is not finalized. The IETF process requires working group consensus, an IESG review, and an RFC editor appointment. Expect the process to conclude in 2026, but the exact date depends on how quickly the working group moves through the remaining steps.

Three Things That Will Break When ARC Goes Away

Forwarded mail visibility degrades. ARC headers let receiving systems see original authentication results even after forwarding. Without them, forwarding scenarios revert to standard DMARC behavior. Legitimate forwarded messages may fail alignment checks and land in spam. The effect hits hardest on large mailing lists and shared inbox services.

Reputation-preservation chains stop working. Some operators use ARC as part of their reputation system. If you rely on ARC signatures to propagate authentication results through a chain of processors, those chains will break. You will need a different method for maintaining sender reputation across intermediate mail handlers.

Tools that ingest ARC headers will have gaps. Any dashboard or report that depends on ARC-Message-Signature, ARC-Seal, or ARC-Authentication-Results will lose a data source it currently uses. If your monitoring ingests these headers, your analytics will start showing incomplete pictures of your authentication health.

What to Use Instead

There is no direct drop-in replacement for ARC. The IETF is retiring it because the working group believes the problem can be addressed through other means.

For most operators, the practical replacement stack is:

  • Extended headers (RFC 8601) for additional authentication context that survives forwarding
  • Standard DMARC aggregate reports (RUA) for high-level authentication health
  • Forensic reports (RUF) for failure investigation, where your receiving infrastructure supports them
  • Improved DKIM alignment practices to reduce alignment failures in forwarded scenarios

If you run a forwarding service or mailing list, the best immediate step is to audit your DKIM signing configuration. Make sure your forwarding infrastructure signs outgoing mail correctly and that your DMARC policy is set to p=quarantine -- not p=reject -- until you have verified alignment across your forwarding path.

How DMARCFlow Helps During the Transition

As ARC disappears from your mail flow, you still need to see which forwarding paths are generating alignment failures. DMARCFlow's aggregate reporting dashboard surfaces this data directly -- you can filter by authentication result, domain, and time period to identify exactly which forwarding scenarios are causing DMARC failures.

This matters because the failure patterns you need to fix are not always obvious from raw mail logs. A forwarded message that fails DMARC looks the same as a spoofing attempt in a plain text report. DMARCFlow's grouping logic helps you distinguish between the two: if you see consistent DKIM alignment failures from a specific forwarder's domain but the SPF is clean, that is a forwarding problem, not a compromise.

Using DMARCFlow during the transition also gives you a baseline. Run a report now, before ARC traffic decreases significantly. Then compare against the same report in six months. The delta tells you how much of your forwarded mail health depended on ARC -- and how much you need to fix in your DKIM signing configuration.

DMARCFlow's aggregate reporting dashboard gives operators the visibility they need during this transition -- sign up at dmarcflow.com to get started.

Action Checklist for 2026

  • Audit your current use of ARC headers in inbound mail processing. Note which systems depend on ARC-Message-Signature, ARC-Seal, or ARC-Authentication-Results.
  • Review your DKIM signing configuration across all forwarding infrastructure. Verify that forwarded mail domains sign correctly to maintain alignment.
  • Update monitoring and analytics that ingest ARC headers. Plan for reduced data in tools that currently rely on ARC chain information.
  • Set calendar reminders for IETF working group updates on the ARC retirement timeline. The final Historic designation will include an effective date.
  • Run a DMARCFlow aggregate report now, before ARC traffic decreases significantly. Use it as your baseline for measuring progress on DKIM alignment improvements.

The ARC retirement is a standards-level change, not an emergency. The operators who audit their current ARC usage and fix their DKIM signing now will avoid the last-minute scramble when the final RFC drops.