ARC: how forwarded mail still passes DMARC

DMARC has one famous failure mode: forwarding. A mailing list rewrites the message; SPF breaks because the connecting IP changes; DKIM breaks because most lists modify subjects or bodies. ARC (Authenticated Received Chain, RFC 8617) is the standard that lets the forwarder vouch that authentication passed before they touched the message — and lets the final receiver trust that vouch.

The problem ARC solves

Imagine Alice subscribes to a discussion list. Bob posts. The list resends Bob's message with a [list] subject prefix and an Original-From rewrite. The message arrives at Alice's mailbox. SPF: fails (the connecting IP is the list, not Bob's domain). DKIM: fails (the subject changed, breaking the signature). DMARC: rejected if Bob's policy is p=reject.

ARC fixes this by letting the list say, in cryptographically verifiable headers: "When this message arrived at me, it passed authentication. Here's a sealed copy of the auth result." If Alice's mail server trusts the list as an ARC signer, it can accept the message.

The three headers

Each hop increments i= (the instance number). The final receiver walks the chain from i=1 upward, validating each seal. If the chain is intact and cv=pass, the receiver can trust that authentication held end-to-end.

Who actually uses ARC

What ARC does NOT do

• It's not authentication for regular senders. If you don't operate an intermediary, ARC is irrelevant to your sending posture.
• It doesn't fix forwarding for unsigned chains. The first hop must sign for the chain to mean anything.
• Trust is local. Each receiver decides which ARC signers to honor. There's no global PKI.
• It doesn't let you bypass DMARC for new senders. Receivers only trust ARC from operators they've decided to trust.

If you operate a mailing list

1. Enable ARC signing in your list software (Mailman 3, Listmonk, etc.). It's usually a config flag.
2. Generate a DKIM keypair and publish the public key — same DNS pattern as DKIM.
3. Sign every outgoing message with ARC-Seal, ARC-Message-Signature, ARC-Authentication-Results headers.
4. Test by sending through your list to a Gmail address. Inspect raw headers — Gmail will show its own Authentication-Results reflecting the ARC chain.

Reading an ARC chain

ARC-Seal: i=1; a=rsa-sha256; cv=none; d=lists.example.com;
    s=arc20260101; t=1768300000;
    b=...
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;
    d=lists.example.com; s=arc20260101;
    h=from:to:subject:date; bh=...
    b=...
ARC-Authentication-Results: i=1; lists.example.com;
    spf=pass [email protected];
    dkim=pass header.d=bob.example;
    dmarc=pass header.from=bob.example

Read this as: the list (lists.example.com) saw the message arrive from Bob with a clean SPF/DKIM/DMARC pass, then signed and sealed that fact at instance 1. A second hop would add i=2 headers; the receiver walks all of them.