ARC (Authenticated Received Chain) is an email authentication standard that lets an intermediary, such as a mailing list or forwarding service, record the SPF, DKIM, and DMARC results it saw before it modified or relayed a message. It exists because forwarding routinely breaks SPF and DKIM, which causes legitimate mail to fail DMARC at the final destination. ARC does not replace DMARC; it gives the final receiver a cryptographically signed record of what authentication looked like earlier in the delivery path, so a trusted forwarder's message can survive a strict policy.
Reads public DNS only. Nothing is stored unless you save the domain to an account.
The problem ARC solves
Email authentication was designed for direct delivery: the sending server connects to the receiving server, and both SPF and DKIM are evaluated against that single hop. Real mail flows are messier. Messages get forwarded to a new address, rewritten by a mailing list, or relayed through a security gateway. Each of those intermediaries can break authentication in ways the original sender never intended.
- SPF checks the connecting IP against the domain's authorized senders. When a forwarder relays the message, the connecting IP is now the forwarder, not the original sender, so SPF fails. This is covered in depth in why email forwarding breaks SPF.
- DKIM signs specific headers and the message body. A mailing list that appends a footer, rewrites the subject line, or changes the encoding invalidates the DKIM body hash, so the signature no longer verifies. That failure looks identical to a DKIM body hash mismatch caused by any other in-transit change.
When both SPF and DKIM fail at the final hop, DMARC has nothing to align, so the message fails. If the sender publishes p=reject, that forwarded message is rejected or quarantined even though it was perfectly legitimate. ARC was created to close this gap.
What ARC actually does
ARC is defined in RFC 8617, published in July 2019 with Experimental status. The core idea is simple: each ARC participant that handles a message records the authentication results it observed and cryptographically signs both that record and the state of any earlier records. The result is an ordered, tamper-evident chain of custody.
When a receiver at the end of the path validates the chain, it can read the authentication results as seen by the first ARC participant, before any forwarding or list processing happened. If the sender's DKIM passed when the message first entered a trusted forwarder, the final receiver can see that, even though the signature no longer verifies after the footer was added.
ARC never authenticates the original author on its own. It authenticates the intermediaries and preserves the evidence they collected. Trust still has to be earned: a receiver only benefits from ARC if it trusts the intermediaries that sealed the chain.
The three ARC header fields
Each ARC participant adds an ARC Set: three header fields that all share the same instance number, carried in an i= tag. The first intermediary uses i=1, the second i=2, and so on. RFC 8617 caps the instance value at 50, so a chain can hold at most 50 ARC Sets before receivers stop processing it.
| Header field | Abbreviation | Purpose |
|---|---|---|
ARC-Authentication-Results | AAR | A frozen snapshot of the SPF, DKIM, and DMARC results this hop observed |
ARC-Message-Signature | AMS | A DKIM-like signature over the message headers and body as this hop saw them |
ARC-Seal | AS | A signature that binds the current AAR and AMS together with all previous ARC Sets |
ARC-Authentication-Results (AAR)
The AAR is essentially a copy of the standard Authentication-Results header, preserved under the ARC namespace so later hops cannot quietly discard it. It states what the intermediary saw: for example that spf=pass and dkim=pass for the original sending domain. If you already know how to read a normal results header, the AAR will look familiar. The guide on how to read the Authentication-Results header applies directly.
ARC-Message-Signature (AMS)
The AMS works like a DKIM signature. It signs the message headers and body as they exist at this hop, using the intermediary's own domain and selector. Because it captures the message state at the moment of sealing, a later validator can confirm that the body has not changed since this intermediary handled it. The AMS uses the same tag structure as DKIM, including d= for the signing domain and s= for the selector.
ARC-Seal (AS)
The ARC-Seal is what makes the chain a chain. It signs the ARC-Seal, ARC-Message-Signature, and ARC-Authentication-Results header fields of all instances up to and including the current one. That is why no intermediary can remove or reorder earlier ARC Sets without breaking the seal.
The ARC-Seal carries a cv= (chain validation) tag that records the outcome of validating the chain that already existed when this hop received the message:
cv=none: there was no prior ARC chain. This is required for the first set,i=1.cv=pass: the existing chain validated successfully. Required for every set whereiis greater than 1.cv=fail: the existing chain failed validation.
Two rules keep a valid chain honest. The cv= value at i=1 must be none, and it must be pass for every later set, so a passing chain never contains cv=fail anywhere. When an intermediary receives a message whose inbound chain is already broken, it can still add a final ARC Set stamped cv=fail to record the failure. That sealing set is scoped to cover only its own headers, not the broken sets beneath it, and it marks the chain as dead: no participant adds further sets on top of a cv=fail, and downstream receivers treat the chain as untrusted.
How a receiver uses ARC
At the final destination, the receiving mail server runs DMARC as usual. If SPF and DKIM both fail and DMARC would otherwise fail, the receiver can then look at the ARC chain as an additional signal. The process looks like this:
- Validate the full ARC chain by checking each ARC-Seal in order and confirming every
cv=value follows the rules above. - If the chain validates, read the earliest AAR to see the original SPF, DKIM, and DMARC results.
- Decide whether the intermediaries that sealed the chain are trusted. A validated chain from an unknown forwarder is worth little; a validated chain from a known, reputable forwarder is worth a lot.
- Optionally apply a local policy override: deliver the message despite the DMARC failure because the ARC evidence shows it authenticated correctly before a trusted forwarder modified it.
This is why ARC is a local policy tool, not an automatic override. The specification deliberately leaves the trust decision to the receiver. Large providers implement this through trusted-sealer lists. Google Workspace and Microsoft 365 both let administrators designate specific ARC sealing domains as trusted, and only chains sealed by those domains influence the delivery decision. Without a trust relationship, a validating chain is recorded but does not change the outcome.
ARC and DMARC together
ARC is best understood as a repair layer for DMARC's blind spot around forwarding. DMARC still governs the policy: whether unauthenticated mail should be delivered, quarantined, or rejected, and where reports are sent. Nothing about deploying ARC changes your DMARC record or your move from p=none toward p=reject.
| Layer | What it checks | What breaks it | What ARC adds |
|---|---|---|---|
| SPF | Connecting IP vs authorized senders | Forwarding changes the IP | Preserves the original spf=pass |
| DKIM | Signature over headers and body | List footers and header rewrites | Preserves the original dkim=pass |
| DMARC | Alignment of SPF or DKIM with the From domain | Both underlying checks failing | Supplies evidence for a policy override |
For a domain owner, ARC is mostly something your forwarders and receivers implement, not something you configure on your own domain in the way you set up SPF, DKIM, and DMARC. You still publish those three records correctly, because ARC only preserves results that existed in the first place. If your DKIM signature was invalid before forwarding, ARC faithfully records that failure and nothing improves.
Where ARC helps and where it does not
ARC materially reduces false DMARC failures for messages that pass through mailing lists, forwarding services, and gateway products that participate in the chain. It is one of the reasons a member of a discussion list can still receive posts from senders that publish p=reject.
ARC does not help when no intermediary in the path implements it, when the receiver does not trust the sealer, or when the message was never authenticated to begin with. It is also not an anti-spoofing control on its own. A message forged from scratch has no legitimate ARC chain, and a chain sealed by an untrusted party carries no weight. If your goal is to stop spoofing of your domain, that still comes down to publishing and enforcing DMARC.
Frequently asked questions
Do I need to configure ARC on my sending domain?
Generally no. ARC is applied by intermediaries that forward or process your mail, and it is consumed by the receiving servers at the destination. Your job as a domain owner is to make sure SPF, DKIM, and DMARC are correct at the source, because ARC only preserves authentication results that already passed.
How is ARC-Message-Signature different from a normal DKIM signature?
Both are cryptographic signatures over message content using a domain and selector, but a DKIM signature claims responsibility for the message as the author or sender. An ARC-Message-Signature documents the message state at an intermediary hop and is bound into the ARC chain by the ARC-Seal, so it survives even after later hops modify the message.
Does a valid ARC chain guarantee my forwarded mail is delivered?
No. A valid chain only gives the receiver evidence it can choose to act on. Delivery depends on whether the receiver trusts the intermediaries that sealed the chain. Providers such as Google and Microsoft only honor ARC from sealers an administrator has explicitly marked as trusted.
Can ARC be used to fake authentication results?
An attacker can add ARC headers claiming anything, but the seal is only meaningful if the sealing domain is one the receiver trusts. An untrusted or invalid chain carries no weight, so ARC does not create a new spoofing path as long as receivers apply trust properly.
Forwarding and mailing lists are the most common reason legitimate mail fails DMARC, and the underlying cause is almost always an SPF or DKIM problem at the source. Run a free scan with SPFWise to confirm your SPF, DKIM, and DMARC records are aligned and valid before a forwarder ever touches your mail.