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:
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.
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 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.
