ARC: Authenticated Received Chain Explained

The Problem ARC Solves

Email authentication works beautifully when a message travels directly from sender to recipient. But a significant portion of legitimate email does not travel a straight path. Mailing lists, corporate mail gateways, university forwarding services, and security gateways all relay messages — and each hop can break DKIM signatures or cause SPF failures.

When these forwarding scenarios trigger DMARC failures, the result is that perfectly legitimate email lands in spam or gets rejected entirely. Before ARC, there was no good solution to this problem.

ARC (Authenticated Received Chain), defined in RFC 8617, creates a cryptographically signed chain of custody record. Each intermediary that handles the message adds a set of ARC headers that say: "When I received this message, these were the authentication results, and I vouch for them with my cryptographic signature." The final receiving server can then evaluate this chain and make a more nuanced delivery decision.

Why Forwarding Breaks Authentication

SPF and the Source IP Problem

When a message is forwarded, the forwarding server sends it onward using its own IP address — not the original sender's IP. The recipient's mail server performs an SPF check against the forwarding server's IP, which is not authorised in the original sender's SPF record.

Original flow:
[email protected] → Google's mail servers (IP: 209.85.220.41) → recipient

Forwarded flow:
[email protected] → Google → forwarding-server.com (IP: 198.51.100.5) → recipient

SPF check at recipient: Is 198.51.100.5 in gmail.com's SPF? NO → SPF FAIL

DKIM and the Modification Problem

DKIM signs specific headers and the message body. Mailing list software commonly modifies messages — prepending the list name to the subject, adding a footer, changing the Reply-To header, or re-encoding the body. Any of these modifications invalidates the original DKIM signature.

Original subject: "Project Update"
After mailing list: "[projectname] Project Update"  ← DKIM signature broken

When both SPF and DKIM fail, DMARC has no passing aligned mechanism to evaluate, and the message fails DMARC — even if it is entirely legitimate.

The Three ARC Headers

ARC adds three new headers to a message at each intermediary hop. Together they form a numbered set called an ARC instance.

ARC-Authentication-Results (AAR)

Records the authentication results (SPF, DKIM, DMARC) that the intermediary observed when it received the message.

ARC-Authentication-Results: i=1; mx.forwarding-server.com;
  spf=pass [email protected];
  dkim=pass header.d=gmail.com;
  dmarc=pass header.from=gmail.com

This preserves evidence that authentication was passing before the message was modified or forwarded onward.

ARC-Message-Signature (AMS)

A DKIM-like signature over the entire message — headers and body — as it existed when the intermediary received it. This allows downstream receivers to verify that the message was not tampered with after the intermediary signed it.

ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;
  d=forwarding-server.com; s=arc-20240101;
  h=from:to:subject:date:message-id;
  bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=;
  b=<signature>

ARC-Seal (AS)

A signature over the set of ARC headers for this instance plus all previous ARC headers. This locks the chain together — an attacker cannot modify earlier ARC instances without breaking the seal.

ARC-Seal: i=1; a=rsa-sha256; t=1706745600;
  cv=none; d=forwarding-server.com; s=arc-20240101;
  b=<seal-signature>

The cv= tag indicates the chain validation status from the intermediary's perspective: - cv=none — First ARC instance; no prior chain to validate - cv=pass — The intermediary validated the prior ARC chain successfully - cv=fail — Prior chain validation failed; chain is broken

How the Chain Grows at Each Hop

Each intermediary that participates in ARC adds its own numbered instance, incrementing the i= counter.

Original message from Gmail:
  (no ARC headers)
  SPF: pass, DKIM: pass, DMARC: pass

After mailing list (hop 1):
  ARC-Authentication-Results: i=1  ← Results observed on arrival
  ARC-Message-Signature: i=1       ← Signature of message as received
  ARC-Seal: i=1; cv=none           ← No prior chain

After corporate gateway (hop 2):
  ARC-Authentication-Results: i=2  ← Results observed (SPF now fails, DKIM broken)
  ARC-Message-Signature: i=2       ← Signature of current message state
  ARC-Seal: i=2; cv=pass           ← Prior i=1 chain validated successfully

Final recipient evaluates:
  - DMARC direct check: FAILS (SPF/DKIM broken by forwarding)
  - ARC chain: cv=pass at i=2, i=1 shows original DKIM passed
  - Decision: Deliver normally (trust the ARC chain)

Evaluating ARC at the Receiving End

The final receiver evaluates ARC through a trusted forwarder concept. ARC does not unconditionally override DMARC — the receiver must decide whether to trust the ARC chain.

Validation Steps

1. Find the highest i= instance — This is the most recent intermediary
2. Verify the ARC-Seal starting from i=1 up to the highest instance
3. If any seal fails, the entire chain is considered broken
4. Check cv= tags — All must be none (for i=1) or pass (for subsequent)
5. Examine the i=1 ARC-Authentication-Results — Was authentication passing at the origin?

Trusted Forwarder Lists

Most major mail providers maintain internal lists of ARC-trusted forwarders — intermediaries whose ARC signatures they trust. This is similar to how IP reputation works, but for ARC.

Google's Gmail, for example, evaluates ARC from intermediaries that have built a positive reputation by consistently adding accurate ARC headers. A new or unknown forwarder's ARC headers carry less weight until reputation is established.

ARC vs DMARC: Complementary, Not Competing

A common misconception is that ARC replaces DMARC. It does not.

DMARC is still evaluated first. ARC comes into play as a secondary signal when DMARC would otherwise fail due to forwarding. Receivers that support ARC may choose to override a DMARC fail if the ARC chain is valid and the forwarder is trusted.

Implementing ARC on Your Mail Server

If you operate a forwarding service, a mailing list, or a security gateway, implementing ARC makes you a better email citizen.

Postfix + OpenARC

# Install OpenARC
sudo apt install openarc

# /etc/opendmarc/openarc.conf
AuthservID        mail.example.com
PeerList          /etc/openarc/trusted-peers.txt
Syslog            yes
UMask             0002
UserID            openarc:openarc
Socket            inet:8891@localhost
SignHeaders       From,Date,Subject,To,Message-ID

milter Integration

# /etc/postfix/main.cf
milter_default_action = accept
smtpd_milters        = inet:localhost:8891, inet:localhost:8892
non_smtpd_milters    = inet:localhost:8892

Key Management

ARC uses the same RSA or Ed25519 key infrastructure as DKIM. Generate a separate keypair for ARC and publish the public key as a DNS TXT record:

arc._domainkey.example.com  TXT  "v=DKIM1; k=rsa; p=<public key>"

The selector (arc in this example) is referenced in the s= tag of your ARC-Message-Signature and ARC-Seal headers.

Reading ARC Headers for Debugging

When troubleshooting forwarding-related delivery issues, examining ARC headers in message source reveals exactly what happened at each hop.

# In Gmail: More options → Show original
# In Outlook: File → Properties → Internet headers

Look for lines starting with:
ARC-Authentication-Results:
ARC-Message-Signature:
ARC-Seal:

A healthy chain for a forwarded message looks like:

ARC-Seal: i=2; cv=pass; ...
ARC-Seal: i=1; cv=none; ...
ARC-Message-Signature: i=2; ...
ARC-Message-Signature: i=1; ...
ARC-Authentication-Results: i=2; spf=fail; dkim=fail; ...
ARC-Authentication-Results: i=1; spf=pass; dkim=pass; dmarc=pass; ...

The i=1 results showing pass for all three is the critical signal — it tells the final receiver that authentication was intact at origin.

Practical Scenarios

Mailing List Forwarding

Most modern mailing list software (Mailman 3, Sympa) supports ARC. Enable it in the configuration to preserve authentication results for subscribers whose providers enforce strict DMARC.

Office 365 and Google Workspace Inbound Rules

Both Microsoft and Google support ARC validation. If you route inbound mail through a third-party security gateway, verify that the gateway adds ARC headers — otherwise DMARC failures may still occur downstream.

University Email Forwarding

Many universities forward student email to personal addresses after graduation. ARC is essential for these setups because the forwarding IP is never in the original sender's SPF record.

Summary

ARC solves a real problem that DMARC alone cannot address: the authentication chain breaks when legitimate mail is forwarded. By having intermediaries cryptographically sign and preserve the authentication state they observed, ARC gives final receivers the information they need to trust forwarded mail from known-good forwarders.

For end-users and most domain owners, ARC is invisible infrastructure. For operators of mailing lists, forwarding services, and security gateways, implementing ARC is a professional obligation that protects the mail flow of everyone who relies on your infrastructure.