ARC: Authenticated Received Chain explained

20 June 2026 · 12 min read

When forwarding breaks authentication, and why that matters

Email authentication has a blind spot that catches almost everyone the first time they meet it. You set up SPF, DKIM and DMARC correctly. Your mail is signed, aligned and passing. Then a recipient forwards one of your messages to another address, or a member subscribes to a mailing list, and suddenly that perfectly authenticated message arrives looking like a forgery. The receiving server checks SPF, sees an unexpected sending IP, and fails it. The DMARC verdict flips from pass to fail. If your policy is p=reject, a legitimate message gets bounced or binned, and you never sent anything wrong.

This is not a bug in your setup. It is a structural limitation of how SPF and DKIM behave when a message changes hands in transit. ARC, the Authenticated Received Chain, exists to repair exactly this scenario. It is a way for an intermediary, a forwarder or a mailing list, to vouch for the authentication results it saw when the message first arrived, and to seal that vouching cryptographically so the next hop can trust it.

ARC does not replace SPF, DKIM or DMARC. It sits alongside them as a supporting mechanism, defined in RFC 8617. It is the part of the standards stack that most people never configure directly, because it is the receiving and forwarding infrastructure that implements it, but understanding it explains a whole category of "my mail passed everywhere except here" mysteries. This article walks through why forwarding breaks authentication in the first place, what ARC actually adds, how the chain is built and validated header by header, and where it genuinely helps versus where people overestimate it.

Why SPF and DKIM fall apart in transit

To see the problem ARC solves, you have to look at what happens to a message between the original sender and the final inbox when an intermediary sits in the middle.

Start with SPF. SPF authorises the IP address that connects to the receiving server against the SPF record of the envelope-from (Return-Path) domain. It is tied to the connecting IP for that specific SMTP conversation. When a message is forwarded, the forwarding server becomes the new connecting IP. The original sender's SPF record almost never lists that forwarder's IP, because the sender has no idea their mail will be relayed through it. So SPF, evaluated at the final destination, fails. There is nothing the original sender can do about this, short of listing the entire internet, which would defeat the purpose. SPF simply does not survive a change of relay. If you want a refresher on how SPF authorisation works, the SPF checker and our guide on DMARC alignment cover the mechanics.

Now DKIM, which is more robust but still fragile. DKIM signs selected headers and the message body with a private key, and the receiver verifies the signature against a public key in DNS. Because the signature travels inside the message, it can survive a simple relay that does not touch the signed content. That is why forwarded mail often still passes DKIM where it fails SPF. But mailing lists, and many forwarders, modify the message. They add a [list-name] prefix to the Subject. They append an unsubscribe footer to the body. They strip or rewrite headers. Any change to a signed header or to the body breaks the cryptographic hash, and the DKIM signature no longer verifies. DKIM was valid when the message left the sender, and is now invalid through no fault of the signature itself.

Put the two together against DMARC. DMARC passes only if at least one of SPF or DKIM both passes and aligns with the From domain. After a mailing list has rewritten the Subject and the message has been relayed through a new IP:

• SPF fails, because the relay IP is not in the original sender's record.
• DKIM fails, because the list edited a signed part of the message.
• Therefore DMARC fails.

The message is from a real sender, it was authenticated correctly at origin, and it still gets a DMARC fail at the destination. For senders on p=none this only shows up as noise in reports. For senders on p=quarantine or p=reject, it means genuine mail lands in spam or is rejected outright. This is the precise failure mode that pushed many organisations to keep their DMARC policy weak for years, afraid that enforcement would break list traffic and forwarded mail.

What ARC actually adds

ARC's core idea is simple to state. If an intermediary can record the authentication results it observed, sign that record, and pass it forward in a tamper-evident way, then a later receiver can choose to trust the original results even after SPF and DKIM have broken in transit.

Think of it as a chain of custody for authentication. When a message arrives at an ARC-aware intermediary, that intermediary writes down three things: what the authentication results looked like on arrival, a snapshot of the message state, and a cryptographic signature over both. It stamps these into the message as a set of headers. If the message passes through several intermediaries, each one adds its own stamped set, and each new set also signs over all the previous ones. The result is an ordered, sealed chain. The final receiver can read the chain, verify that no link was tampered with, and see what the very first ARC-aware hop reported about the original SPF and DKIM results.

Crucially, ARC is informational, not authoritative. It does not force any receiver to deliver a message. It gives the final receiver a trustworthy account of "here is what authentication looked like before the intermediaries got involved, and here is who is vouching for that". The receiver still decides what to do with that information, based on whether it trusts the intermediaries in the chain. A reputable forwarder's ARC seal is worth a great deal; an unknown one's is worth very little. ARC supplies the evidence; local policy and reputation supply the trust.

The three ARC header fields

ARC is implemented through three header fields, and every intermediary that participates adds one of each, grouped together as an ARC set and tagged with an instance number i=. The first intermediary uses i=1, the second i=2, and so on. Understanding the three fields is the key to reading a chain.

ARC-Authentication-Results (AAR)

The ARC-Authentication-Results header is essentially a frozen snapshot of the ordinary Authentication-Results header that the intermediary generated when the message arrived. It records the SPF, DKIM and DMARC verdicts as that hop saw them. A simplified example:

ARC-Authentication-Results: i=1; mx.example-list.org;
  spf=pass smtp.mailfrom=news@yourbrand.com;
  dkim=pass header.d=yourbrand.com;
  dmarc=pass header.from=yourbrand.com

This is the substance of what ARC preserves: the original passing results, captured before the list rewrote the Subject and broke them. Without ARC, that verdict would be lost the moment the message was modified.

ARC-Message-Signature (AMS)

The ARC-Message-Signature is, in structure, almost identical to a DKIM signature. It signs the message headers and body as they exist at that intermediary, using the intermediary's own key and selector published in DNS. It captures the state of the message as the intermediary forwards it onward. Because each intermediary signs the message as it leaves their hands, a later receiver can confirm that the body and headers were not altered after that specific hop sealed them.

The AMS is what lets a receiver detect tampering between intermediaries, as opposed to the legitimate modifications an intermediary itself made.

ARC-Seal (AS)

The ARC-Seal is the link that binds the chain together. It is a signature too, but instead of signing the message body, it signs over the ARC header fields themselves: the AAR, the AMS, and the AS of the current set, plus all the ARC sets that came before it. This is what makes the chain ordered and tamper-evident as a whole. If anyone removed, reordered or edited an earlier ARC set, the seal over the chain would no longer validate.

Each ARC-Seal also carries a chain validation status, cv=, which records the state of the chain as that intermediary saw it:

• cv=none means this is the first ARC set; there was no prior chain.
• cv=pass means the chain up to this point validated correctly.
• cv=fail means the chain was already broken when this intermediary received it.

A receiver reads the cv= value on the most recent seal, then independently re-verifies, to decide whether the whole chain can be trusted.

A worked example: a message through a mailing list

Walk through a concrete journey. Sarah at yourbrand.com posts to an announcements list run at example-list.org, which fans the message out to a few hundred subscribers, one of whom reads their mail at a large mailbox provider that enforces DMARC.

Step one, original send. Sarah's mail server sends the message. It is SPF-aligned and DKIM-signed for yourbrand.com. At this point, with no intermediary yet, the message would pass DMARC anywhere. You can confirm a domain's own setup with the DMARC checker and DKIM checker.

Step two, the list receives it. The list server at example-list.org accepts the message. On arrival it runs normal authentication and sees spf=pass, dkim=pass, dmarc=pass for yourbrand.com. Being ARC-aware, it now adds an ARC set with i=1:

• AAR i=1 records those passing results.
• AMS i=1 signs the message as received.
• AS i=1 seals the set with cv=none, because it is the first link.

Step three, the list modifies and forwards. The list rewrites the Subject to [Announce] ... and appends an unsubscribe footer. These edits break the original DKIM signature and, because the message now leaves from the list's IP, SPF for yourbrand.com will fail at the next hop. The message goes out to subscribers carrying both the now-broken original authentication and the intact ARC set.

Step four, the subscriber's provider receives it. The destination provider runs ordinary authentication and gets the bad news: SPF fail, DKIM fail, DMARC fail for yourbrand.com. Under plain DMARC this message is a candidate for the spam folder or rejection. But the provider is ARC-aware. It reads the ARC chain, verifies the AS and AMS signatures against example-list.org's published keys, and confirms cv=pass for the chain. It now has trustworthy evidence that when the message first arrived at the list, it genuinely passed DMARC for yourbrand.com. If the provider trusts example-list.org as a forwarder, it can use that evidence to override the local DMARC failure and deliver the message normally.

The message is delivered, the sender's reputation is not dinged, and no one had to weaken their DMARC policy to make list traffic work. That is the entire value proposition of ARC in one journey.

Where ARC helps, and where it does not

ARC is genuinely useful, but it is easy to overestimate. Be precise about its scope.

It helps with indirect mail flows. Anything where a legitimate message changes hands and gets modified: traditional mailing lists, discussion lists, role-account forwarding (info@ redirecting to a personal mailbox), university and alumni forwarding addresses, and "send to a friend" relays. These are the cases where SPF and DKIM legitimately break and where preserving the original verdict matters.

It does not weaken spoofing protection. A common worry is that ARC lets attackers launder forged mail by passing it through a forwarder. It does not, for two reasons. First, ARC only preserves the results the intermediary actually observed; if the original message failed authentication on arrival, the chain faithfully records that failure, and there is nothing useful to override. Second, ARC is built on trust in the intermediaries. A receiver only honours an ARC chain from forwarders it has reason to trust. An attacker spinning up a throwaway forwarder gains nothing, because no major receiver trusts an unknown ARC sealer. ARC moves the trust question from "do I trust this IP" to "do I trust this named, signing intermediary", which is a much better question to be asking.

It is not something most senders configure. This is the most important practical point. As an ordinary sending domain, you do not "turn on ARC". ARC is added by the receiving and forwarding infrastructure: mailing list managers, forwarding services, and the large mailbox providers that both honour incoming chains and seal outgoing ones. The major providers already do this for you. Your job as a sender is the same as it always was: get SPF, DKIM and DMARC right at origin so that there are genuine passing results worth preserving. If your message fails authentication before it ever reaches a forwarder, ARC has nothing good to carry forward.

It is not a substitute for getting to enforcement. Some teams hear "ARC fixes forwarding" and treat it as a reason to delay DMARC enforcement. The logic is backwards. ARC is precisely the thing that makes moving to p=reject safer, because the main historical risk of enforcement, breaking forwarded and list mail, is exactly what ARC mitigates at the receiver. ARC is a reason to be more confident about enforcement, not less.

What ARC means for your own DMARC rollout

If you are working a domain from p=none towards p=reject, here is how ARC fits into the practical picture.

First, read your reports with forwarding in mind. When you analyse aggregate reports and see failures from IPs you do not recognise, a large share are usually legitimate forwarders and lists, not attackers. Distinguishing the two is the core skill of a rollout. Tools like the DMARC report analyzer help you group sources so you can tell a forwarding pattern (one of your real messages, relayed, modified) from an actual spoofing attempt. Our guide on reading RUA and RUF reports goes into how to interpret these sources.

Second, do not try to authorise forwarders in SPF. A frequent mistake is to keep adding forwarder IPs to your SPF record to stop forwarded mail failing. This does not scale, it consumes your SPF lookup limit, and it is the wrong layer. Forwarding is meant to be handled by DKIM survival and, where that breaks, by ARC at the receiver. Keep your SPF record tight and correct.

Third, lean on DKIM as your durable signal. Because DKIM can survive a plain relay where SPF cannot, a well-configured DKIM signature is your best friend for forwarded mail. Sign with a key on your own domain so the result aligns, keep your signed-headers list sensible, and verify with the DKIM checker. The stronger your DKIM, the more mail survives forwarding without even needing ARC, and the more genuine passing results exist for ARC to preserve when modification does occur.

Fourth, let the receivers do the ARC work. You cannot make a destination provider honour a chain, and you do not need to. The ecosystem of major providers and list managers already implements ARC. Your contribution is upstream: clean alignment, durable DKIM, and a DMARC policy you are steadily tightening. If you want to understand the full stack ARC supports, see our overviews of DMARC, SPF and DKIM, and the broader requirements for the major mailbox providers.

The practical takeaway

ARC is the quiet plumbing that lets DMARC enforcement coexist with the messy reality of forwarded and list mail. SPF breaks the moment a message changes relay; DKIM breaks the moment an intermediary edits the message; and without something to carry the original verdict forward, legitimate mail would fail DMARC at the destination through no fault of the sender. ARC supplies that something: a signed, ordered, tamper-evident chain in which each forwarder records the authentication results it saw and vouches for them to the next hop, leaving the final receiver free to trust those results when it trusts the forwarders.

You do not configure ARC as a sender, and it does not replace any part of the SPF, DKIM and DMARC stack. What it does is remove the single biggest excuse for staying stuck on p=none. Get your authentication right at origin, keep your DKIM durable and aligned, read your reports to separate real forwarders from spoofers, and let ARC-aware receivers handle the rest.

If you want to see exactly how your domain is authenticating today, run it through the free DMARC checker and the wider diagnostic tools, and if you would rather not manage the path from none to reject by hand, our done-for-you service takes a domain to full enforcement without breaking your mail, including the forwarding and list traffic that ARC is built to protect. You can also keep an eye on changes over time with continuous monitoring.