If you are an ordinary sender and a guide has told you to deploy ARC, that guide is wrong twice over. ARC is something an intermediary adds while relaying somebody else's message, so an originating sender has nothing to seal. And the IETF working group that owns it published a draft in April 2026 asking for the specification to be reclassified as Historic, on the grounds that the experiment is finished.
None of which makes ARC useless to read. It still explains why a forwarded message was delivered or refused, and Apple still asks for it on mail forwarded to its mailboxes. Reading it and deploying it are different decisions, and only one of them is being retired.
ARC records what a forwarder saw, which is why a sender has nothing to seal
DMARC breaks on forwarding. A mailing list or a forwarding address relays your message from its own servers, so SPF fails on an envelope domain that is not yours, and any modification to the headers or body breaks your DKIM signature. The message was legitimate when you sent it and fails authentication when it arrives.
ARC was the proposed answer. Each intermediary records the authentication results it saw on arrival, signs that record, and seals the chain of everything before it. A receiver at the end can then see the original result as the first hop observed it, even though the evidence itself is gone.
The party doing that signing is the forwarder, not you. You publish nothing for ARC, there is no DNS record for it on your domain beyond the DKIM key an intermediary would use if you happened to be one, and the header set appears only on messages that have been relayed. A guide that tells an ordinary sending domain to "enable ARC" has confused it with DKIM.
The chain is three headers per hop, and the numbering is the check
Each hop adds three headers, and RFC 8617 section 5.2 makes the set and the sequence strict.
| Header | What it carries |
|---|---|
| ARC-Authentication-Results | The authentication results this hop saw on arrival |
| ARC-Message-Signature | A signature over the message as this hop received it |
| ARC-Seal | A signature over the chain so far, carrying the chain validation status |
Four rules turn those headers into a chain rather than a pile:
- Instance numbers run from 1 upward, continuously, to a maximum of 50. A gap or a repetition is a malformed chain, not a chain with a missing link.
- Each instance has exactly one of each of the three headers. A duplicate is a fault.
- The seal at instance 1 must carry
cv=none, and every later instance must carrycv=pass. That value is the signer's statement about everything before it. - A
cv=failat the highest instance ends the chain there. Once a hop records a failure, nothing after it restores the chain.
The structure is checkable offline and the signatures are not, which is the entire shape of what any header tool can honestly tell you. A reader that looks at the highest instance and reports the value it finds has skipped the check that matters, because it is the continuity from 1 that makes the sequence meaningful.
The IETF is retiring ARC, and says so in plain language
draft-ietf-dmarc-arc-to-historic-00, published 22 April 2026 by Todd Adams of Proofpoint and John Levine of Taughannock Networks, is a working group document, not an individual proposal. It obsoletes RFC 8617 if approved and asks that the specification be marked Historic.
Its conclusions are unusually direct. The experiment is over. Implementers and operators should not rely on ARC going forward and should cease further Internet-wide deployments. Existing deployers should plan to decommission or confine their use to controlled, intra-domain contexts. New deployments are discouraged because they are unlikely to provide useful information for mail processing.
The reason given is not that the cryptography failed. It is that verification without reputation cannot safely override an enforcement policy. An evaluator has to decide whether to trust each signer in the chain before acting on its assertions, which means running a reputation system for intermediaries, and after ten years nobody built one that works at Internet scale. What deployers built instead were allowlists of intermediaries they already trusted, which works bilaterally and does not generalize. The draft names this the core lesson: signatures are not trust.
A second limitation is more specific. When an intermediary modifies a message, ARC identifies who modified it but has no mechanism to say what was changed or why, so the receiver is back to judging the intermediary's reputation. The useful pieces are being folded into the DKIM successor work currently called DKIM2, which avoids a parallel chain and a separate hop-by-hop trust fabric.
Note the status honestly: this is an Internet-Draft, not an RFC. It expires in October 2026 if it does not progress. What it documents, though, is not a proposal so much as a description of where effort has already stopped.
Apple is the one provider that still asks for it, and asks the forwarder
Apple's sender requirements, published in February 2025, ask for ARC on forwarded mail to Apple mailboxes. It is the only one of the four large providers to ask for it at all, and it is the honest reason to surface ARC in a checker rather than ignore it.
Read the scope carefully, because it is where this gets misreported. The ask covers mail forwarded into Apple mailboxes, and the party in a position to satisfy it is the forwarder. If you run a forwarding service, a mailing list or a mail gateway, this is about you. If you send marketing or transactional mail from your own domain, it is not, and no configuration change on your side produces an ARC chain.
The other three large mailbox providers ask for SPF, DKIM and DMARC, and none of them mention ARC. Across the domains we test for the Unspam 2026 Email Deliverability Benchmark, 48% publish a DMARC policy, which is the work that is genuinely unfinished.
What to do instead when forwarding breaks your DMARC
The problem ARC was built for is real and still needs handling. The available answers are less exotic.
- Make sure DKIM is aligned and signs the headers that survive. DKIM is the identifier that gets through a forward at all, because it covers the message rather than the connection. If only SPF is aligned, forwarding removes your only passing identifier.
- Keep the signed header list conservative. A signature over headers that intermediaries routinely rewrite breaks more often than one over the essentials.
- Read your DMARC reports before assuming forwarding is the cause. Forwarders show up as sources you do not recognize passing DKIM and failing SPF, which is a distinctive shape and easy to separate from real problems.
- Do not stay at
p=nonebecause of forwarding. Mail that passes aligned DKIM survives the forward, and the reports tell you which sources do not before you enforce anything. - If you operate an intermediary, follow the DKIM2 work rather than starting an ARC deployment now.
Our guide to DMARC records covers the policy and the reporting, and the identifier that forwarding breaks first is the subject of our guide to the Return-Path.
What a checker can report, and what it should refuse to report
An ARC chain in a message you received is evidence about its path, and it is worth reading on exactly those terms.
Our email header analyzer reports the chain structure: how many sets are present, whether the instance numbers form a continuous sequence from 1, whether each set is complete, whether the cv values follow the rule for their position, and the domain that sealed each hop. It reports a cv=fail as the point where the chain ended.
What it does not do is verify the signatures, and it does not tell you the chain is trustworthy. Those are different claims, and the draft is explicit that chain validity without a reputational judgment is not a basis for a delivery decision. A tool that prints a green ARC badge is asserting something no receiver would act on.
For the records that do decide delivery, our guide to email authentication covers how SPF, DKIM and DMARC depend on one another. To see the authentication results on a real message, including any ARC chain it picked up along the way, run a free spam test.
