ARC Sealing Explained: How Intermediaries Preserve Authentication

The Three ARC Headers

When an intermediary ARC-seals a message, it adds three headers as a numbered set:

1. ARC-Authentication-Results (AAR)

Records what authentication looked like when the intermediary received the message:

ARC-Authentication-Results: i=1; mx.forwarder.com;
  dkim=pass header.d=example.com;
  spf=pass smtp.mailfrom=example.com;
  dmarc=pass header.from=example.com

This is the critical evidence — it proves authentication passed before forwarding broke it.

2. ARC-Message-Signature (AMS)

A DKIM-like signature over the message at that point in time:

ARC-Message-Signature: i=1; a=rsa-sha256; d=forwarder.com;
  s=arc-selector; h=from:to:subject:date;
  b=<base64 signature>

If the message is modified after this point, the AMS lets the next hop detect the change.

3. ARC-Seal (AS)

A signature that covers the AAR, AMS, and any previous ARC-Seal headers:

ARC-Seal: i=1; a=rsa-sha256; d=forwarder.com;
  s=arc-selector; cv=none;
  b=<base64 signature>

The cv= (chain validation) field indicates whether the previous chain was valid:

• cv=none — this is the first ARC set
• cv=pass — previous ARC chain validated
• cv=fail — previous ARC chain failed (chain is broken)

How the Chain Builds

Multiple intermediaries create a numbered chain:

Hop	Server	ARC Instance	What Happens
1	Origin	None	Sends with SPF + DKIM
2	Mailing list	i=1	Records auth results, ARC-seals
3	Corporate gateway	i=2	Records i=1 results, ARC-seals
4	Recipient inbox	Evaluates	Walks chain: i=2 → i=1 → original

Practitioner note: In practice, most ARC chains are 1-2 hops. If you see an ARC chain with 4+ instances, something unusual is happening — either a complex routing setup or a misconfigured forwarding loop. I've seen both.

Implementing ARC Sealing

If you run infrastructure that forwards email, implementing ARC sealing is straightforward with modern MTAs:

Postfix + OpenARC:

# /etc/openarc.conf
Mode sv
Canonicalization relaxed/relaxed
Domain forwarder.com
Selector arc
KeyFile /etc/openarc/arc.key

Rspamd (built-in):

-- /etc/rspamd/local.d/arc.conf
sign_authenticated = true;
domain {
  forwarder.com {
    selector = "arc";
    path = "/etc/rspamd/arc.key";
  }
}

You'll need a dedicated DKIM-style key pair for ARC signing — separate from your regular DKIM keys.

Who Trusts ARC

ARC is a trust-based system. Receiving servers maintain lists of intermediaries they trust:

• Gmail trusts ARC seals from major mailing list providers and known forwarding services
• Microsoft 365 evaluates ARC for their spam filtering decisions
• Yahoo considers ARC in delivery decisions

An ARC seal from an unknown or untrusted intermediary won't help much. Building reputation as an ARC sealer takes time.

Practitioner note: If you operate a mailing list or forwarding service and your users complain about DMARC failures, implementing ARC sealing is the fix. It won't help overnight — receivers need to learn to trust your seals — but it's the right long-term solution.

If you're running email infrastructure that forwards messages and need ARC sealing configured correctly, get in touch.

Sources

• RFC 8617: The Authenticated Received Chain (ARC) Protocol
• RFC 8617 Section 5: ARC Set Definition
• Google: ARC Implementation
• OpenARC: GitHub Repository

---

v1.0 · April 2026