What ARC Retirement Means for Email Forwarding and

You run a mailing list or a internal mail relay. One day, forwarded messages from your setup start arriving without authentication checks - or failing entirely - even though nothing changed in your SPF, DKIM, or DMARC records. You search for "ARC retired email" and find scattered mentions that don't explain what you actually need to do.

This is the situation a growing number of email practitioners are running into. ARC - Authentication Results Certification - is being phased out. Here's what that means practically.

What ARC Actually Does

ARC is an authentication extension that handles a specific problem: email forwarding and mailing lists modify messages in ways that break ordinary DKIM signatures.

When a mailing list adds a footer, or an internal relay modifies headers, the email body changes after the original DKIM signature is applied. A receiving mail server seeing the modified body and a broken DKIM signature might reject the message - even though the sender is legitimate.

ARC solves this by creating a chain of custody. Each server that handles and modifies the message adds its own certified authentication result. The chain is evaluated at final delivery, not just at the original signing point. If the original sender passed SPF and DKIM, and the intermediate modifications are legitimate, the final server can still trust the message.

You can spot ARC in email headers:

ARC-Authentication-Results: i=1; mx.google.com;
spf=pass (google.com: 209.85.220.41 is permitted sender)
dkim=pass header.i=@example.com header.b=AbC123;
arc=pass (1)
ARC-Message-Signature: i=1; t=1704067200; ...
ARC-Seal: i=1; s=...;

The `arc=pass` and the ARC-Seal show the chain is intact. If you see `arc=fail`, something in the forwarding chain broke the authentication record.

Why ARC Is Being Retired

ARC wasn't broken - but DKIM2 is designed to make it unnecessary.

DKIM2 introduces two concepts that directly replace what ARC does:

Message-Instance headers carry JSON "recipes" that let a verifier reconstruct the prior state of a message body or headers. A mailing list server adds its footer, then adds a new DKIM2 signature covering the modified message - with the recipe telling the next verifier exactly what changed. The next server can check the signature against the reconstructed state, rather than relying on a separate certification layer.

Replay defense binds each DKIM2 signature to the SMTP envelope via `mf=` (mailfrom) and `rt=` (recipient) tags. A message captured and re-sent to other recipients fails verification because the envelope values don't match. This prevents the exact attack pattern ARC was designed to guard against.

Together, these mean DKIM2 handles forwarding authentication natively - no separate ARC chain needed. The IETF draft that defines DKIM2 (draft-ietf-dkim-dkim2-spec) describes both features as core to the new standard.

ARC is being retired because the problem it solves is solved better inside the signing protocol itself.

What Breaks When ARC Goes Away

Not every email setup depends on ARC. But if yours does, the failure signs are specific.

Mailing lists are the most obvious dependency. Lists that added footers or modified headers without DKIM2 signing relied on ARC to maintain authentication through those changes. Once receivers stop checking ARC, forwarded messages from those lists may start failing DMARC alignment checks - particularly `arc=fail` on messages that previously passed.

Internal relay setups that modify headers - such as internal ticketing systems, internal mail gateways, or any system that stamps messages with internal tracking headers - had similar ARC dependencies. If those systems don't sign with DKIM2, their forwarded output could fail DMARC when ARC is no longer available as a fallback.

What the failure looks like: A message passes SPF and DKIM at the original sender, but after the relay or list modifies it, the receiver sees the modified body with a broken DKIM signature. Without ARC to bridge the gap, the receiver may apply a hard fail based on DMARC alignment - rejecting the message entirely.

The timing question: ARC retirement is not a single flag-day event. Adoption of DKIM2 will be gradual - some receivers will check ARC and some won't. During the overlap, intermittent failures will surface in your DMARC aggregate reports before they appear as user complaints. Monitoring those reports is how you catch the shift early.

What Comes Next: DKIM2 Replaces ARC

DKIM2 is the successor to DKIM, standardized in an IETF draft. It keeps the core DKIM signing mechanism but adds the features that eliminate the need for ARC.

Key DKIM2 additions relevant to forwarding:

- Replay defense (`mf=`, `rt=` tags) - binds signatures to the SMTP envelope. Prevents captured messages from being replayed to other recipients.

- Message-Instance (`i=` tag with recipes) - carries a JSON recipe describing what modifications were made. Verifiers can reconstruct the prior state and check the signature against it.

- Signer intent flags (`donotexplode`, `donotmodify`, `exploded`, `feedback`) - make explicit what the signing server intended for each message. Reduces ambiguity about whether modifications are legitimate.

- DSN (bounce) handling - bounces must follow the chain back through the MTAs that actually handled the message, reducing backscatter from forged bounces.

For mailing list operators, the practical shift is from "add ARC" to "sign with DKIM2 using Message-Instance." For internal relay operators, it is from "add ARC and hope receivers check it" to "DKIM2 sign your modifications explicitly."

DKIM2 adoption is expected to ramp through 2026-2028 as receivers implement support. The overlap period is where monitoring becomes critical.

What You Should Do Now

Identify ARC-dependent flows. Check your mail infrastructure for any servers that add headers, modify message content, or run mailing list software. Look at whether those systems add ARC signatures today.
Check DKIM2 readiness. If your mail servers or mailing list software signs outgoing messages, check whether the software vendor has a DKIM2 roadmap. Many major MTAs are tracking DKIM2 support.
Watch your aggregate reports. During the transition, you'll likely see new failure patterns in DMARC reports - messages failing DMARC alignment that previously passed via ARC. This is where aggregate report monitoring pays off: you catch the shift before it becomes a deluge of failed delivery.
Audit your forwarding infrastructure. If you forward mail to external addresses or receive forwarded mail from partners, check whether those flows depend on ARC and what happens when they're gone.

Frequently Asked Questions

Does this affect my DMARC policy?

No. Your DMARC policy (p=none, p=quarantine, or p=reject) stays the same. What changes is how receivers evaluate authentication when messages pass through forwarding or modification chains. If your legitimate sending is already DMARC-aligned and you use DKIM2 for modified messages, your p=reject policy remains safe.

What if I run a mailing list?

Your mailing list software needs to either sign outgoing messages with DKIM2 (using Message-Instance) or ensure it doesn't modify messages in ways that break the original DKIM signature. If you're using modern mailing list software, check the vendor's DKIM2 roadmap. If you've built custom relay infrastructure, you need to add DKIM2 signing.

When will ARC actually stop working?

There's no fixed retirement date published yet. Like most email protocol transitions, it will be gradual - different receivers will drop ARC checking at different times. The practical risk period is already underway, which is why identifying ARC-dependent flows now matters.

How do I know if my email flow depends on ARC?

Look at your DMARC aggregate reports. If you see patterns where forwarded messages from legitimate partners fail DMARC alignment - and those failures appear to correlate with message modifications - that's likely an ARC dependency. You can also examine the raw email headers of forwarded messages to see whether they contain ARC-Seal and ARC-Message-Signature headers.

How does DKIM2 handle forwarding better than ARC?

ARC added a separate certification layer on top of the existing authentication chain. DKIM2 builds the forwarding-aware behavior into the signing layer itself - so a DKIM2-signed message carries its own reconstruction recipe, meaning the verifier can validate the signature against the modified message without needing a separate certification step. This is architecturally cleaner and harder to bypass.

What DMARCFlow Does Here

During the ARC-to-DKIM2 transition, you'll see new failure types in your DMARC reports before you see end-user complaints. DMARCFlow monitors those reports and flags the patterns - so you can investigate which sending paths are affected and why, rather than discovering the problem when delivery failures spike.

The ARC retirement isn't a crisis if you're watching the data. It's a transition that rewards preparation.

This article answers the question: what does ARC retirement mean for email forwarding and authentication. DMARCFlow helps you monitor the transition.