ARC — Email Authentication Across Forwarding
Why Email Forwarding Breaks Authentication
SPF verifies that the sending server is authorized for the domain in the email envelope. DKIM verifies message integrity using a digital signature. DMARC ties both protocols to the From header address. This trio works reliably — as long as the email travels directly from sender to recipient.
The problem arises when emails are forwarded. When a message passes through a mailing list, corporate forwarding rule, or alias service:
- SPF fails because the forwarding server delivers the message, and it is not listed in the original domain's SPF record (more on SPF limitations).
- DKIM fails if the forwarder modifies the message — adds a footer, changes the subject line, or appends headers.
- DMARC fails because neither SPF nor DKIM passes in alignment with the From header domain.
The result: a legitimate email lands in spam or gets rejected, even though the sender's authentication is configured correctly.
What Is ARC
ARC (Authenticated Received Chain) is a protocol defined in RFC 8617. It allows intermediary servers (forwarders, mailing lists) to preserve and sign authentication results from previous delivery steps.
ARC does not replace SPF, DKIM, or DMARC. It supplements them with a mechanism that tells the receiving server: "The original message passed authentication. Here is the evidence and my signature confirming the chain of custody."
The protocol has an Experimental status (RFC 8617 is categorized as "Experimental"), but in practice all major email providers support and use it.
How ARC Works
Each intermediary server that handles an email adds a set of three headers with a sequence number (instance number). The first intermediary adds a set with i=1, the second i=2, and so on. This creates a chain that documents the message's entire path.
The Three ARC Headers
| Header | Function |
|---|---|
ARC-Authentication-Results (AAR) |
Records authentication results (SPF, DKIM, DMARC) at the point when the message arrived at this server |
ARC-Message-Signature (AMS) |
Cryptographic signature of the message (headers + body) — same mechanism as a DKIM signature |
ARC-Seal (AS) |
Cryptographic signature of previous ARC headers and the chain validation status (cv= tag) |
Processing Flow
- The sender sends an email with valid SPF, DKIM, and DMARC.
- The email arrives at an intermediary server (mailing list, forwarder).
- The intermediary verifies authentication of the incoming message.
- It records the results in
ARC-Authentication-Results(i=1). - It makes any modifications to the message (adds a footer, changes the subject).
- It signs the modified message with its own key — creating
ARC-Message-Signature(i=1). - It seals the entire ARC chain with
ARC-Seal(i=1) including the tagcv=none(first link in the chain, nothing to validate) and sends the message onward. - The destination server receives the message with failed SPF/DKIM but a valid ARC chain.
- If the destination server trusts the sealer (ARC sealer), it can accept the email based on ARC.
Example ARC Headers
A simplified example of a message forwarded through a mailing list:
ARC-Seal: i=1; a=rsa-sha256; cv=none; d=list.example.org;
s=arc-selector; b=<signature>
ARC-Message-Signature: i=1; a=rsa-sha256; d=list.example.org;
s=arc-selector; h=from:to:subject:date; bh=<body hash>;
b=<signature>
ARC-Authentication-Results: i=1; list.example.org;
spf=pass smtp.mailfrom=example.com;
dkim=pass header.d=example.com;
dmarc=pass header.from=example.com
The cv= (chain validation) tag in ARC-Seal indicates the chain status:
| Value | Meaning |
|---|---|
cv=none |
First link in the chain (instance i=1) — no previous chain to validate |
cv=pass |
Previous ARC chain is valid |
cv=fail |
Previous ARC chain is invalid — the recipient should disregard ARC |
ARC and DMARC — How They Work Together
The DMARC specification (RFC 9871, formerly RFC 7489) does not explicitly mention ARC, but it defines the concept of "local policy override" — a receiving server can adjust message handling based on its own rules, even when the DMARC check fails.
In practice, this works as follows:
- An email arrives with a failed DMARC result (due to forwarding).
- The receiving server finds a valid ARC chain.
- The server verifies whether it trusts the sealer (ARC sealer).
- If it does, it applies a DMARC override and accepts the email despite the DMARC failure.
This behavior appears in DMARC reports as a pass result with an override flag (type local_policy or trusted_forwarder).
Who Supports ARC
On the Forwarder Side (ARC Sealer)
These services add ARC headers when forwarding:
- Google (Gmail, Google Workspace) — full support, adds ARC headers automatically
- Microsoft (Outlook.com, Exchange Online) — full support
- Yahoo — supported
- Mailman 3 — built-in support (configured in the
[ARC]section ofmailman.cfg) - Sympa — supported since version 6.2.38
On the Receiver Side (ARC Verifier)
These services evaluate the ARC chain upon receipt:
- Google — evaluates ARC and factors it into DMARC decisions
- Microsoft — supports configuring trusted ARC sealers in Microsoft 365
- Yahoo — evaluates ARC
- Fastmail — supported
Microsoft 365 allows administrators to explicitly add trusted ARC sealers in the email authentication settings. If you operate a forwarding service that sends emails to Microsoft 365, add your domain to the trusted ARC sealers list.
How to Deploy ARC on Your Own Server
ARC is primarily relevant for intermediary servers — forwarders and mailing lists. If you operate:
A Mailing List (Mailman, Sympa)
Update to a version with ARC support. Generate a key pair and publish the public key as a DNS TXT record, using the same format as DKIM:
arc-selector._domainkey.list.example.com IN TXT "v=DKIM1; k=rsa; p=<public key>"
ARC uses the same DNS record format as DKIM — it shares the key infrastructure.
A Forwarding Service (Postfix, Exim)
For Postfix, there is an integration via OpenARC — a milter (mail filter) that adds ARC headers:
apt install openarc
Configuration in /etc/openarc.conf:
Mode sv
Canonicalization relaxed/relaxed
Domain example.com
Selector arc-selector
KeyFile /etc/openarc/arc-selector.key
AuthservID example.com
Mode sv (sign and verify) means the server will add ARC headers when forwarding and verify them upon receipt.
Corporate Forwarding (Aliases)
If your domain forwards emails via aliases (e.g., info@example.com → personal mailbox), the forwarding server should add ARC headers. For standard forwarding using SRS (Sender Rewriting Scheme), ARC complements SRS — SRS addresses SPF, while ARC preserves the full authentication context.
ARC Limitations
Trust in the Sealer
ARC operates on a trust model. The receiving server must decide which ARC sealers it trusts. There is no centralized list of trusted sealers — each receiving server maintains its own. In practice, major providers (Google, Microsoft) trust each other's ARC signatures.
Experimental Status
RFC 8617 has an "Experimental" status, not "Standards Track." This means the specification may change in the future. In practice, however, ARC is widely deployed and change is unlikely.
ARC Does Not Solve Everything
ARC only helps with legitimate forwarding. If an attacker compromises a forwarding server and adds their own ARC headers, the recipient may accept the spoofed message if it trusts the compromised server. ARC does not replace proper configuration of SPF, DKIM, and DMARC.
ARC as Part of Email Authentication
ARC solves a real problem — email forwarding is common practice, and without ARC it causes delivery issues for legitimate messages. If your domains forward emails or you operate mailing lists, ARC is a relevant protocol worth deploying. For a foundation overview, see the complete guide to SPF, DKIM, and DMARC.
For domains that only send and receive emails (no forwarding), ARC requires no action — it operates on the intermediary and receiver side.
Verify that your core authentication protocols are configured correctly. Check your domain's security to see the status of your SPF, DKIM, and DMARC setup.
