ARC (Authenticated Received Chain, RFC 8617) lets forwarders record the authentication results they observed before modifying a message, so downstream receivers can trust the original DMARC verdict even after SPF and DKIM have been broken by forwarding. This article explains what ARC is, how it works, when it matters, and how UK businesses deploy and benefit from it.
When a message is forwarded — through a mailing list, a university alumni relay, a local-authority gateway, a personal forwarding rule — the sending IP changes (breaking SPF) and the forwarder may modify content (breaking DKIM). Without compensating mechanisms, strict DMARC enforcement (p=reject) blocks all such forwarded mail.
The scale of the problem became visible in 2014 when Yahoo published p=reject and mailing lists across the internet broke. Messages from Yahoo users to lists were rejected by list software; messages redistributed by lists were rejected by recipients' mail servers. The industry needed a way for forwarders to preserve the original authentication results across the hops they owned.
ARC is a set of three header fields that a forwarder adds to a message, cryptographically sealing the authentication results it saw at the time it received the message. Downstream receivers can walk the ARC chain backwards, verify each seal, and trust the original DMARC verdict from the first hop in the chain — even if the current SPF and DKIM now fail.
ARC is additive, not replacing SPF, DKIM or DMARC. It provides evidence about what an intermediate hop observed, which receivers can use to override a current DMARC failure if the intermediate is trusted.
ARC-Authentication-ResultsA copy of the Authentication-Results header the forwarder wrote at the time of receipt. Contains SPF, DKIM and DMARC results as the forwarder observed them.
ARC-Message-SignatureA DKIM-style signature covering the message headers and body at the time of receipt by this hop. Similar format to DKIM-Signature but identified as ARC.
ARC-SealA signature over the previous two ARC headers and the seal of the previous hop (if any). Creates a cryptographic chain.
Each forwarder adds all three headers with matching instance numbers (i=1, i=2, etc.). The final receiver reads all three instances, verifies the chain is intact, and decides whether to trust the first hop's authentication verdict.
Consider a message going through three hops:
ARC-Authentication-Results i=1, signs with ARC-Message-Signature i=1, seals with ARC-Seal i=1. Forwards.ARC-Authentication-Results i=2, signs ARC-Message-Signature i=2, seals ARC-Seal i=2 covering the previous hop's seal. Forwards.ARC-Authentication-Results i=1. If the chain is valid and the origin's DMARC passed, the message is accepted despite current SPF/DKIM failures.A Leeds accountancy sends a message to [email protected]:
From: [email protected]
To: [email protected]
DKIM-Signature: d=firm.co.uk; s=2026q2; ...Manchester's alumni forwarder receives, authenticates (DKIM pass, SPF pass, DMARC pass), then forwards to the user's personal Gmail. Before forwarding, Manchester's ARC-signing adds:
ARC-Authentication-Results: i=1; mx.manchester.ac.uk;
dmarc=pass header.from=firm.co.uk;
dkim=pass header.d=firm.co.uk;
spf=pass smtp.mailfrom=firm.co.uk
ARC-Message-Signature: i=1; a=rsa-sha256; d=manchester.ac.uk; ...
ARC-Seal: i=1; a=rsa-sha256; cv=none; d=manchester.ac.uk; ...Gmail receives the forwarded message. The sending IP is Manchester's forwarder, not firm.co.uk's — SPF fails. The message body may have been modified with a disclaimer footer — DKIM fails. Normally DMARC would fail.
But Gmail reads the ARC chain: one hop, signed by Manchester, reporting dmarc=pass for firm.co.uk at the time of receipt. Manchester is a trusted forwarder. Gmail accepts ARC's evidence and delivers the message despite current DMARC failure.
Any organisation that forwards or redistributes mail on behalf of third parties should sign ARC:
End-sender mail servers (the origin of the message, like your business mail server) do not typically sign ARC — they sign DKIM at the origin and trust forwarders to add ARC if forwarding occurs.
As of 2026:
Smaller and older receivers may ignore ARC entirely; for them, DMARC failures from forwarded mail remain unresolvable. The majority of UK business mail traffic, however, benefits from ARC.
Install OpenARC alongside OpenDKIM:
apt install opendkim opendkim-tools openarc openarc-toolsConfigure /etc/openarc.conf:
Domain firm.co.uk
Selector arc2026
KeyFile /etc/arc/arc2026.private
Mode sv
MilterSocket inet:8894@localhostChain Postfix's milters so OpenARC runs after OpenDKIM. Restart both.
Exim 4.95+ has built-in ARC support. Configure via the arc_sign option in transport definitions.
The Axigen platform used by SmartXHosting signs ARC automatically for any forwarded mail. Customers do not configure ARC directly.
Both sign ARC automatically on forwarded mail. No configuration needed.
For a UK business deploying DMARC p=reject, ARC support across the ecosystem means most legitimate forwarded mail continues to pass. The failures that do occur typically come from legacy forwarders that have not yet been upgraded.
When a receiver processes an ARC-signed message, it performs several checks:
Any failure in the chain causes the receiver to ignore ARC and fall back to current SPF/DKIM/DMARC evaluation.
cv= tag in ARC-SealThe cv= tag ("chain validation") in each ARC-Seal indicates the signer's view of the previous chain:
cv=none — first hop, no previous chain.cv=pass — previous chain validated successfully.cv=fail — previous chain failed validation; subsequent hops are advised to stop trusting the chain.A chain containing cv=fail at any hop is effectively broken — receivers do not honour the original DMARC result.
ARC was developed by the IETF DMARC Working Group between 2016 and 2018, reaching Experimental status as RFC 8617 in July 2019. The motivation was the 2014 Yahoo p=reject incident which demonstrated that DMARC enforcement without a forwarding-compatible mechanism would break large portions of legitimate mail.
Major receivers (Google, Microsoft, Yahoo) began supporting ARC shortly after publication. By 2022, ARC was effectively the default response to the forwarding problem across the industry. UK academic and public-sector forwarders followed by 2023-2024.
Current status: widely deployed, stable, continuing to mature. No major specification updates pending.
Q: Does my origin mail server need to sign ARC?
A: No. Origin servers sign DKIM; ARC is added by intermediate hops. If you do not forward mail, you do not sign ARC.
Q: What happens if a middle hop in the chain is not trusted?
A: Receivers evaluate trust per hop. A chain with one untrusted hop may be rejected outright. Receivers maintain lists of trusted forwarders based on track record.
Q: How do receivers decide whether a forwarder is trusted?
A: Reputation over time — volume of mail processed, low spam complaints, correct ARC signing practices. Small or new forwarders may not be trusted until they build a track record.
Q: Is ARC required for DMARC compliance?
A: Not directly required by the DMARC RFC. Required in practice for forwarding-heavy mail flows where DMARC p=reject would otherwise block legitimate forwards.
Q: Does ARC signing affect SPF or DKIM on the original message?
A: No. ARC adds headers; it does not modify the original SPF or DKIM signatures. Those remain for direct receivers to evaluate.
Q: How do I verify a message has passed through an ARC chain?
A: Look at the headers. Messages that have been ARC-signed carry ARC-Authentication-Results, ARC-Message-Signature, and ARC-Seal headers, potentially multiple instances (i=1, i=2, ...).
Q: Can ARC be abused to forge DMARC passes?
A: Theoretically yes — a malicious forwarder could claim a fake DMARC pass in ARC-Authentication-Results. But the forwarder must be trusted by the final receiver, which imposes reputation-based gating. Casual abuse is impractical.
Q: Is ARC deployment complicated for a small UK business?
A: Only if you operate a forwarder. Most UK SMEs do not — their mail goes out via their server and inbound arrives at their server. Forwarding is usually done by larger infrastructure providers who handle ARC.
Q: Does ARC have any overhead for mail delivery?
A: Minimal. A few extra headers and a signature computation at each forwarding hop. Invisible to users; imperceptible to deliverability.
Q: What happens to ARC headers after the final receiver processes the message?
A: They remain in the delivered message. Users rarely see them unless they inspect headers. The signatures remain valid for as long as the associated public keys are in DNS.
Q: Can ARC be added to a DKIM-unsigned message?
A: Yes — ARC is independent of whether the original message was DKIM-signed. A forwarder can still record "no DKIM seen" in ARC-Authentication-Results and sign ARC over the current state.
Q: Does ARC interact with S/MIME or PGP?
A: Yes but independently. ARC signs the transport state including S/MIME and PGP encrypted payloads. The layers do not conflict.
Q: How do mailing lists typically use ARC?
A: Modern list software (Mailman 3, Sympa) rewrites the From header to the list's domain, signs with its own DKIM, and ARC-signs preserving original authentication. Recipients see the list's DMARC passing while retaining attribution of the original author.
Q: Can I see aggregate statistics on ARC effectiveness in DMARC reports?
A: Yes. DMARC aggregate reports include policy_override_reasons with values like "forwarded" or "trusted_forwarder" when ARC saves a message from policy rejection.
Q: Is ARC superseded by anything newer?
A: No. ARC is stable and widely deployed. No replacement is in active development. Future work is in broader adoption and tighter integration with DMARC reporting.
Q: How do UK Jisc Mail and similar academic list operators use ARC?
A: Jisc Mail signs ARC on redistribution. Messages through their lists preserve original DMARC state in the chain. UK universities and academic subscribers benefit automatically.
Q: If I am a UK supplier sending mail to NHS.net, does ARC matter?
A: Yes — if your mail is ever forwarded within NHS infrastructure (common), ARC support in the forwarding path determines whether it reaches the final clinical recipient. NHS.net's own infrastructure ARC-signs.
Q: Does ARC require DNSSEC?
A: No. ARC signatures are validated by DNS TXT lookup for the signer's public key — similar to DKIM. DNSSEC protects the lookup but is not a prerequisite.
Q: Can a forwarder choose not to sign ARC?
A: Yes. The forwarder's mail continues to flow without ARC; downstream receivers see only current SPF/DKIM/DMARC. But the forwarder forfeits the benefit of being a trusted hop in the authentication chain.
Q: If a message passes through five ARC-signing hops, does each add headers?
A: Yes — each adds its instance. Header count grows linearly. Final message may carry 5x three = 15 ARC headers plus the original DKIM. Not a practical concern; messages are still well under any size limits.
Q: Are ARC public keys managed like DKIM public keys?
A: Yes — published at selector._domainkey.domain TXT records. Essentially the same DNS format as DKIM. Some implementations use separate selectors for ARC vs DKIM; others reuse.
Q: Does ARC have a role in anti-phishing?
A: Indirectly. By allowing strict DMARC policies to coexist with forwarding, ARC enables domain owners to deploy p=reject — which is the actual anti-phishing measure. ARC is supportive infrastructure.
Q: How are ARC signatures verified without TLS?
A: ARC uses DNS TXT records for public keys, same as DKIM. DNS is queried during receipt processing; the signatures are cryptographic, independent of transport layer.
Q: Is there monitoring available for ARC chain failures?
A: Receiver-side logs show ARC validation results. On the sender side, you see DMARC aggregate reports with policy_override_reasons reflecting when ARC saved a message. Third-party monitoring services (Mail Hardener, Red Sift) surface ARC data in dashboards.
Q: If I run a small UK mailing list, should I sign ARC?
A: If your list rewrites content or headers, yes — ARC lets subscribers' DMARC at p=reject still accept your distributions. Modern Mailman 3 supports ARC out of the box. Retrofit on older list software may require work.
Q: What happens to mail from someone behind a restrictive corporate firewall that strips ARC headers?
A: The chain becomes incomplete. Downstream receivers treat the message as if ARC were not present and fall back to DMARC as usual. No worse than the pre-ARC baseline.
Q: Is ARC required for Cyber Essentials Plus certification?
A: Not explicitly. But a mature UK email security posture deploying DMARC p=reject will typically also support ARC on forwarders to avoid breaking legitimate mail flows. Auditors recognise this as good practice.
Q: Can ARC keys be rotated like DKIM keys?
A: Yes. Same rotation pattern — publish new selector alongside old, switch signer, wait 30-60 days, revoke old. Quarterly rotation is a reasonable cadence, though ARC keys can be rotated less aggressively than DKIM since ARC validation windows are shorter (ARC results are typically consumed immediately by the next hop).
Q: Does ARC work the same way for mail from outside the UK forwarded into a UK receiver?
A: Yes — ARC is protocol-level and independent of geography. International forwarders following the spec benefit UK receivers identically to UK forwarders.
Q: Are there tools to test whether my forwarder's ARC signing is correct?
A: Hardenize and similar services can test messages you route through them. For operational verification, send test mail through your forwarder to a Gmail inbox and inspect the delivered message's ARC headers.
Q: What level of adoption means "ARC is the default" in practice?
A: In 2026, ARC is the default for handling forwarded mail at major receivers. A mail flow that relies on forwarding and does not deploy ARC is considered legacy. UK business email infrastructure has broadly reached this point.
Q: If I operate a simple inbound filtering gateway (Mimecast, Proofpoint) in front of my mailbox, do I need to worry about ARC?
A: Yes — if the gateway modifies messages (disclaimer headers, content rewriting). Most enterprise gateways ARC-sign by default. Check with the vendor; configure if not on by default.
Q: Can ARC headers be dropped by a spam filter along the way?
A: Some legacy spam filters strip unknown headers. Modern filters preserve ARC. If you see unexpectedly broken chains, check filter configurations in the delivery path.
Q: Is there a way to see all messages in my inbox that benefitted from ARC override?
A: Most mail clients do not expose this. Receiver-side logs (Gmail's Postmaster Tools, Microsoft 365 reports) show aggregate ARC override statistics. For per-message visibility, inspect headers.