What Is ARC (Authenticated Received Chain)? How It Keeps DMARC Intact Through Forwarding

Why Email Forwarding Breaks DMARC: SPF, DKIM, and Alignment Challenges

Authenticated Received Chain (ARC) helps receiving mail servers evaluate messages when forwarding services, mailing lists, or email security gateways disrupt SPF, DKIM, or DMARC authentication. Defined in RFC 8617, ARC records authentication assessments made by participating mail handlers and protects those records with cryptographic signatures.

ARC does not guarantee DMARC alignment or inbox placement. Instead, it gives receiving systems additional evidence to consider when deciding how to handle a message that fails authentication after legitimate intermediary processing.

SPF breaks when the sending path changes

SPF validates whether the connecting mail server is authorized to send for a domain name. That works well when mail goes directly from cohovineyard.com to the receiver. But if the message is forwarded through tailspintoys.com or a vendor gateway, the final receiver sees the forwarding server’s IP address, not the original sender’s server.

As a result, SPF may fail because the forwarding service is not listed in the sender’s SPF record. Even if SPF passed at the first hop, the final email service may not know that. This is where the Authenticated Received Chain, or ARC, becomes valuable: ARC can preserve original authentication information and validation results as the message moves through forwarding chains.

DKIM can fail after message modification

DKIM verifies a cryptographic signature over selected message headers and a canonicalized version of the message body. Forwarding alone does not necessarily break DKIM, but changes to signed headers or the signed body content can cause verification to fail. For example, a mailing list that adds a footer or rewrites a subject line may invalidate a signature if the affected content was covered by that signature.

If both SPF and DKIM fail at the final destination, DMARC may also fail when neither authentication method produces a passing, aligned result. ARC can provide evidence of authentication results recorded before the message was modified, subject to chain validation and the receiver’s trust policy.

What ARC Is and How It Works: ARC-Seal, ARC-Message-Signature, and ARC-Authentication-Results

Authenticated Received Chain (ARC) is an email authentication protocol standardized by the IETF in RFC 8617. It complements SPF, DKIM, and DMARC by preserving signed authentication results at each trusted hop. Each ARC sealer records, signs, and passes its results along, building a tamper-evident ARC chain.

The three ARC header fields

• ARC-Authentication-Results: Records the authentication assessment made by the ARC sealer, including relevant SPF, DKIM, and DMARC results.
• ARC-Message-Signature: Cryptographically signs selected message headers and body content using the sealer’s signing domain.
• ARC-Seal: Signs the ARC set and links it to the chain’s previous sets, allowing receivers to validate the chain’s integrity.

Each ARC set contains these three headers and uses an instance number (i=) to identify its position in the chain. The signing domain appears in the d= tag. A valid ARC chain helps establish that the recorded assessments have not been altered undetectably; it does not independently prove that the original message or the sealer is trustworthy.

Instance numbers and the ARC chain

Each ARC set has an instance number (i=1, i=2, etc.) that tracks each trusted sealer in the chain. The d= value identifies the signing domain, and ARC validation checks the chain’s integrity, seal validity, and sealer trust.

How ARC Preserves Authentication Results Across Forwarding Chains

From first receiver to final mailbox

Consider this flow:

1. A sender at cohovineyard.com sends mail with valid SPF and DKIM.
2. A mailing list at tailspintoys.com receives the message and verifies SPF, DKIM, and policy alignment.
3. The mailing list modifies the subject and footer, causing message modification.
4. The mailing list acts as an ARC sealer and adds ARC-Authentication-Results, ARC-Message-Signature, and ARC-Seal.
5. The final receiver gets the forwarded message and performs ARC validation.

Without Authenticated Received Chain, the final receiver may see SPF fail and DKIM fail. With ARC, the receiver can inspect the ARC chain and see that a trusted ARC sealer recorded a pass result before forwarding. If the ARC-Seal and ARC-Message-Signature verify, the receiver has stronger evidence that the message was legitimate before it was altered.

This does not guarantee delivery, but it gives modern email authentication systems more context. Microsoft 365, Microsoft Defender for Office 365, and other large email service platforms can combine ARC validation with anti-spam, anti-phishing, and business email compromise detection.

ARC vs. DMARC: What ARC Does, What It Doesn’t Do, and Why Trust Still Matters

ARC and policy-based authentication serve different purposes. DMARC evaluates whether SPF or DKIM aligns with the visible From domain and tells receivers what to do when alignment fails. ARC, by contrast, records previous authentication checks and helps preserve validation results across forwarding chains.

ARC does not automatically make a message safe. It does not override all security controls, and it does not mean every forwarded message should be delivered. A malicious vendor could seal bad mail, or an attacker could abuse a compromised forwarding service. That is why a trusted ARC sealer matters.

Trust decisions and abuse controls

A receiver should only rely on an ARC chain when the ARC sealer is trusted. A trusted ARC sealer is typically a reputable email service, security gateway, or partner domain with good operational controls. The receiver may evaluate the trusted signing domain, the d= value, historical reputation, and whether the ARC specification has been implemented correctly.

This trust model is critical for stopping phishing attacks and business email compromise. If a message claims to come from an executive but the ARC-Authentication-Results show suspicious authentication failures, the receiver should not blindly accept it. If the ARC-Seal validates but the ARC sealer is unknown, the ARC chain may provide limited value.

In other words, ARC provides evidence, not a verdict. The receiver still decides how much weight to give the ARC-Authentication-Results, ARC-Seal, and ARC-Message-Signature.

Implementing ARC: Benefits, Limitations, and Best Practices for Senders, Receivers, and Forwarders

ARC is most beneficial for organizations that operate mailing lists, forwarding services, security gateways, or multi-hop cloud email environments. Senders benefit because legitimate forwarded mail is less likely to become rejected email. Forwarders benefit because they can preserve original authentication information. Receivers benefit because they gain more reliable context for authentication checks.

However, ARC has limitations. It cannot repair a malicious message. It cannot prove that the original sender intended every later change. It also depends on receiver trust. If no trusted ARC sealer appears in the ARC chain, the final receiver may treat the ARC data cautiously.

Microsoft 365 and Exchange Online Implementation Notes

In Microsoft 365, administrators can configure trusted ARC sealers through the Defender portal or Exchange Online PowerShell. These settings help determine whether authentication results from trusted forwarding services should influence email delivery decisions.

Administrators can use the Set-ArcConfig and Get-ArcConfig PowerShell commands to configure and review trusted ARC sealers. Appropriate administrative permissions are required.

Before adding a trusted ARC sealer, verify its signing domain and d= value to ensure the ARC signatures can be trusted.

Best practices for ARC sealers and receivers

Organizations implementing Authenticated Received Chain should follow several best practices:

• Seal only after performing authentication checks. An ARC sealer should record accurate ARC-Authentication-Results, including SPF and DKIM outcomes.
• Protect signing keys. ARC-Message-Signature and ARC-Seal are only trustworthy if private keys remain secure.
• Use stable signing domains. The signing domain should be controlled, monitored, and aligned with organizational security policies.
• Monitor validation results. Receivers should log ARC validation outcomes, pass result patterns, authentication failures, and suspicious changes in header fields.
• Avoid over-trusting ARC. A trusted ARC sealer should be reviewed like any other security vendor or email service dependency.
• Inspect message headers during investigations. Analysts should review ARC-Seal, ARC-Message-Signature, ARC-Authentication-Results, instance number, SPF, DKIM, and forwarding history.

For senders, ARC reduces false positives when legitimate messages pass through a forwarding service or mailing list. For forwarders, ARC demonstrates responsible handling of authentication results. For receivers, ARC adds valuable evidence to email authentication decisions while preserving the ability to quarantine, route to the Junk Email folder, or reject suspicious mail.