CyberFurl can load analytics only after you opt in. Core product features work without analytics consent.
What is ARC Email? Authenticated Received Chain — DMARC Forwarding Fix
Email Security
ARC Explained: How Authenticated Received Chain Fixes DMARC Forwarding Failures
ARC (Authenticated Received Chain, RFC 8617) preserves DMARC authentication results when email passes through forwarders, mailing lists, and security gateways that break SPF and DKIM. Learn how the three ARC headers work, which mail providers trust ARC, and how ARC enables confident DMARC p=reject enforcement without sacrificing forwarding deliverability.
ARC (Authenticated Received Chain, RFC 8617) preserves DMARC authentication results when email passes through forwa…
Why DMARC breaks on email forwarding
Email forwarding — through mailing list servers, alumni forwarding services, or email security gateways — fundamentally breaks the authentication assumptions that SPF and DKIM were built on.
When a forwarder relays an email, it sends from its own IP address. That IP is not in the original sender's SPF record. SPF fails.
spf=pass dkim=pass → chain valid
SPF fails on forwarding:
DKIM fails on modification: When a mailing list adds [ListName] to the Subject line or appends a footer to the message body, the original DKIM signature over those headers and body no longer matches. DKIM fails.
DMARC amplifies the problem: With a strict p=reject policy, the final receiver sees both SPF and DKIM failures, and drops the email — even though it came from a legitimate sender that was properly authenticated before hitting the forwarder.
This is the forwarding problem. ARC was designed specifically to solve it without weakening DMARC enforcement.
ARC (Authenticated Received Chain) is a protocol (RFC 8617) that allows trusted email intermediaries to cryptographically preserve and pass along their authentication observations. Instead of losing the original authentication results when an intermediary modifies the message, ARC creates a signed record of what was true at each hop — forming a chain of authenticated observations that the final receiver can inspect and decide to trust.
The key word is trusted. ARC only works when the final receiver trusts the intermediary's ARC signature. A major email gateway like Proofpoint or Mimecast, or a well-known academic mailing list, will have their ARC signing domain trusted by Gmail and Microsoft. An unknown random forwarder will not.
The three ARC headers
ARC works by adding three headers to each message at each trusted hop:
1. ARC-Authentication-Results (AAR):
Records what the intermediary observed when the message arrived at its server — the SPF, DKIM, and DMARC results at that point in the chain. This is the authentication snapshot for that hop.
2. ARC-Message-Signature (AMS):
A DKIM-style cryptographic signature over the current message headers, body, and the AAR header. This proves the content was not modified after the intermediary observed and signed it.
3. ARC-Seal (AS):
Seals the entire ARC chain state for this hop, signing the i= index, cv= chain validation result, and the AMS header. This allows receivers to verify that the chain was not tampered with between hops.
The i=1 index indicates this is the first hop in the chain. Each subsequent trusted forwarder increments to i=2, i=3, etc.
How ARC chains enable p=reject without breaking forwarding
The critical behavior: when Gmail receives a message that fails DMARC — but carries a valid ARC chain signed by a trusted intermediary — Gmail can inspect the chain, see that authentication was passing before the forwarder broke it, and choose to deliver the message despite the DMARC failure.
This allows domain owners to advance to p=reject without permanently breaking:
Corporate security gateways that rewrite URLs or add footers
Compliance tools that modify messages in transit
The trade-off: ARC only helps for paths through trusted intermediaries. Obscure or unconfigured forwarders that do not add ARC headers provide no protection — those messages will still fail DMARC enforcement.
The ARC trust model: who trusts which forwarders?
ARC shifts the trust question from "is this message authenticated?" to "do I trust the intermediary that observed it?" Each major receiver (Gmail, Microsoft, Yahoo) maintains their own internal list of trusted ARC signing domains. This list is not publicly published, but in practice includes:
Major cloud email security gateways (Proofpoint, Mimecast, Barracuda)
Large academic email systems
Well-known mailing list services
Unknown forwarders are not trusted — their ARC signatures are ignored. This prevents ARC from becoming an easy bypass mechanism: an attacker cannot set up a random forwarder, sign with ARC, and override DMARC protections.
ARC limitations
No universal trust: ARC trust is receiver-specific and not transparently published. You cannot know with certainty which intermediaries are trusted by which receivers.
Not a replacement for DMARC: ARC does not create authentication where none exists. If the original message was not authenticated, the ARC chain cannot rescue it. DMARC enforcement should not be delayed because of ARC.
Chain integrity required: If any hop in the ARC chain has a key rotation failure, a signing misconfiguration, or an incorrect sequence index, the chain breaks and receivers cannot trust it.
How to implement ARC
step 1─────────>
step 2─────────>
step 3─────────>
step 4─────────>
step 5
1. Step 1:Most organizations are ARC beneficiaries, not ARC implementers. If you are a sender, your job is to reach DMARC p=reject and use strong DKIM signing. The benefit of ARC comes automatically when your emails are forwarded through trusted intermediaries (like major security gateways or academic list servers) that add ARC headers. Use a DMARC checker to confirm your current policy and alignment status.
2. Step 2:Open your DMARC RUA reports and look for failures with source IPs belonging to forwarding services, mailing list providers, or email security gateways. These often appear as large volumes from ASNs like Google Groups, university mail systems, or Proofpoint. A consistent failure pattern from the same forwarding ASN is the signal that ARC is relevant to your deliverability challenge.
3. Step 3:If your organization runs a forwarding service or mailing list that modifies emails in transit, implement ARC signing on your outbound MTA. Generate a DKIM-style key pair, publish the public key in DNS at selector._domainkey.yourforwarderdomain.com, and configure your MTA to add ARC-Authentication-Results, ARC-Message-Signature, and ARC-Seal headers on each forwarded message. Ensure the ARC sequence index (i=) is incremented correctly for each hop.
4. Step 4:The most important action for most organizations is reaching DMARC p=reject. Do not indefinitely delay enforcement because a few legacy forwarding paths may break. Gmail, Microsoft, and Yahoo handle legitimate forwarding via ARC natively. The trade-off: some niche or legacy forwarding services that do not implement ARC may temporarily experience delivery issues, but the spoofing protection gain far outweighs the edge-case deliverability cost.
5. Step 5:After advancing to p=reject, monitor DMARC aggregate reports for a spike in failures from forwarding ASNs. If specific forwarding services are blocking due to ARC not being implemented, work with those providers to add ARC support. CyberFurl's DMARC monitoring identifies forwarding-related failure patterns and helps trace them back to specific intermediaries.
Technical Architecture
ARC is defined in RFC 8617. It relies on the DKIM key infrastructure — forwarders publish public keys as DNS TXT records at selector._domainkey.forwarderdomain.com:
Intermediary receives message: Records SPF, DKIM, DMARC results observed upon receipt (AAR)
Signs the content: Generates DKIM-like cryptographic signature over message + AAR (AMS)
Seals the chain: Signs the chain state for this hop (AS)
Forwards with headers: Passes message along with i=N ARC headers prepended
Queries arc-2025._domainkey.forwarder.example.com for public key
Verifies the ARC-Seal signature
If chain is valid and forwarder is trusted: may override DMARC failure
Common Misconfigurations
Missing ARC-Seal (signing only AMS, not AS): Downstream receivers cannot verify chain integrity
DKIM key rotation without ARC key update: ARC validation fails for in-flight messages
Broken sequence indexes: Each hop must increment i= correctly; gaps break the chain
Security Risks
Compromised trusted intermediary: If a highly trusted forwarder (major university, Proofpoint tenant) is compromised, attackers can use it to forge ARC chains that override DMARC protection
Replay attacks: Without tight timestamp and Message-ID scoping, captured ARC-signed emails may be replayable to bypass spam filters
False confidence: Organizations that see ARC references sometimes delay DMARC enforcement. ARC is not a reason to stay at p=none — it is a mechanism to safely reach p=reject.
Compliance Impact
CISA BOD 18-01 (US federal): DMARC p=reject requirement for federal domains. ARC enables agencies to enforce p=reject while maintaining legacy forwarding workflows (e.g., government mailing lists)
GDPR / Data integrity: ARC preserves the audit trail of authentication across mail hops, providing a cryptographic record of modifications made to messages in transit
Best Practices for ARC in 2025/2026
Do not delay DMARC p=reject because of forwarding — major receivers handle it via ARC natively
If you operate a forwarder: implement ARC signing — be the trusted intermediary, not the problem
Rotate ARC signing keys annually — same cryptographic hygiene as DKIM keys
Monitor DMARC reports for forwarding-related failures — use them to identify which forwarding paths need ARC support, not as a reason to soften enforcement
Tools to check your ARC
Use the CyberFurl email audit to verify ARC implementation on live emails. Send a test message through each of your known forwarding paths and inspect the full raw headers to check for ARC-Seal, ARC-Message-Signature, and ARC-Authentication-Results headers. Confirm that the i= index is correct and the d= signing domain matches a valid DNS key. Step back to the security report for the wider authentication posture picture.
CF
How CyberFurl Helps
Automated monitoring. Zero manual work.
CyberFurl email audit provides deep visibility into authentication results across the full SMTP header chain. For organizations debugging why legitimate forwarded mail fails DMARC, CyberFurl parses Authentication-Results, ARC-Authentication-Results, and ARC-Seal headers from live messages to trace exactly where authentication broke and whether the ARC chain attempted to preserve it.
Yes — Gmail was one of the earliest and most significant adopters of ARC. Google implemented ARC verification in Gmail to solve the exact problem ARC was designed for: allowing DMARC-protected domains to reach p=reject without breaking legitimate forwarded mail through trusted intermediaries like university lists, alumni forwarding services, and major security gateways. When Gmail receives a message with a valid ARC chain from a trusted intermediary — and the underlying DMARC result would otherwise be a failure — Gmail consults the ARC chain to decide whether to override the DMARC failure. Microsoft and Yahoo also support ARC verification.
ARC vs DMARC — what is the difference?
DMARC and ARC solve different problems and operate at different points in the trust chain. DMARC is an enforcement policy — it tells receivers what to do when email authentication fails for the visible From domain, and it generates aggregate reports. DMARC does not solve the forwarding problem; it makes it worse by enforcing against legitimate forwarded mail. ARC is a compatibility protocol — it preserves the authentication state from earlier hops so that a final receiver can understand what was true before the forwarder modified the message. ARC does not replace DMARC; it is a mechanism that allows DMARC-protected domains to enforce p=reject while maintaining deliverability for legitimate forwarding paths.
Do I need to enable ARC for my domain?
If you only send email and receive email via normal direct delivery, ARC is not something you configure. ARC is configured by intermediaries — the forwarders, mailing list servers, and security gateways that handle email in transit. You benefit from ARC as a sender when your recipients' mail providers verify ARC chains added by trusted intermediaries. You need to implement ARC if you operate a forwarding service, mailing list, or email gateway that breaks DKIM signatures — in that case, your infrastructure needs to add ARC headers to preserve authentication for downstream receivers. For most organizations, reaching DMARC p=reject is more important than ARC — modern receivers (Gmail, Microsoft) handle the forwarding exception via ARC verification internally.
Can ARC be spoofed or abused?
ARC can be forged by a compromised intermediary, which is the fundamental security tradeoff of the ARC model. The safety mechanism is the trust model: a final receiver (like Gmail) only overrides DMARC failures based on ARC if the ARC chain is signed by an intermediary the receiver explicitly trusts. An unknown, random forwarder signing with ARC provides no benefit — Gmail will not override DMARC failures for unknown intermediaries. The ARC trust model is similar to how X.509 PKI works: a CA's signature is meaningful only if the CA is in the trusted root store. For attackers, forging ARC from an untrusted intermediary is useless; compromising a highly trusted intermediary (major university, known gateway) to forge ARC is a sophisticated attack that gains no more capability than what that intermediary already possesses.
What is ARC?
ARC (Authenticated Received Chain) is an email protocol defined in RFC 8617 that enables trusted intermediaries — email forwarders, mailing list servers, and security gateways — to cryptographically preserve their authentication observations as they pass email along. It adds three headers to each processed message: ARC-Authentication-Results (what the intermediary observed), ARC-Message-Signature (a DKIM-style signature of the relevant content), and ARC-Seal (sealing the chain state). Final receivers that trust the intermediary can read these headers and decide to override DMARC failures caused by normal forwarding behavior, enabling DMARC p=reject deployment without breaking legitimate forwarding paths.
Does Microsoft Exchange Online support ARC?
Yes — Microsoft Exchange Online and Microsoft 365 both implement ARC signing and ARC verification. As a sender, Exchange Online adds ARC headers when forwarding mail through Microsoft infrastructure (for example, when a user mailbox has forwarding rules configured, or when mail passes through Microsoft Defender for Office 365). As a receiver, Exchange Online verifies ARC chains from trusted intermediaries when making DMARC disposition decisions. Microsoft is one of the most significant ARC adopters precisely because enterprise customers rely extensively on Outlook forwarding rules and Microsoft security products — both of which modify messages in transit and need ARC to preserve authentication across hops.
How do I identify whether forwarding is causing my DMARC failures?
Look at your DMARC aggregate RUA reports and examine rows where DMARC is failing. For forwarding-related failures, you will typically see: (1) the source IP belongs to a known forwarding service, mailing list provider, or corporate email security gateway — not a malicious actor, (2) the SPF result shows pass for a different domain than the From domain (the forwarder's Return-Path), and (3) failures appear consistently from the same source ASN across multiple reporting periods. If these patterns appear, forwarding is the cause. The correct fix is not to weaken DMARC — it is to ensure DKIM is correctly configured (DKIM signatures survive forwarding unlike SPF) or to work with the forwarder to implement ARC signing.
