ARC Seals the Gaps DMARC Leaves in Forwarding

A user forwards an invoice from their personal Gmail to their corporate inbox. An hour later, a help desk ticket lands in your queue: 'Important email from a vendor never arrived.' You find it in quarantine, flagged for DMARC failure. The email was legitimate, the user's action was normal, yet the security stack blocked it. Why?

The forwarding process itself broke the authentication. The final mail server saw the email coming from the user's personal mail provider, not the original vendor. This hop mismatch causes an SPF failure. If the forwarding service added a helpful footer or prefix to the subject, it also invalidated the DKIM signature. With both SPF and DKIM alignment failing, DMARC had no choice but to follow its policy—likely `p=quarantine` or `p=reject`.

This is the exact problem Authenticated Received Chain (ARC), defined in RFC 8617, was designed to solve. It creates a cryptographic chain of custody for authentication results, allowing a final recipient to see that an email was legitimate *before* it was forwarded.

Forwarders Are DMARC's Kryptonite

To understand why ARC is necessary, you have to pinpoint exactly where the standard checks fall apart. DMARC relies on the results of SPF and DKIM. When an intermediary like a forwarder or mailing list handler touches a message, it inadvertently sabotages one or both of those pillars.

The SPF Identity Crisis

Sender Policy Framework (SPF), specified in RFC 7208, is a simple identity check: is the IP address sending me this email authorized to send on behalf of the domain in the `Return-Path` address? A domain owner publishes a list of approved IPs and services in their DNS records.

When a message is forwarded, it’s re-transmitted by the forwarding mail server. Imagine a vendor at `acme.com` emails `user@university-alumni.org`, which auto-forwards to their corporate `user@example-corp.com` inbox. The final recipient, `example-corp.com`, sees the email coming from the IP of `university-alumni.org`'s mail server. It checks Acme's SPF record. That university IP isn't listed. The result is an immediate SPF `fail` or `softfail`. The original context is lost; the verifier only sees the last, failing hop.

DKIM's Fragile Signature

DomainKeys Identified Mail (DKIM), per RFC 6376, provides a cryptographic signature that covers specific headers and the message body. This signature confirms that the message hasn't been tampered with in transit. It’s powerful but brittle.

Mailing lists are the classic offenders. They often modify messages by adding a prefix to the `Subject` line (e.g., `[Project-List]`) or appending a footer with unsubscribe instructions. These modifications, however minor, alter the message body or its signed headers. When the receiving server recalculates the hash of the message body to check against the DKIM signature's body hash (`bh=`), they no longer match. The signature is invalidated. This is DKIM working as designed, but it’s a major headache for legitimate, modified mail flows.

When both SPF and DKIM alignment are broken, DMARC (RFC 7489) has no passing signal to evaluate. It defaults to its stated policy, and a perfectly valid email gets binned. The system fails at the edges.

The Three Seals of ARC

ARC introduces three new email headers to create and validate a chain of trust. Each intermediary that participates in the ARC standard adds a new 'set' of these headers, building a verifiable history of the message's journey and its authentication status at each hop.

ARC-Authentication-Results (AAR)

The AAR header is a snapshot. When a mail server in the chain receives a message, it performs the usual SPF, DKIM, and DMARC checks. It then records these results in an `ARC-Authentication-Results` header. This preserves the original verdict before the forward could break it.

ARC-Authentication-Results: i=1; mx.forwarder.com; dkim=pass header.i=@original-sender.com; spf=pass smtp.mailfrom=user@original-sender.com; dmarc=pass (p=reject sp=reject dis=none) header.from=original-sender.com — Example ARC-Authentication-Results header

Notice the `i=1` tag. This is the instance number, indicating it's the first ARC 'set' in the chain. The header contains the same familiar syntax as the standard `Authentication-Results` header, effectively saying, 'When I received this message, SPF, DKIM, and DMARC all passed. Here is the proof.'

ARC-Message-Signature (AMS)

The AMS is a DKIM-like signature that covers the entire message *after* the AAR header has been added. It takes a snapshot of the message headers and body and signs them. Critically, this signature includes the AAR header itself. This binds the original authentication results to the message content at that specific point in time. Any subsequent modification to the email body or headers (except for the next set of ARC headers) will break this signature.

ARC-Seal (AS)

The `ARC-Seal` header is the linchpin. It's a signature that covers the two previous ARC headers for the current instance (`i=1`, for example). This seal locks the AAR and AMS headers together, ensuring they can't be tampered with, stripped, or reordered. It contains its own instance number (`i=`), signature data (`b=`), and a chain validation status (`cv=`). The first ARC participant sets `cv=none`. Subsequent verifiers will change this to `pass` or `fail` as they validate the chain.

Building and Verifying the Chain

The real power of ARC emerges when you see how these headers interact across multiple hops. Let's trace an email's path from a vendor through a mailing list to your corporate gateway.

Hop 1: A message leaves `vendor.com` and arrives at `mailing-list.net`. The mailing list server validates SPF and DKIM. Both pass. Before modifying the message (e.g., adding a footer), it generates the first ARC set (`i=1`). It creates an `ARC-Authentication-Results` header logging the `dkim=pass` and `spf=pass`. It then creates an `ARC-Message-Signature` covering the message content and the new AAR header. Finally, it creates an `ARC-Seal` header that signs the AAR and AMS, setting `cv=none`. Now, it adds its footer and forwards the message.

Hop 2: Your corporate gateway at `your-company.com` receives the message. The source IP is `mailing-list.net`, not `vendor.com`, so SPF fails. The added footer breaks the original DKIM signature. Naturally, DMARC evaluation fails.

Without ARC, this is where the story ends. But your gateway is ARC-aware. It sees the `ARC-Seal`, `ARC-Message-Signature`, and `ARC-Authentication-Results` headers. It begins verification.

The verifier first checks the `ARC-Seal` at `i=1`. Does its signature correctly cover the AMS and AAR headers from instance 1? If yes, the seal is valid. It then checks the `ARC-Message-Signature` at `i=1`. Does its signature correctly cover the message content and the AAR header from that hop? If yes, that signature is also valid. The chain is intact. The final `Authentication-Results` header added by your gateway will now include an `arc=pass` verdict.

Now, your mail security policy has a new, powerful piece of data. Even though DMARC failed on this final hop, the ARC chain passed, and the AAR from `i=1` clearly shows DMARC passed at the first hop. Your system can be configured to trust this ARC result and override the final DMARC failure, allowing the legitimate forwarded message to be delivered.

Adoption and Its Discontents

ARC's utility depends entirely on adoption by the major mail providers—both as sealers of forwarded mail and as verifiers of inbound chains. Fortunately, the biggest players are on board. Services like Google's Gmail and Microsoft's Office 365 both create and consume ARC headers, which has driven widespread relevance. Many email service providers and secure email gateways have also implemented support.

A Chain Is Only as Strong as Its Weakest Link

The trust model of ARC is its biggest limitation. A verifier isn't just validating a chain of cryptography; it's implicitly trusting every intermediary that added a link to that chain. If a misconfigured or malicious forwarder (an 'untrusted intermediary') is part of the mail flow, it could potentially sign and seal a modified or malicious message, giving it a false air of legitimacy. Final receivers must maintain a policy of which ARC-signing domains they trust, and weigh the results accordingly. An `arc=pass` from Google is not the same as one from an unknown, shared hosting provider.

Not a Silver Bullet for Spoofing

It's essential to remember what ARC does: it preserves existing authentication results. It doesn't generate new ones. If the *original* email was a sophisticated spoof from a lookalike domain (`micros0ft.com`) that had valid SPF and DKIM records, ARC would dutifully report `dmarc=pass` in its AAR header. The job of detecting lookalike domains, malicious payloads, or social engineering still falls to other layers of your security stack. ARC tells you if the message's authentication trail survived the journey; it doesn't vouch for the sender's intent.

The takeaway

ARC isn't a replacement for DMARC, SPF, or DKIM. It’s the connective tissue they always needed to function in the messy reality of modern email routing. It acknowledges that mail doesn't always travel in a straight line from A to B and provides a standardized way to preserve context and intent across multiple, legitimate hops. For analysts, it turns a black-and-white `dmarc=fail` verdict into a more nuanced signal.

The presence of an `arc=pass` in an authentication header is a critical piece of triage data. It’s a strong indicator that a DMARC failure was likely caused by forwarding, not by a malicious spoofing attempt. Instead of dismissing the message outright, it tells you to look deeper at the chain. In a busy SOC, this context is invaluable for making faster, more accurate decisions, and tools like MailSleuth.AI that parse and visualize the entire authenticated received chain are indispensable for cutting through that complexity.