ARC (Authenticated Received Chain, RFC 8617) is a protocol that lets each server handling a message in transit record and cryptographically sign the authentication results it observed, so when a mailing list or forwarder inevitably breaks SPF and DKIM, the final receiver can still see the message authenticated cleanly at the start of its journey. It matters in exactly one scenario: indirect mail flows. Direct senders don't implement ARC; forwarders and mailbox providers do.
The problem ARC solves
Forwarding breaks authentication in predictable ways:
| Hop behavior | Effect |
|---|---|
| Forwarder resends from its own IP | SPF fails (IP not in origin domain's record) |
| Mailing list adds a footer or subject tag | DKIM fails, see body hash did not verify |
| Both of the above | DMARC fails despite a legitimate origin |
At p=reject, that legitimate-but-modified message bounces. This is the classic mailing-list problem that made early DMARC enforcement painful for discussion lists. ARC gives the receiver a trustworthy record that the message passed everything before the list touched it.
How the chain works
Each intermediary adds three headers, stamped with an instance number i= that increments per hop. RFC 8617 allows i=1 to i=50, so a message can carry at most 50 ARC sets:
ARC-Authentication-Results: i=1; mx.google.com;
spf=pass smtp.mailfrom=yourdomain.com;
dkim=pass header.d=yourdomain.com; dmarc=pass
ARC-Message-Signature: i=1; a=rsa-sha256; d=lists.example.org; s=arc2026;
h=from:to:subject:date; bh=...; b=...
ARC-Seal: i=1; a=rsa-sha256; cv=none; d=lists.example.org; s=arc2026; b=...
| Header | What it carries |
|---|---|
ARC-Authentication-Results (AAR) | The SPF/DKIM/DMARC results this hop observed on arrival |
ARC-Message-Signature (AMS) | A DKIM-like signature over the message as this hop sent it |
ARC-Seal (AS) | A signature over the ARC headers themselves, chaining all prior hops; cv= records whether the existing chain validated (none for the first hop, then pass/fail) |
A receiver validating the chain can walk it back hop by hop: who handled the message, what each hop saw, and whether anyone tampered with the record. One cv=fail and the chain is dead, it can't be repaired downstream.
The signatures follow DKIM's key rules: RFC 8301 requires RSA keys of at least 1024 bits and recommends 2048, so an intermediary sealing with a short legacy key weakens its whole chain.
What receivers do with it
ARC doesn't force any outcome. It licenses a local override: "this message fails DMARC now, but a sealer I trust attests it passed at origin, deliver it anyway." Gmail and Microsoft 365 both seal and evaluate ARC; Gmail's sender guidelines explicitly instruct forwarding services to add ARC headers.
Trust is the load-bearing part. A receiver only honors seals from intermediaries with established reputations. Google, Microsoft, major list operators. A spammer sealing their own chain attests to nothing a receiver believes.
Do you need to do anything?
| You are | ARC action |
|---|---|
| A normal sender (marketing, transactional, cold outreach) | Nothing, get SPF, DKIM, and DMARC right instead |
| Running a mailing list (Mailman 3, Sympa) | Enable ARC sealing; it's built in |
| Operating a forwarding service | Seal with ARC per Gmail/Yahoo forwarding guidance |
| Running inbound filtering/gateway MTAs | Seal, so downstream servers can trust your handling |
| Debugging "my forwarded mail bounces at p=reject" | Check whether the forwarder seals ARC; if not, that's the gap |
For senders, the practical takeaway is diagnostic: when DMARC reports show failures from IPs you don't recognize, check the receiver's Authentication-Results for arc=pass, it usually means legitimate forwarding, not spoofing, and no action is needed on your side.
ARC also can't rescue mail that failed authentication at origin. If your own SPF or DKIM is broken, every hop just records the failure, fix the source, not the chain.
How to see ARC headers on a real message
You don't need special tools. In Gmail on a computer, open the message, click More next to Reply, and choose Show original (Google's steps). The full header opens in a new window.
Read it from the top down. The newest hop sits highest, so the set with the largest i= number is the last intermediary that touched the message. Then find the receiver's own Authentication-Results line and look for the arc= result. RFC 8617 registers exactly three values for it:
| Result | What it means | What to do |
|---|---|---|
arc=none | The message arrived with no ARC chain | Normal for direct mail from your own server |
arc=pass | Every seal in the chain validated | The forwarder vouched for the original results |
arc=fail | A seal or signature did not validate | The chain is dead; the receiver falls back to plain DMARC |
The cv= tag inside each ARC-Seal uses the same three words. The first hop always writes cv=none, because no chain existed before it. Every later hop writes pass or fail for the chain it received.
How ARC shows up in your DMARC reports
When a receiver delivers a message that failed DMARC because it trusts the ARC chain, it should say so in the aggregate report. RFC 7489 gives receivers six override reasons to choose from: forwarded, sampled_out, trusted_forwarder, mailing_list, local_policy and other.
So if your reports show DMARC failures with an override reason of trusted_forwarder or mailing_list attached, that is ARC (or a similar local rule) doing its job. Those rows are not spoofing and need no fix on your side. Rows that fail DMARC with no override from an IP you don't recognize are the ones to investigate. Reports arrive once a day by default (RFC 7489 sets the ri interval to 86400 seconds), so a forwarding change you make today shows up in tomorrow's reports, not this afternoon's. Our guide to reading DMARC aggregate reports covers where these fields sit in the XML.
How BulkEmailSetup helps
We make sure mail leaving your dedicated SMTP server passes SPF, DKIM, and DMARC at hop zero, which is what ARC chains end up attesting to when your mail gets forwarded. Authentication, PTR, and MTA-STS are configured and verified on every server; see pricing.
Frequently asked questions
What is ARC in email?
ARC (Authenticated Received Chain, RFC 8617) lets each intermediary that handles a message record the authentication results it saw and sign that record. Receivers can then see the message passed SPF/DKIM/DMARC before a forwarder or mailing list broke those checks.
Does ARC replace DMARC?
No. ARC is a supplement: it gives receivers evidence to override a DMARC failure caused by legitimate forwarding. DMARC remains the policy layer; ARC informs the receiver's local decision.
Do I need to set up ARC as a normal sender?
No. ARC is implemented by intermediaries, mailing lists, forwarding services, security gateways, and consumed by receivers. Direct senders only need SPF, DKIM, and DMARC.
Does Gmail use ARC?
Yes. Gmail both seals outgoing forwarded mail with ARC and evaluates ARC chains on inbound mail, and Google's forwarding guidelines tell intermediaries to add ARC headers. Microsoft 365 does the same.
Can ARC be abused by spammers?
An ARC chain is only as trustworthy as the sealers in it, so receivers only honor chains from intermediaries they trust. A spammer sealing their own mail gains nothing, the receiver ignores seals from unknown domains.
