ARC Is Being Retired: What It Means for Email Authentication and Mailing Lists

What Is ARC — and Why Did We Need It?

Anyone running DMARC knows the forwarding problem. An email travels through a mailing list or a forwarding service, and suddenly DMARC fails. The original sender did everything right — SPF, DKIM, DMARC — but the intermediary server modified the message or introduced a new sending IP. The receiving server sees a message that no longer passes authentication checks.

ARC (Authenticated Received Chain) was designed specifically for this scenario. It is a mechanism that documents and carries authentication results across multiple forwarding hops. Each intermediary server — an ARC sealer — appends a cryptographically signed record of the authentication state it observed. The final receiving server can inspect this chain and decide whether to trust the original authentication, even if SPF or DKIM fail on the last hop.

ARC was published in 2019 as an experimental RFC (RFC 8617). In IETF terms, “experimental” means there is interest but no guarantee of broad adoption or long-term standardization.

Why Is ARC Being Retired Now?

After years as an experimental standard, the IETF has decided not to advance ARC to full Internet Standard status. The reasons are layered:

• Insufficient adoption: Only a handful of mail server implementations ever fully and correctly implemented ARC. The critical mass needed for a functioning ecosystem never materialized.
• The trust problem: ARC only solves the authentication problem if every server in the forwarding chain implements ARC correctly and if the receiving server trusts the ARC sealer. That trust model proved difficult to operationalize at scale.
• Complexity without clear payoff: Implementing ARC is non-trivial, and the benefit depends heavily on the environment. For most operators, the effort simply wasn’t justified.

The result: ARC remains technically usable, but it will no longer be actively developed. Building on it today means building on a foundation that is being wound down.

What Does This Mean for Mailing Lists?

Mailing lists are the canonical ARC use case. A user sends a message to a list, the list server modifies it — appending a footer, changing the Reply-To header — and the modified message is distributed to all subscribers. In the process, the original sender’s DKIM signature typically breaks, and SPF fails because the sending IP is now the list server’s.

Without ARC — or without a functioning ARC implementation across all involved servers — this means: messages from mailing lists will be blocked or quarantined by strict DMARC policies (p=reject or p=quarantine).

Scenarios that need attention now:

• Self-hosted mailing lists (Mailman, Listserv, Sympa): Check whether the list server signs outgoing messages with its own DKIM key. This is the most reliable fix: the list server becomes the legitimate sender and takes ownership of the authentication.
• External list services: Providers like Google Groups or Mailchimp handle this differently. It is worth reviewing the current authentication practices of each provider you rely on.
• Mailbox-level forwarding: Classic .forward redirects are particularly vulnerable. SRS (Sender Rewriting Scheme) helps with SPF, but DKIM remains a problem unless the forwarding server re-signs.

What Are the Alternatives?

The retirement of ARC does not mean the forwarding authentication problem is solved — it means there is no longer a universal protocol-level solution. IT admins need to rely on a combination of established practices instead.

DKIM re-signing by the list server: The list server strips the original DKIM signature and signs the message with its own key. The From header still shows the original user, but the DKIM signature belongs to the list server’s domain. This works cleanly unless the sender’s DMARC policy enforces strict alignment with p=reject — in which case From-header munging is also needed.

From-header munging: The list server rewrites the From header, for example from [email protected] to user via [email protected]. It is not elegant, but it is reliable and widely supported. Most modern mailing list software does this automatically when it detects a p=reject DMARC policy on the sender’s domain.

Dedicated subdomains for mailing lists: Operators running their own lists can use a dedicated subdomain (e.g., lists.example.com) with a separate, less restrictive DMARC policy scoped to that subdomain.

Moving away from mailing lists: In many cases, modern collaboration tools (Teams, Slack, etc.) are a more practical alternative to classic mailing lists — though that is an organizational decision, not a technical fix.

What Should IT Admins Do Now?

The ARC retirement is a good prompt to audit your email infrastructure:

1. Review your DMARC reports: Which sources are sending on your behalf, and which of them are failing DMARC? Mailing lists and forwarders frequently show up as problem sources.
2. Check your list server configuration: Is it signing with its own DKIM key? Is From-munging enabled where needed?
3. Plan your path to a stricter DMARC policy: If you are still on p=none, map out the steps to p=quarantine and then p=reject — but only after all legitimate sending sources are correctly configured.
4. Inventory external forwarders: Are there mailboxes that auto-forward messages? These often go unnoticed in DMARC reports but can cause real deliverability problems.

The good news: the core principles of DMARC, SPF, and DKIM are unaffected by the ARC retirement. A crutch that was never widely adopted is being removed — and that is an opportunity to build a cleaner, more resilient authentication setup.

Check how your domain is configured right now — the free domain check at dmarcpulse.io shows you instantly whether your DMARC, SPF, and DKIM setup is ready for an ARC-free world.