Authentication

ARCAuthenticated Received Chain

Definition

ARC (Authenticated Received Chain) is an email-authentication standard, defined in RFC 8617, that preserves the original SPF and DKIM results when a message is forwarded. Forwarding and mailing lists usually break those checks, which can sink a message at a strict DMARC gate. ARC lets each hop record and cryptographically seal what it saw, so the final receiver can trust the chain.

  • It rescues legitimate mail that loses SPF/DKIM during forwarding
  • Each intermediary adds a sealed snapshot of the results it observed
  • A receiver can honour a trusted ARC chain instead of failing DMARC
  • ARC is advisory: it never forces delivery, it informs the decision
At a glance
Defined in RFC 8617 (2019)
Header fields AAR · AMS · AS
Instance tag i=1 to i=50
Chain status cv=none · pass · fail
Builds on DKIM-style signing
Used by Gmail, Microsoft 365, Yahoo

The forwarding problem ARC solves

When a message is forwarded through a mailing list, an alumni address, or a security gateway, two things tend to happen. The new server sends from its own IP, so the original SPF authorisation no longer matches. And the intermediary often rewrites the subject or footer, which breaks the DKIM signature that covered the body. With both broken, a strict DMARC policy of p=reject tells the final receiver to throw the message away, even though it was perfectly genuine when it left the sender.

ARC fixes this by letting each handler in the path record the authentication results it saw before it touched anything, then sign that record. The final receiver reads the chain, decides whether it trusts the intermediaries, and can choose to deliver mail that would otherwise fail DMARC outright.

The three ARC header fields

Every ARC participant adds a numbered ARC set of three headers, tagged with an instance number (i=1 for the first hop, incrementing up to a maximum of 50):

  • ARC-Authentication-Results (AAR): a frozen copy of the SPF, DKIM, and DMARC results that hop observed on arrival.
  • ARC-Message-Signature (AMS): a DKIM-style signature over the message as that hop saw it, so later receivers can confirm what was forwarded.
  • ARC-Seal (AS): a signature that locks the whole chain together, including every earlier ARC set, and carries the chain-validation verdict.

The seal’s cv= tag reports the state of the chain so far: cv=none on the first hop (no prior chain), cv=pass when every earlier set validated, and cv=fail the moment any link is broken. Once a chain fails it cannot recover.

A first-hop ARC set: AAR, AMS, and AS sharing instance i=1 
ARC-Seal: i=1; a=rsa-sha256; t=1718000000; cv=none;
        d=lists.example.org; s=arc2026; b=Lk9c...AB==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;
        d=lists.example.org; s=arc2026; h=from:to:subject; b=h7Qy...9d==
ARC-Authentication-Results: i=1; lists.example.org;
        spf=pass smtp.mailfrom=sender.com;
        dkim=pass header.d=sender.com; dmarc=pass header.from=sender.com

How receivers use ARC, and its limits

ARC is strictly advisory. It never overrides a sender’s DMARC policy on its own and it never guarantees delivery. What it does is hand the final receiver extra evidence: “this message passed authentication when it entered the chain, and a server I trust is vouching for that.” A receiver that trusts the sealing intermediary can then deliver mail that current SPF and DKIM would otherwise sink.

That trust is the catch. A receiver only honours an ARC chain from intermediaries it has reason to believe, so a forged seal from an unknown host buys nothing. ARC also doesn’t replace SPF, DKIM, or DMARC; it sits alongside them to handle the specific case of authenticated mail that gets modified in transit. If you run a mailing list or forwarding service, sealing with ARC is how you stop breaking your subscribers’ DMARC.

How ARC preserves authentication through a forward

Sender mails a message that passes SPF and DKIM
A mailing list receives it and records the passing results in an ARC set
The list rewrites the footer and re-sends from its own IP
SPF now fails DKIM signature broken
The final receiver re-checks SPF and DKIM, which fail, and would normally apply DMARC
It validates the ARC chain and sees the message passed at origin
Trusting the chain, it delivers the message instead of rejecting it

ARC vs DKIM vs DMARC

ARC DKIM DMARC
What it does Preserves results across forwarding Signs each message Sets the policy on failure
Survives forwarding? Yes, that is its job Often breaks Inherits the broken result
Forces delivery? No, advisory only No Yes, with p=reject
Who adds it Each intermediary hop The original sender The domain owner

Common mistakes

Assuming ARC overrides DMARC
ARC never forces a message through. It only gives the receiver evidence to make a better decision; the receiver still chooses whether to trust the chain and deliver.
Expecting ARC from unknown senders to count
A receiver honours ARC only from intermediaries it trusts. A sealed chain from a host with no reputation carries no weight, so ARC is not a delivery guarantee.
Running a mailing list without sealing
If your list rewrites messages but never adds ARC, you break SPF and DKIM for every subscriber whose domain publishes p=reject, and their mail to your list members gets bounced.

Frequently asked questions

Does ARC replace SPF, DKIM, or DMARC?
No. ARC works alongside them. SPF, DKIM, and DMARC still run as normal; ARC simply preserves their original results across forwarding hops so a receiver can recognise mail that was genuine before it was modified in transit.
Do I need to set up ARC?
Most ordinary senders do not. ARC matters mainly for intermediaries: mailing lists, forwarders, and security gateways that modify messages in transit. Sealing with ARC stops them from breaking DMARC for the people whose mail they relay. Major receivers like Gmail and Microsoft 365 already validate ARC on inbound mail.
What does cv=fail mean in an ARC seal?
It means the chain validation failed at that hop, usually because an earlier ARC set was altered or a signature no longer verifies. Once a chain reports cv=fail it cannot recover, and the receiver treats the chain as untrustworthy.
Reviewed by Jennifer Jackson, Email Deliverability Analyst · June 2026 ← Back to glossary