What is ARC in email and how does it work? (Authenticated Received Chain explained)

dmarcspfdkimarc

If ARC still feels fuzzy, that is completely normal.

Most admins first meet ARC while debugging a very practical problem: "this message is legitimate, but DMARC failed after forwarding." ARC exists for exactly that kind of path.

ARC stands for Authenticated Received Chain. It is defined in RFC 8617 and is best thought of as a signed "chain of custody" for authentication results as a message passes through intermediaries.

That wording sounds formal, but the practical version is simple:

  • a server receives a message and checks SPF/DKIM/DMARC
  • it records what it observed
  • it cryptographically seals that observation
  • the next hop can validate that sealed history

So ARC does not replace SPF, DKIM, or DMARC. ARC preserves context when forwarding or list processing makes direct checks harder to interpret.

Why ARC is needed in real mail flow

Forwarding and mailing lists routinely break assumptions used by SPF and DKIM:

  • SPF is path-sensitive and often fails after forwarding
  • DKIM is content-sensitive and can fail after footers, subject tags, or MIME changes

When both happen, DMARC can fail even for legitimate traffic.

Google documents this directly in its forwarding guidance and sender requirements. That is why forwarders are encouraged to add ARC headers:

Yahoo similarly calls out ARC for forwarders in sender recommendations:

The 3 ARC headers you will see

An ARC "set" has three headers with the same instance number (i=):

  1. ARC-Authentication-Results (AAR)
  2. ARC-Message-Signature (AMS)
  3. ARC-Seal (AS)

You can read them as:

  • AAR: "here is what this hop observed"
  • AMS: "here is a signature over message/header context"
  • AS: "here is the seal that binds this ARC set into the chain"

The chain status is carried in cv= and is commonly none, pass, or fail.

Google has a concise ARC overview for admins here:

How ARC works hop by hop

Think about a message from alerts@example.com that gets forwarded by forwarder.example.net:

  1. Original message arrives at the forwarder.
  2. The forwarder evaluates authentication at that point in time.
  3. The forwarder adds an ARC set (i=1) with its observed results and seal.
  4. Message is relayed onward.
  5. Receiver validates the ARC chain and may use it as additional trust input.

If another intermediary adds ARC later, that becomes i=2, and so on.

Tiny header sketch:

ARC-Authentication-Results: i=1; ... spf=pass ... dkim=pass ...
ARC-Message-Signature: i=1; d=forwarder.example.net; s=arc1; ...
ARC-Seal: i=1; cv=none; d=forwarder.example.net; s=arc1; ...

ARC-Authentication-Results: i=2; ...
ARC-Message-Signature: i=2; d=next-hop.example.org; s=arc2; ...
ARC-Seal: i=2; cv=pass; d=next-hop.example.org; s=arc2; ...

What ARC can and cannot do

ARC can:

  • preserve prior authentication observations across forwarding hops
  • help receivers make better local decisions for indirect flows
  • reduce false positives when legitimate intermediaries modify mail

ARC cannot:

  • "force" DMARC to pass
  • prove a forwarder is trustworthy by itself
  • replace baseline SPF, DKIM, and DMARC hygiene

Google explicitly notes that ARC does not automatically authenticate a message on its own. Receivers still run their own checks.

Where ARC trust decisions happen

The important operational point: ARC is most useful when the receiver has a trust model for sealers.

Microsoft 365 makes this very concrete with trusted ARC sealers. Admins can configure domains they trust so preserved results can be used during evaluation in indirect flows:

That does not mean "trust everything with ARC." It means "trust specific sealers that are legitimate for your environment."

Practical checklist for domain admins

If mail forwarding/list traffic matters in your environment, this is the workable checklist:

  1. Keep DKIM aligned and resilient (because SPF often breaks first in forwarding).
  2. Ask forwarding/list services to ARC-seal outbound relayed mail.
  3. Validate headers during incidents (Authentication-Results, ARC-*, DKIM-Signature, Return-Path).
  4. Treat ARC as additional evidence, not an override switch.
  5. Build receiver-side trust carefully for known sealers.

If this is the first ARC deep-dive, pair it with:

Once this model clicks, ARC stops feeling like a mysterious "extra header" and starts behaving like what it is: signed transit context that makes forwarded mail easier to evaluate safely.

Previous Post