Forwarding breaks the assumptions behind SPF, and mailing-list or gateway changes can also invalidate DKIM. By the time the message reaches the next receiver, the authentication results the original sender depended on may no longer hold.
That is why DMARC can fail on legitimate forwarded mail even when the original sender was configured correctly.
What is ARC
ARC preserves authentication results when email passes through forwarders, mailing lists, and security gateways. ARC sits in the part of the mail flow where identity, sender reputation, and enforcement meet. The details matter because one weak link can undo the work done by the other controls.
If you are already working through DMARC and DKIM, this topic gives you the missing layer between the raw signal and the decision you have to make. For a live check, start with the CyberFurl email authentication audit and then use the See the email authentication feature page to see where it fits in the wider CyberFurl workflow.
The 3 ARC headers
ARC works by carrying forward an authenticated story about what earlier hops saw. The three headers are ARC-Authentication-Results, which records what a system observed, ARC-Message-Signature, which signs the relevant content, and ARC-Seal, which seals the chain state for the next hop.
Together they do not “fix” forwarding by magic. They make forwarding behavior explainable and assessable to downstream receivers.
How ARC chains work
Each trusted intermediary adds its own observation and seal, building a chain that later receivers can inspect. A receiver that trusts the intermediary can decide that even if SPF no longer passes at the final hop, the earlier authenticated state is still meaningful enough to consider.
Who actually validates ARC
ARC is only as useful as the receivers and intermediaries that choose to honor it. Large mailbox providers and gateways may inspect ARC, but support and trust decisions are not universal.
That means ARC should be seen as a compatibility and trust-preservation layer, not a guarantee that every forwarding path will be accepted.
Limitations
ARC preserves trust context; it does not create trust where none existed. If the intermediaries are weak, if the chain is broken, or if receivers do not trust the chain, ARC cannot rescue the message on its own.
How to fix or implement ARC
A good implementation plan for ARC starts with inventory, not with copying a sample policy. Teams need to know which providers, applications, mail paths, or DNS owners are already in the flow before they tighten anything.
From there the safe pattern is consistent: publish the smallest defensible change, validate the result from the outside, and keep monitoring after rollout so the control does not quietly regress after a vendor or infrastructure change. CyberFurl helps most when that validation is tied back to live evidence from CyberFurl email authentication audit.
1
Baseline ARC on the live domain
Start by reading the exact DNS records, headers, or transport signals involved in ARC so you know whether the domain is merely configured or actually aligned with production traffic.
2
Publish or correct the control safely
Implement the smallest change that improves ARC without breaking legitimate senders, forwarders, or receiving paths. For email controls, staged rollout matters more than fast rollout.
3
Validate behavior end to end
Check that receivers, forwarding paths, and dependent services behave the way the policy claims they should. Configuration without real validation is how silent delivery regressions happen.
4
Monitor drift continuously
Keep watching reports, DNS changes, and sender inventory so ARC stays trustworthy after vendor changes, key rotation, or mail-routing updates.
Technical Architecture
The Authenticated Received Chain (ARC) is a protocol (RFC 8617) designed to solve the "forwarding breakage" problem inherent in DMARC. When an email passes through a mailing list (e.g., Google Groups) or a security gateway, the intermediary often modifies the message (e.g., adding a [Subject] tag or a footer). This modification breaks the cryptographic DKIM signature. Furthermore, the intermediary's IP address doesn't match the original sender's SPF record, causing SPF to fail. Consequently, strict DMARC policies (p=reject) will block legitimate forwarded mail.
ARC solves this by cryptographically sealing the authentication results at each hop. The architecture relies on three specific headers injected by the intermediary:
ARC-Authentication-Results (AAR): The intermediary records the SPF, DKIM, and DMARC results it observed when the message arrived at its server.
ARC-Message-Signature (AMS): The intermediary cryptographically signs the message (similar to DKIM), encompassing the original headers, the body, and the new AAR header.
ARC-Seal (AS): The intermediary signs the entire ARC chain, effectively sealing the previous hops.
Note the i=1 index, indicating this is the first hop in the ARC chain.
DNS Flow
ARC does not have a dedicated DNS record type like SPF or DMARC. Instead, it piggybacks on the existing DKIM infrastructure:
Key Publishing: The intermediary forwarder (e.g., forwarder.example.com) generates a public/private key pair and publishes the public key as a standard TXT record in DNS, exactly like a DKIM record.
Hop Interception: The forwarder receives an email from original.com. It evaluates SPF and DKIM.
Chain Generation: The forwarder generates the three ARC headers (AAR, AMS, AS), cryptographically signing them with its private key.
Delivery: The forwarder delivers the modified message to the final destination (e.g., Gmail).
Validation: The final destination receiver notices the DMARC failure (due to the broken DKIM/SPF). It then inspects the ARC chain. It queries DNS for the forwarder.example.com public key to validate the ARC-Seal.
Trust Model
ARC introduces a fundamental shift in the email trust model. Instead of relying solely on cryptographic proof from the originating domain, the final receiver must explicitly trust the intermediary domain.
This is the most critical aspect of ARC: ARC only works if the receiver trusts the forwarder. If Gmail receives an email with a broken DKIM signature but a valid ARC chain from a random, unknown forwarder, Gmail will ignore the ARC chain and reject the email. However, if the ARC chain is signed by a trusted entity (like a known university mailing list, or a major security gateway like Proofpoint), Gmail will override the DMARC failure and deliver the message based on the intermediary's attestation.
Common Misconfigurations
Because ARC involves cryptographic chaining, misconfigurations quickly compound:
Failing to Sign the Chain: An intermediary evaluates SPF and DKIM but only injects standard Authentication-Results headers without applying the cryptographic ARC-Seal. Downstream receivers cannot trust unsigned results.
Key Rotation Failures: Just like DKIM, ARC relies on public keys in DNS. If an intermediary rotates its private key but forgets to update the DNS TXT record, all downstream ARC validations will fail, resulting in dropped emails.
Broken Sequence Indexes: Each hop in an ARC chain must increment the index (i=1, i=2, i=3). If a poorly configured script modifies the headers and disrupts this sequence, the entire cryptographic chain becomes invalid.
Security Risks
While ARC solves a deliverability problem, it introduces complex supply-chain risks into the email ecosystem:
Compromised Intermediaries: If an attacker compromises a highly trusted intermediary (e.g., a university forwarding service), they can inject malicious emails, forge a passing ARC-Authentication-Results header, and sign it with the university's trusted ARC key. Downstream receivers (like Google or Microsoft) will trust the ARC seal and deliver the malicious payload.
Replay Attacks: Without strict timestamps and message-ID validation, an attacker might capture a valid ARC-sealed email and attempt to replay it to bypass spam filters.
Header Injection: If an intermediary fails to properly sanitize inbound headers, an attacker might inject fake ARC-Seal headers, attempting to confuse the final receiver's ARC validation logic.
Compliance Impact
While ARC itself is an operational protocol rather than a compliance mandate, its implementation directly impacts regulatory requirements:
Federal Mandates (BOD 18-01): US Federal agencies are required to enforce DMARC at p=reject. Historically, this broke agency mailing lists. Implementing ARC is the only technically compliant way to maintain DMARC enforcement while supporting legacy forwarding infrastructure.
GDPR and Data Integrity: If security gateways strip or modify attachments (e.g., removing PII for compliance reasons), it breaks DKIM. ARC ensures that the cryptographic integrity of the message is tracked chronologically, maintaining an auditable trail of modifications.
Detection and Monitoring
Monitoring ARC requires deep visibility into the exact headers arriving at the final inbox:
DMARC RUA Reports: Unfortunately, standard DMARC aggregate reports (RUA) do not natively provide deep visibility into ARC failures. They will simply show a DMARC failure due to forwarding.
Header Analysis: Security teams must routinely inspect the Authentication-Results headers of inbound mail. A successful ARC override will typically look like this: dmarc=fail (p=REJECT sp=REJECT dis=NONE) arc=pass.
Intermediary Auditing: Organizations that operate their own forwarding infrastructure must continuously monitor their ARC signing logs to ensure the cryptographic seals are being generated rapidly and without error.
Best Practices
Only Trust Known Forwarders: If you operate a receiving Mail Transfer Agent (MTA), configure your ARC validation logic to only override DMARC failures if the ARC-Seal belongs to an explicitly trusted whitelist of forwarders (e.g., major cloud providers, known partner gateways).
Use ARC to Reach p=reject: Do not delay your DMARC p=reject rollout simply because a few obscure mailing lists break. Rely on the fact that major receivers (Google, Microsoft, Yahoo) natively support ARC to seamlessly handle legitimate forwarding.
Rotate ARC Keys Annually: Treat your ARC signing keys with the same cryptographic hygiene as your DKIM keys. Rotate them annually and use at least 2048-bit RSA keys.
How CyberFurl Helps
Debugging why a legitimate email was dropped by a downstream receiver due to complex forwarding hops is a massive drain on IT resources.
Through the CyberFurl Email Intelligence suite, teams gain unprecedented visibility into their email routing topology. CyberFurl parses complex authentication headers to visualize exactly where DKIM signatures are breaking and whether intermediaries are properly applying ARC seals. By mapping your trusted forwarders and identifying misconfigured mailing lists, CyberFurl provides the exact technical evidence needed to confidently enforce DMARC at p=reject without sacrificing deliverability.
Tools to check your ARC
Use the CyberFurl email authentication audit to verify the arc email standard when you want to see the live signal on a real domain. Evaluating your email authentication forwarder setup helps resolve any lingering dmarc forwarding issue. Once checked, step back to the See the email authentication feature page when you need the wider workflow around posture, monitoring, or remediation. That combination is usually much more useful than reading the standard in isolation.
Support depends on the exact receiver, browser, platform, or vendor on the other side. Many ecosystems implement part of ARC, but the reliable answer comes from testing the specific product path you care about in production rather than assuming support is universal.
ARC vs DMARC?
The right comparison is scope plus enforcement point: what each option controls, where it acts in the stack, and what failure looks like when it goes wrong. Similar terms often sound interchangeable until a rollout or incident forces the team to explain which trust decision each one actually changes.
Do I need to enable ARC?
Usually yes if ARC protects a real production path you depend on, but the rollout should follow actual dependency mapping rather than a blind checklist. Check the live signal first, understand what still relies on the current behavior, and then tighten the control with room to validate and roll back safely.
Can ARC be spoofed?
ARC can help, but only when the prerequisites and surrounding trust assumptions are also true. The safest answer is to validate the specific path you care about in production, because edge cases around forwarding, intermediaries, browser support, or vendor behavior are often where theory breaks down.
What is ARC?
ARC preserves authentication results when email passes through forwarders, mailing lists, and security gateways. In practice, teams care about ARC because it changes a real trust boundary somewhere in the stack and gives them a concrete signal they can validate on the live domain or application.
Related reading
Keep the research trail connected so the next control or failure mode is one click away.
