DMARC and ARC: How Authenticated Received Chain Fixes Forwarding Issues

Email forwarding has been breaking email authentication for as long as SPF and DMARC have existed. When someone forwards your message, SPF fails because the forwarding server's IP is not in your SPF record. Sometimes DKIM breaks too, if the forwarder modifies the message. ARC (Authenticated Received Chain) was designed to solve this problem.

ARC is a protocol that preserves the original authentication results as an email passes through intermediary servers. It gives the final destination server a trusted record of what happened at each hop, even when SPF and DKIM fail at the last step. This guide explains how ARC works, how it interacts with DMARC, and what it means for domain owners.

The Forwarding Problem

To understand why ARC exists, you need to understand what happens to email authentication when messages are forwarded.

SPF checks the sending server's IP address. When you send an email, the receiving server verifies that your server's IP is authorized to send for your domain. When a forwarder re-sends that message, the IP changes to the forwarder's server. SPF fails because the forwarder is not in your SPF record.

DKIM attaches a cryptographic signature. This signature usually survives forwarding because it travels with the message. But if the forwarding server modifies the message body (adding a footer, for example) or alters signed headers, the signature becomes invalid and DKIM fails too.

DMARC needs at least one to pass and align. If both SPF and DKIM fail after forwarding, DMARC fails. Depending on your policy, the forwarded message gets quarantined or rejected — even though it was a legitimate email that your domain actually sent.

Before ARC, the receiving server had no way to know that the message originally passed authentication. It could only evaluate SPF and DKIM at the final hop, where both might be broken due to forwarding. ARC fills this gap.

How ARC Works

ARC creates a chain of authentication evidence as a message moves through servers. Each intermediary that handles the message adds three ARC-specific headers that document what it observed.

The Three ARC Headers

ARC-Authentication-Results (AAR): This header records the authentication results that the intermediary server observed when it received the message. It captures SPF, DKIM, and DMARC results at that specific hop. This is essentially a snapshot of the email's authentication status at each point in the chain.

ARC-Message-Signature (AMS): This is similar to a DKIM signature but applied by the intermediary server. It signs the message headers and body as the intermediary sees them, creating a verifiable record of the message's state at that hop.

ARC-Seal (AS): This header cryptographically signs the ARC headers from the current hop and all previous hops. It chains the authentication evidence together, preventing tampering. Each seal includes an instance number (i=1, i=2, etc.) that shows its position in the chain.

Here is a simplified example of what ARC headers look like:

ARC-Seal: i=1; a=rsa-sha256; d=forwarder.com; s=arc; cv=none;
  b=<cryptographic signature>
ARC-Message-Signature: i=1; a=rsa-sha256; d=forwarder.com; s=arc;
  h=from:to:subject:date; b=<cryptographic signature>
ARC-Authentication-Results: i=1; forwarder.com;
  spf=pass smtp.mailfrom=yourdomain.com;
  dkim=pass header.d=yourdomain.com;
  dmarc=pass header.from=yourdomain.com

This tells the final destination: "When I (forwarder.com) received this message, SPF, DKIM, and DMARC all passed." The seal ensures these results have not been forged.

The Chain in Action

Here is what happens step by step when a message is forwarded through an ARC-capable server:

1. You send an email from your domain. It arrives at the recipient's mail server.
2. The recipient's server evaluates SPF, DKIM, and DMARC. Everything passes.
3. The recipient has a forwarding rule. Their server forwards the message to another address.
4. Before forwarding, the server adds ARC headers (AAR, AMS, AS) recording that all authentication passed at this hop. The instance number is i=1.
5. The message arrives at the final destination. SPF fails (different server IP). DKIM may or may not pass.
6. The final destination server sees the ARC headers. It verifies the ARC seal from the forwarder. If the seal is valid and the forwarder is trusted, the server can use the ARC results to override the DMARC failure.

If the message passes through multiple intermediaries, each one adds its own set of ARC headers with incrementing instance numbers (i=2, i=3, etc.). The chain grows with each hop.

How ARC Interacts with DMARC

ARC does not change how DMARC evaluation works. A message either passes or fails DMARC based on the standard SPF and DKIM checks at the final destination. What ARC provides is additional information that the receiving server can use when deciding what to do with a message that fails DMARC.

When a message fails DMARC but has a valid ARC chain, the receiving server can make an informed decision:

Trust the ARC chain and deliver the message. If the ARC seals are valid and the intermediary servers are trusted, the receiving server may choose to override the DMARC policy and deliver the message to the inbox.

Apply the DMARC policy anyway. The receiving server is not required to honor ARC results. If it does not trust the intermediary or the ARC chain is invalid, it will apply the DMARC policy as usual (quarantine or reject).

This is an important distinction: ARC is advisory, not mandatory. It is up to the receiving server to decide how much weight to give ARC results. In practice, major providers like Gmail and Microsoft have developed trust models for known forwarders and use ARC data to reduce false positives from forwarding.

Which Providers Support ARC

ARC support has grown significantly since the protocol was published as an experimental RFC (RFC 8617). Here are the major providers that implement ARC:

Google (Gmail): Gmail both generates ARC headers when forwarding messages and evaluates ARC headers on incoming messages. Gmail uses ARC data to reduce false DMARC failures from trusted forwarders, which is particularly relevant because Gmail accounts are among the most common forwarding sources.

Microsoft (Outlook, Microsoft 365): Microsoft supports ARC validation and uses it in their Trusted ARC Sealers configuration. Microsoft 365 administrators can specify which ARC sealers they trust, giving organizations control over which forwarding paths are honored.

Yahoo Mail: Yahoo supports ARC header evaluation and generates ARC headers on forwarded messages.

Proofpoint, Mimecast, and other security gateways: Many enterprise email security gateways generate ARC headers, which is important because these services act as intermediaries for millions of corporate mailboxes.

The trend is clear: ARC adoption is growing, and the major email ecosystem players already support it.

What Domain Owners Need to Do

Here is the good news: if you are a domain owner who sends email and wants it to survive forwarding, you do not need to configure ARC yourself. ARC is primarily a server-side protocol implemented by mail providers and intermediary servers. Your main responsibilities are:

Set up DKIM. ARC helps when SPF fails, but DKIM is still your best defense against forwarding-related authentication failures. If DKIM passes at the final destination, DMARC passes regardless of ARC. Generate your DKIM keys at dkimcreator.com.

Use relaxed DMARC alignment. Relaxed alignment (the default) gives DKIM the best chance of aligning with your "From" domain, even when signing is done by a subdomain. Do not set adkim=s unless you have a specific reason to.

Monitor your DMARC reports. Aggregate reports show you which messages are failing DMARC and why. If you see consistent failures from forwarding servers with valid ARC chains, those are likely legitimate forwarded messages where ARC is working as intended behind the scenes.

Do not weaken your DMARC policy. It can be tempting to drop back to p=none when you see forwarding-related failures. Resist that urge. With DKIM in place and ARC support from major providers, the forwarding problem is largely managed. A strong DMARC policy is more valuable than a weak one that avoids a few edge-case forwarding failures.

ARC Limitations

ARC is not a perfect solution. There are limitations to be aware of:

Trust is not universal. A receiving server must trust the ARC sealer for the chain to be useful. If the forwarder is unknown or untrusted, the ARC headers are ignored. This means ARC works best for well-known, established mail providers.

ARC does not prevent abuse. A malicious forwarder could generate fraudulent ARC headers claiming a message passed authentication when it did not. This is why ARC relies on trust relationships — receiving servers only honor ARC from sealers they recognize and trust.

Not all forwarders support ARC. While adoption is growing, many smaller mail servers and legacy systems do not generate ARC headers. Messages forwarded through these servers have no ARC chain, and the receiving server must make a decision based solely on the final-hop SPF and DKIM results. Organizations running self-hosted email infrastructure should verify whether their mail server software supports ARC sealing and validation.

Multiple hops increase complexity. Each hop in the chain adds a set of ARC headers. Long forwarding chains with many intermediaries create complex chains that are harder to validate and more likely to encounter an untrusted link.

How SPF, DKIM, DMARC, and ARC Work Together

These four protocols form a layered email authentication system:

SPF verifies the sending server is authorized. It is the first line of defense but breaks during forwarding.

DKIM verifies the message is authentic and unmodified. It survives most forwarding scenarios and provides the strongest single authentication signal.

DMARC ties SPF and DKIM to the visible "From" domain and defines what happens to failures. It is the policy layer that makes authentication actionable.

ARC preserves authentication evidence through forwarding chains. It bridges the gap when SPF and DKIM fail at the final destination but passed at an earlier hop.

Together, they cover the vast majority of email delivery scenarios. For a detailed comparison, see our guide on SPF vs DKIM vs DMARC. The recommended approach for any domain owner is straightforward: set up SPF and DKIM, publish a DMARC record with enforcement, and let ARC handle the forwarding edge cases at the provider level. Developers building mail infrastructure should ensure their sending stack supports all three protocols before worrying about ARC.

Monitor Your DMARC Record

You've created your DMARC record — now make sure it keeps working. The Email Deliverability Suite watches your SPF, DKIM, DMARC, and MX records daily and alerts you when something breaks.