Introduction
ARC — Authenticated Received Chain — is the mechanism that solves a specific, common problem: legitimate email that fails DMARC because an intermediary modified it or hid the original sender. Mailing lists, forwarding services, and secure email gateways all break SPF and DKIM in ways that make perfectly legitimate mail look like a DMARC failure. ARC is the standardized way for a trusted intermediary to preserve the authentication results it observed, so the final receiver can factor them into its decision.
This article is the deep-dive companion to why DMARC fails behind a gateway. It walks what ARC is, the headers it adds, the cv= chain-validation tag, and — importantly — the limits of what ARC can and cannot do.
Why this topic matters
DMARC has a known, structural weakness with indirect mail flows. When mail passes through a mailing list that appends a footer, or a forwarder that changes the envelope, or a gateway that rewrites links, the DKIM signature breaks and the SPF check evaluates the wrong IP. The result is a DMARC failure on mail that is entirely legitimate. Before ARC, the only options were to weaken the DMARC policy (bad) or accept that some legitimate mail would be caught by enforcement (also bad).
ARC gives receivers a third option: trust the authentication verdict that a reputable intermediary observed before it modified the message. For MSPs, understanding ARC is essential because so many DMARC failures in the real world are ARC-shaped — the failure is at the intermediary layer, not the sender.
The problem ARC solves
Consider a message that authenticates perfectly when it leaves the sender:
“ [email protected] sends ↓ SPF pass (sender IP authorized) DKIM pass (signature valid) DMARC pass (aligned) ↓ Message arrives at a mailing list ↓ List appends "Unsubscribe" footer to the body List rewrites the From: header ↓ Message forwarded to final recipients ↓ At the final receiver: SPF fail (connecting IP is now the list, not the sender) DKIM fail (body was modified — signature no longer validates) DMARC fail (neither aligned check passes) “
The message was legitimate. Every check passed at origin. But by the time it reaches the final recipient, the modifications made by the mailing list have broken both authentication paths. Without ARC, the final receiver has no way to know that the message authenticated cleanly before the list touched it.
What ARC does
ARC lets each participating intermediary record the authentication state it observed and cryptographically seal that record. The chain of seals travels with the message. The final receiver can inspect the chain and decide: "This message fails DMARC now, but a trusted intermediary attests that it passed DMARC before modification. I'll factor that in."
In plain terms, ARC lets an intermediary say:
“ When I received this message, SPF/DKIM/DMARC had these results. I am sealing those results so the next receiver can evaluate them. “
The key word is trusted. ARC does not force the receiver to accept the intermediary's word. It gives the receiver additional context, and the receiver decides whether the sealer is trustworthy enough to act on.
The three ARC headers
Each ARC-participating hop adds three headers, numbered by their position in the chain (instance 1, instance 2, etc.):
ARC-Authentication-Results (AAR). Records the SPF/DKIM/DMARC results this hop observed when it received the message. This is essentially a snapshot of the Authentication-Results header at that point in the chain.
ARC-Message-Signature (AMS). A DKIM-like signature over the message as this hop received it. It signs the headers and body so a later receiver can verify what the message looked like at this point in the chain.
ARC-Seal (AS). A signature over the ARC headers themselves (the AAR and AMS of this instance, plus all previous ARC headers). This is what chains the instances together and makes the whole sequence tamper-evident.
Together, these three headers per hop create a verifiable chain. Each seal covers the previous seals, so you cannot remove or reorder a link without breaking the chain.
The cv= tag — chain validation
The single most important tag when reading ARC is cv= on the most recent ARC-Seal. It reports the validation state of the entire chain up to that point:
cv=none. No ARC chain exists yet. This is what the first ARC-participating hop sets — there was nothing before it to validate.
cv=pass. The chain is intact. Every seal from the originating ARC hop through this one validates correctly. The receiver can trust that the recorded authentication results have not been tampered with. (It still has to decide whether it trusts the sealer, which is a separate question.)
cv=fail. The chain is broken. Some seal in the sequence didn't validate — a hop modified the ARC headers improperly, or an intermediary that should have sealed didn't, or the chain was tampered with. A broken chain means the receiver cannot trust the preserved results and will fall back to evaluating the message as it stands.
When you're triaging a DMARC failure on forwarded mail, cv=pass on the ARC chain is the signal that the message may have authenticated cleanly upstream. cv=fail means the ARC evidence is unusable and you're back to the raw DMARC verdict.
How a receiver uses ARC
When a receiver that supports ARC gets a message that fails DMARC, it can perform an additional evaluation:
- Is there an ARC chain? If not (
cv=noneor no ARC headers), evaluate DMARC normally. ARC provides nothing. - Does the chain validate? Check
cv=. Ifcv=fail, the chain is untrustworthy — evaluate DMARC normally. - If
cv=pass, do I trust the sealer? This is a local policy decision. The receiver maintains (implicitly or explicitly) a set of ARC sealers it trusts — large, reputable forwarders and gateways. If the outermost sealer is trusted, proceed. - What did the trusted sealer observe? Read the ARC-Authentication-Results. If the sealer recorded a DMARC pass before modification, the receiver may choose to deliver the message despite the current DMARC failure.
The critical point: every step involves the receiver's judgment. ARC gives the receiver information; it doesn't dictate the outcome. Two receivers with different trust policies can reach different decisions on the same ARC-sealed message.
ARC and Microsoft 365
Microsoft 365 supports ARC, and the interaction with third-party gateways is where it matters most for MSPs. When a gateway sits in front of Microsoft 365 and modifies messages, Microsoft 365 can be configured to trust the gateway's ARC seal. If configured correctly, Microsoft 365 will evaluate the authentication results the gateway observed before modification, rather than only the (now-broken) results of the modified message.
This is a deliberate configuration step. Microsoft 365 does not trust every ARC sealer automatically — the tenant admin specifies which sealers to trust. Trusting the wrong sealer is a security risk (a malicious intermediary could forge favorable authentication results), so the trust decision should be made carefully and only for gateways that are genuinely in the mail path. The Enhanced Filtering for Connectors article covers the related connector configuration.
When ARC helps
ARC is genuinely useful in these situations:
Mailing lists. The classic ARC use case. A list that modifies the body and rewrites From: will break DMARC, but if the list seals with ARC and the receiver trusts it, legitimate list traffic survives enforcement.
Forwarding services. Auto-forwarders (someone forwarding their work mail to a personal account) break SPF alignment. ARC preserves the original verdict.
Secure email gateways. A gateway that scans and modifies inbound mail before delivering to Microsoft 365 or Google Workspace can seal the pre-modification authentication state, so the final platform doesn't treat legitimate mail as a failure.
Multi-hop enterprise routing. Complex internal mail routing that passes through several systems can use ARC to preserve the original external authentication verdict.
When ARC does NOT help
ARC is not a universal fix. It does nothing in these cases:
No ARC participation. If the intermediary doesn't seal with ARC, there's no chain to evaluate. Many older forwarders and smaller gateways don't implement ARC sealing.
Untrusted sealer. If the receiver doesn't trust the sealer, cv=pass is irrelevant — the receiver won't act on results from a sealer it doesn't trust. A brand-new or unknown intermediary gets no benefit.
Broken chain (cv=fail). If any hop breaks the chain, the whole ARC evidence is discarded.
The message was actually bad. ARC preserves whatever the intermediary observed. If a message failed authentication before the intermediary, ARC faithfully preserves that failure. ARC is not a way to launder a spoofed message into a passing one — a correctly-behaving sealer records the real (failing) verdict.
The important caveat: ARC is not a free pass
ARC should never be treated as a universal bypass for DMARC failures. A malicious or poorly configured intermediary can create confusing or dangerous results. ARC only helps when:
- the intermediary is genuinely trusted by the receiver;
- the ARC seal is valid (
cv=pass); - the original authentication results were captured correctly;
- the receiving system knows how to evaluate ARC;
- local trust policy is configured safely.
The security risk to avoid: trusting an ARC sealer that shouldn't be trusted. If a receiver trusts a malicious intermediary's ARC seal, that intermediary can forge favorable authentication results for spoofed mail. The trust decision is a security-sensitive configuration, not a checkbox. Trust only sealers that are genuinely in your mail path and that you have a reason to trust.
ARC adds context. It does not replace SPF, DKIM, or DMARC.
What MSPs should do with ARC
For an MSP managing DMARC across client domains, ARC shows up in three practical ways:
Interpreting failures. When a client's aggregate reports show DMARC failures on what look like legitimate senders, check whether the mail path involves a forwarder, list, or gateway. If it does, the failure is likely ARC-shaped — the fix is upstream, not in the client's DMARC record. The Email Header Analyzer surfaces the ARC chain status (cv=) so you can see this quickly.
Configuring the client's gateways. If a client runs a gateway in front of Microsoft 365 or Google Workspace, ensure the gateway is ARC-sealing and the mail platform is configured to trust it. This preserves legitimate mail through the modification the gateway performs.
Explaining the picture to the client. Clients who see DMARC failures on legitimate mail often panic. Explaining that the failure is caused by an intermediary — and that ARC (correctly configured) resolves it — turns a false alarm into a routine explanation. This is exactly the interpretation work an MSP is paid for.
Headers to look for
When investigating ARC, look for these headers in the message. The Email Header Analyzer parses them automatically:
“ ARC-Seal: i=1; cv=pass; ... ARC-Message-Signature: i=1; ... ARC-Authentication-Results: i=1; ... “
The i= value is the instance number (position in the chain). The cv= on the highest-numbered ARC-Seal is the chain-validation verdict. Multiple instances (i=1, i=2, …) indicate multiple ARC-participating hops.
Related articles
- Why DMARC fails with a gateway in front of Microsoft 365
- Why DMARC reports say reject but the email was delivered
- Microsoft 365 Enhanced Filtering for Connectors
- How to read email headers — an MSP triage guide
- DMARC alignment explained
Authoritative references
- RFC 8617 — The Authenticated Received Chain (ARC) Protocol
- RFC 7489 — DMARC
- RFC 6376 — DKIM Signatures
Author: DMARC AI editorial team Last updated: July 2026