InboxRatio
Check your domain

Glossary term

ARC: how authentication results survive forwarding

What ARC is

ARC, short for Authenticated Received Chain and defined in RFC 8617, is a mechanism that lets each server handling a message in transit record the authentication results it observed and cryptographically seal that record for the next hop. The final receiver can then see that a message which now fails SPF and DKIM did pass both when a trusted intermediary first received it.

The problem ARC exists to solve is indirect mail flow. A message sent to a mailing list or a forwarding address gets re-sent by a server your SPF record never authorized, which fails SPF alignment by design. Mailing lists also routinely modify subject lines and footers, which breaks the DKIM signature. The result: a perfectly legitimate message arrives at its final destination failing every DMARC mechanism, and at an enforcement policy it gets quarantined or rejected. RFC 7960 catalogs these failures; ARC is the standards-track answer to them.

ARC does not authenticate the message itself for the final receiver. It authenticates a claim about the past: "when I received this, here is what SPF, DKIM and DMARC said." Whether to believe that claim is left entirely to the receiver's judgment of the sealing party.

How ARC differs from DKIM

ARC borrows DKIM's cryptography and DNS key mechanics, so the two are easy to conflate. They answer different questions.

A DKIM signature is the author's platform vouching for message integrity: this content, under this d= domain, has not changed since signing. It is evaluated once, against the message as it arrives, and DKIM alignment feeds it into DMARC.

An ARC seal is an intermediary vouching for its own observation: this is what the authentication picture looked like at my doorstep, before I touched the message. Each hop adds its own seal, building a chain in which every participant is identified by its own domain and key.

The consequence: DKIM failing is evidence about the message, while ARC is evidence about the journey. A receiver that trusts the sealing forwarder can use the chain to override a DMARC failure it knows the forwarder caused. A receiver that has never heard of the sealer can ignore the chain completely — and RFC 8617 explicitly blesses both choices.

How ARC works

Each intermediary that participates adds three headers, together forming one "ARC set" with an instance number i= (1 for the first hop, counting upward, with 50 as the protocol maximum):

ARC-Authentication-Results: i=1; mx.example.org; spf=pass ...; dkim=pass ...
ARC-Message-Signature: i=1; a=rsa-sha256; d=example.org; s=arc; ...
ARC-Seal: i=1; a=rsa-sha256; cv=none; d=example.org; s=arc; ...

ARC-Authentication-Results (AAR) is a snapshot of the standard Authentication-Results evaluation the hop performed on receipt — the SPF, DKIM and DMARC verdicts before any modification.

ARC-Message-Signature (AMS) is structurally a DKIM signature over the message as this hop sends it onward, so the next hop can verify nothing changed in transit from this sealer.

ARC-Seal (AS) signs the ARC header sets themselves, chaining each instance to all previous ones. Its cv= tag states the sealer's verdict on the chain so far: none for the first participant, pass if the existing chain validated, fail if it did not. A chain containing a failed seal is dead; nothing downstream can resurrect it.

Keys are published in DNS exactly like DKIM keys, at {selector}._domainkey.{domain}, so the same DKIM checker mechanics apply. On the receiving end, a validated chain gives the receiver a trustworthy record of instance 1's AAR; whether that record overrides a DMARC failure is local policy. In practice you see the outcome in the receiver's own Authentication-Results header as arc=pass, which the email header analyzer will surface.

ARC and your deliverability

For most senders, ARC is not something you configure — it is something that happens to your mail, and understanding it changes how you read failure data.

First, it explains survivable forwarding. The Gmail sender guidelines ask forwarders and mailing lists to add ARC headers precisely so that legitimate forwarded mail is not collateral damage of DMARC enforcement. When your DMARC aggregate reports show a source failing both mechanisms yet receiving a none disposition at a major provider, a validated ARC chain is a common reason: the receiver believed the forwarder's testimony about your original pass.

Second, it lowers the cost of enforcement. The historical argument against p=reject was breakage of mailing-list mail; ARC adoption at the large providers has shrunk exactly that category. Senders holding DMARC at p=none out of forwarding fear are often solving a smaller problem than they think — check the reports through a DMARC checker lens before deciding.

Third, if you operate forwarding infrastructure (a mailing list, an alias service, a ticketing system that re-emits inbound mail), sealing with ARC is how you stop destroying your users' authentication. That, plus your own return-path hygiene, determines whether downstream receivers can distinguish your forwarding from spoofing.

Limitations and failure modes

ARC is testimony, not proof. Any server can add syntactically valid ARC headers claiming the message passed everything; spammers do. The chain only helps when the receiver trusts the sealing domain, and receivers build that trust from their own traffic history. There is no public registry of trusted sealers, and arc=pass on a chain sealed by an unknown domain moves nothing.

A broken chain is unrecoverable. One hop that modifies the message without resealing, or seals with cv=fail, ends the chain's usefulness permanently. Long forwarding paths through mixed infrastructure fail more often than the protocol diagrams suggest.

It rescues nothing at uninvolved receivers. Smaller mailbox providers that validate DMARC but not ARC will still reject forwarded mail that fails alignment. ARC adoption is strongest exactly where the volume is: the large consumer providers.

Misreading arc=fail as your problem. An ARC chain failing usually indicts the intermediary, not the origin. Your authentication posture is what instance 1 recorded; debug that with your own direct sends before touching anything based on forwarded-path failures.

Sealing without observing. A forwarder that adds ARC headers but records an AAR it never actually evaluated is publishing fiction under its own signature. Receivers score sealers on the accuracy of their testimony, so sloppy sealing burns the forwarder's own domain reputation as a witness.

Treating ARC as a sender-side fix. There is no DNS record a message author publishes to "enable ARC" for their mail. If forwarding breaks your authentication, your levers remain aligned DKIM (which survives benign forwarding) and enforcement decisions informed by report data — ARC is the intermediaries' lever.

Related terms

DMARC, DKIM, DKIM alignment, SPF alignment, SPF record, DMARC aggregate reports, return-path, domain reputation.

Frequently asked questions

Do I need to set up ARC for my domain? As a message author, no — ARC is added by servers that handle mail in transit, not by the origin. You only implement ARC if you operate forwarding or mailing-list infrastructure that re-sends other people's mail.

Does ARC replace SPF, DKIM or DMARC? No. It presupposes them: an ARC chain is a record of SPF, DKIM and DMARC results at earlier hops. A message with no authentication to begin with gains nothing from being sealed.

What does arc=pass in my headers mean? The receiver validated an unbroken chain of seals and can therefore trust the recorded authentication results from the first hop. It does not by itself mean the message was treated as authenticated — that depends on whether the receiver trusts the sealers.

Why did my forwarded mail deliver despite failing DMARC? Very likely ARC: the forwarder sealed the message, the receiver validated the chain and trusted the forwarder's record of your original SPF and DKIM passes, and applied a local override instead of your requested policy.

Can spammers abuse ARC to bypass DMARC? They can add ARC headers, but headers alone move nothing. An override requires the receiver to trust the sealing domain, and that trust is earned through observed sealing accuracy over time. Forged chains from unknown sealers are ignored.

Is ARC related to DKIM2? The IETF work on a revised DKIM specification addresses some of the same indirect-flow damage from a different angle, at the signature layer itself. ARC is the deployed, receiver-side mechanism today; follow the standards work before assuming anything replaces it.

Next time a forwarded message of yours lands correctly against the odds, pull its headers into the email header analyzer and read the ARC sets bottom to top. Watching instance 1 preserve your original pass is the fastest way to make this mechanism concrete.

Sources