What Happens to Email Authentication When ARC Is Retired?

ARC - the Authenticated Received Chain - is being retired from the email standards track. If you run a mailing list, manage forwarded email infrastructure, or rely on DMARC aggregate reports, this affects you. Most people will see no change. Some will need to act.

This is a plain explanation of what ARC does, why it's being removed, what changes after retirement, and what you should do now.

What ARC Does in Plain English

When an email passes through a forwarding server or mailing list, the forwarding server becomes the new sender. From a receiving mail server's perspective, that forwarded email originated from the forwarding server's IP - not from the original sender's domain. This causes a problem: the forwarded email fails SPF checks against the original sender's domain, because the RFC5321.MailFrom now belongs to the forwarder, not the original sender.

ARC was designed to solve this. It works by attaching a cryptographic chain of signatures to forwarded mail. Each server in the forwarding chain adds an ARC header that records:

• The original SPF result for the original sender's domain
• The original DKIM result for the original sender's domain
• The position of this server in the chain

When the email reaches the final receiving mail server, the receiving server can read the ARC headers, reconstruct the original authentication results, and make a delivery decision based on the original sender's intent - not the forwarding server's current IP.

In practice, ARC is what keeps forwarded mail and mailing list forwards delivering reliably for domains that enforce DMARC strictly. Without ARC, a strict p=reject policy on the original sender's domain would silently block forwarded mail.

Why ARC Is Being Retired

ARC was a useful solution to a real problem, but it was always a workaround layered on top of existing protocols rather than a native part of email infrastructure. Email standards bodies have been reconsidering whether the complexity ARC adds is justified relative to other approaches to the forwarding problem.

The retirement is part of a broader cleanup of email authentication standards. ARC was introduced as a countermeasure for forwarding, but the email ecosystem has changed significantly since ARC was designed. The standards groups now favor solutions that address forwarding more directly at the protocol level rather than patching it with chain signatures.

ARC retirement is not a security failure. It's a standards-level recalibration. The protocols ARC was patching - SPF, DKIM, DMARC - remain active and unchanged.

What Changes After Retirement

Forwarded mail

When ARC is retired, forwarded mail from domains with strict DMARC enforcement will start failing SPF checks at the receiving server. The receiving server will see the forwarding server's IP as the sender, and if the original domain uses p=quarantine or p=reject, the forwarded email is more likely to be flagged or rejected.

This is the most direct operational consequence of ARC retirement. Forwarded mail that currently lands in inboxes because of ARC will begin landing in spam folders or being rejected - not because the original sender changed anything, but because the forwarding chain no longer carries proof of the original authentication.

Mailing list forwarding

Mailing lists that forward mail to subscribers are the infrastructure most directly affected. A mailing list like Mailman, Sympa, or Google Groups receives mail from a sender, then redistributes it to subscriber addresses. Without ARC, the redistributed mail originates from the mailing list's server, not the original sender.

If the mailing list operator hasn't set up SPF or DKIM for the mailing list's own domain, and the original sender's domain uses strict DMARC, the forwarded mail from the mailing list fails DMARC. Until now, ARC allowed the mailing list to preserve the original authentication results through the redistribution. After retirement, that preservation goes away.

Mailing list operators should treat ARC retirement as an operational alert that requires action - not a background change that can be ignored.

What Does NOT Change

**DMARC enforcement itself is unaffected.** DMARC policies (p=none, p=quarantine, p=reject) remain exactly as configured on your domain's DNS records. The retirement doesn't change the DMARC protocol.

**SPF and DKIM validation are unchanged.** These remain the primary email authentication mechanisms. Their results are what DMARC evaluates. ARC retirement doesn't change how SPF and DKIM work.

**Non-forwarded email is unaffected.** If you send email directly from your domain's mail server - no forwarding, no mailing list - ARC retirement has no effect on your delivery.

**DMARC reporting is unaffected.** Aggregate reports (RUA) and failure reports (RUF) still work. These remain your primary visibility into authentication failures.

Who Is Affected and How Much

**Most affected:**

• Mailing list operators
• IT administrators managing forwarded aliases (e.g., support@ forwarded to a personal Gmail)
• Organizations that receive high volumes of forwarded mail from external domains with strict DMARC

**Less affected:**

• Domains with p=none - ARC retirement doesn't change delivery for these
• Direct sender infrastructure - no forwarding, no change
• Organizations whose email sending is fully internal

The practical impact depends heavily on your sending and forwarding profile. If your primary concern is DMARC monitoring and you don't operate forwarding infrastructure, ARC retirement is a background note, not an operational fire drill. If you do operate a mailing list or manage forwarded aliases for strict DMARC domains, you need to plan.

What Forwarding Operators and Mailing Lists Should Do Now

If you operate forwarding infrastructure or a mailing list:

1. **Audit which domains you forward mail for.** If you're forwarding mail from domains with p=quarantine or p=reject, that's the risk surface.

1. **Set up SPF and DKIM for your forwarding infrastructure.** Create a sending domain for your mailing list or forwarder, add it to your DNS, and sign outgoing mail with DKIM. This gives receiving servers a legitimate authentication result to evaluate, rather than relying on ARC to proxy the original sender's results.

1. **Consider using a subdomain for forwarding.** Route forwarded mail from a subdomain you've delegated specifically for this purpose. This keeps your main domain's DMARC policy independent from the forwarding domain's policy.

1. **Watch aggregate reports for ARC-related failures after retirement.** If forwarded mail starts failing DMARC, the aggregate reports will show which source domains are affected. Set up a monitoring process that can receive and act on those reports.

1. **Test before retirement.** If possible, simulate forwarded mail delivery with and without ARC headers to see what your receiving infrastructure does.

FAQ: Common Concerns About ARC Retirement

**Will my forwarded mail stop working?** Possibly, if the original sender's domain uses strict DMARC (p=quarantine or p=reject) and your forwarding infrastructure isn't authorized via SPF or DKIM. If the original domain uses p=none, there is no enforcement, so ARC retirement doesn't affect delivery.

**Will DMARC break after ARC retirement?** No. DMARC enforcement is independent of ARC. Your p=none, p=quarantine, or p=reject policy remains active. The difference is that forwarded mail that currently passes DMARC because of ARC will no longer have that advantage.

**Do I need to change my DNS records?** You don't need to change your DMARC records specifically. But if you operate forwarding infrastructure and want forwarded mail to continue delivering for strict DMARC domains, you need to set up SPF and DKIM for your forwarder's sending identity.

**Can I still use ARC after retirement?** ARC headers may still be present in mail for a transition period, but receiving servers will stop evaluating them. ARC is being removed from the standards track - it won't be enforced or trusted by receiving servers after retirement.

**Does this affect DMARCFlow?** DMARCFlow continues to parse aggregate reports normally. The retirement affects the forwarding infrastructure feeding those reports, not the reports themselves. If you're a mailing list operator or IT pro managing forwarded aliases, watching your DMARC aggregate reports after retirement matters more than it did before - you'll want to spot authentication failures from forwarded mail quickly.