ARC in Email Gateways: Support, Adoption and DMARC Role

You forwarded mail from a personal address to your work account for years. You finally convinced the security team to move DMARC to p=reject. Within a week, mailing-list mail and forwarded mail start landing in junk - or never arriving at all. Authentication headers say the messages were fine when they left the original sender, but by the time they reach your tenant, DMARC alignment is broken. The authentication chain is broken too, but only in the sense that nobody has preserved it.

ARC (Authenticated Received Chain, defined in RFC 8617 in July 2019) exists for this exact situation. It is an explicit chain of custody for email authentication results. Each intermediary that handles the message can add a signed layer saying what authentication results were visible at that point. The final receiver can then choose to honor that chain rather than re-evaluating alignment against a message that has been modified in transit.

ARC is not a replacement for DMARC. It does not make a non-aligned message aligned. It preserves the original alignment information so a receiver that trusts the intermediaries can apply informed disposition decisions. Without ARC, a strict DMARC policy on a forwarded message will almost always reject.

What problem does ARC solve?

DMARC alignment requires the SPF-authenticated identity or the DKIM signing domain to match the visible From domain. Forwarding breaks that in two ways.

The first is SPF. When a forwarder relays a message, it adds its own envelope sender. SPF now checks against the forwarder\'s IP, not the original sender\'s. Unless the receiver\'s policy accepts the forwarder\'s domain as a valid SPF identity for the original From domain, alignment fails.

The second is DKIM. Mailing lists and many forwarders modify the message in transit (adding a subject tag, adding a footer, attaching unsubscribe links). Any modification after signing breaks the signature. Even if the body passes DKIM verification against the modified version, alignment still fails because the From domain is unchanged but the signing domain belongs to the intermediary.

The result is legitimate, well-intentioned mail that arrives at a DMARC p=reject tenant and gets quarantined or dropped. ARC was designed to address this by carrying an attested authentication assessment through each hop.

ARC does not fix the original alignment. It carries a separate, signed assertion that says: at this point in the chain, the message was authenticated by the original sender, and here are the specific results. The practical impact: without ARC in the chain, a forwarded message will reliably fail DMARC alignment at the final destination if that destination is at p=quarantine or p=reject. ARC is what makes strict DMARC enforcement possible on a domain that is also being forwarded.

How ARC works: three headers in a chain

ARC adds three header fields per intermediary hop. Each intermediary that wants to participate adds its own complete set of three headers. The sets are ordered, with the most recent hop at the top.

ARC-Authentication-Results (AAR) is the per-hop authentication results. It is structurally similar to the standard Authentication-Results header, but scoped to the ARC chain rather than to a single evaluation. It records the SPF, DKIM, and (if evaluated) DMARC results that the intermediary saw at the moment it received the message. Each intermediary adds its own AAR.

ARC-Message-Signature (AMS) is the per-hop integrity check. It is a DKIM-like signature over the message body and a selected set of header fields, but signed by the ARC intermediary, not by the original sender. It proves that the body and selected headers have not been tampered with between this hop and the next. Each intermediary adds its own AMS.

ARC-Seal (AS) is the cryptographic attestation for the entire chain. The seal covers all previous ARC headers, plus a small set of message-level fields. It is signed by the ARC intermediary\'s own key (typically tied to the intermediary\'s DKIM selector domain). The seal is what binds the chain together. If any earlier hop is altered, the seals break in a verifiable way.

The instance counter (i=) keeps the chain ordered. The first intermediary that seals sets i=1. The next sets i=2, and so on. A receiver that walks the chain checks each instance in order and verifies the seal for that instance against the previous set of headers.

In practice, the headers look something like:

ARC-Authentication-Results: i=1; mx.example.net; dkim=pass header.d=original-sender.example; spf=pass smtp.mailfrom=original-sender.example\nARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.example.net; s=arc; t=1700000000; ...\nARC-Seal: i=1; a=rsa-sha256; t=1700000000; cv=none; d=mx.example.net; s=arc; ...\nARC-Authentication-Results: i=2; lists.example.org; dkim=pass header.d=original-sender.example; spf=pass smtp.mailfrom=original-sender.example\nARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=lists.example.org; s=arc; t=1700000005; ...\nARC-Seal: i=2; a=rsa-sha256; t=1700000005; cv=pass; d=lists.example.org; s=arc; ...

Each hop adds a fresh set of three headers. The chain grows downward. The most recent seal (the last one added) is what the receiver validates first.

Sealer and validator are different jobs

The ARC specification splits the protocol into two roles. Each intermediary plays one or both roles, depending on what it does.

A sealer is any intermediary that adds ARC headers to a message. Common sealers include mailing list managers, ESPs that handle bounces or reformat messages, forwarders, and security gateways that re-sign or annotate mail. A sealer is responsible for choosing whether to participate in ARC, generating its own DKIM-style key for ARC sealing (published in DNS as a regular DKIM record at a designated selector), and signing the AMS and AS headers it adds.

A validator is the receiving server that makes the final disposition decision. A validator walks the most recent seal backward, decides whether the chain is trustworthy (typically every seal must cryptographically verify and the chain must be unbroken), and then decides whether to honor the original authentication results carried in the AAR headers. A validator can choose to honor ARC and accept the message as if it were aligned, fall back to standard DMARC evaluation, or reject outright.

The two roles are deliberately separate. A relay can seal without validating, and a receiver can validate without ever having sealed anything. Most production systems do both: gateways seal outgoing mail and validate incoming mail.

Where ARC is actually supported today

The adoption story is uneven. ARC sealing requires a participating intermediary that has chosen to implement the protocol, published an ARC DKIM key, and is willing to sign on behalf of forwarded mail. ARC validation is more common because the major mailbox providers all support it on the receiving side. The list below is a practical map, not an exhaustive one, and it changes as vendors ship updates.

Open source MTAs are the easiest place to find ARC sealing. Postfix has the most mature ecosystem. arc-dkim-milter is a milter that signs and verifies ARC on Postfix, and there are production deployments at mailing list operators and ESPs that use it. OpenDKIM has ARC support in its more recent releases, often combined with arc-seal helper tools. Exim and Sendmail have ARC implementations but they are less commonly deployed. Haraka and other Node.js MTAs have ARC libraries available, mostly for high-volume transactional senders.

The major mailbox providers support ARC validation in their inbound pipelines. Google Workspace (Gmail) has supported ARC verification for years and uses it as one of several signals in its spam and authentication scoring. Microsoft 365 (Exchange Online and Outlook.com) supports ARC validation on inbound mail. Apple iCloud validates ARC as well. None of these three publish detailed public documentation on the exact policy they apply once ARC validation succeeds, which is itself a useful signal that ARC is part of standard inbound handling.

The big security gateway vendors fall in a more complicated place. Proofpoint supports ARC in its gateway products, with both sealing and verification depending on configuration. Cisco Ironport (now Secure Email) added ARC support in AsyncOS releases that rolled out from 2024 onwards. Mimecast supports ARC in its inbound and outbound pipelines. Barracuda supports ARC on its Email Security Gateway. Adoption among the gatekeepers is widespread but not uniform; the feature flags often depend on the specific product tier and version, and operators should check their vendor\'s release notes.

ESPs are the most operationally important category for ARC. When a marketing platform sends mail on behalf of a customer, that message has to authenticate against the customer domain, not the ESP. ESPs that support ARC sealing can preserve authentication across their own internal processing. Mailchimp, SendGrid, Postmark, and Amazon SES can each participate in ARC, but the configuration is per-sending-domain and requires a DKIM key for ARC sealing to be published in DNS. Many ESPs default to enabling ARC where the customer has DKIM set up, but the customer has to opt in.

Mailing list managers are a special case. Mailman 3 supports ARC sealing when configured with a DKIM key. Sympa supports ARC. GNU Mailman 3 specifically documents the protocol and ships configuration helpers. ezmlm and other smaller list managers have variable support. For a list operator, ARC sealing is one of the few ways to keep mail flowing to a p=reject destination.

ARC and DKIM2 / DMARCbis: where this is going

ARC has been an Experimental protocol since 2019. The IETF DMARCbis working group has discussed whether ARC\'s concepts should fold into a successor protocol, often referred to as DKIM2 or DKIMv2. The general direction in the working group is that some ARC concepts, particularly the chain-of-custody model for authentication results, are useful enough to carry forward, but the exact mechanism may change.

The practical consequence for operators is twofold. ARC works today and is being used today. The protocol is implemented across most major mailbox providers, the major security gateways, and a long list of open source MTAs. If you operate a mailing list, a forwarding service, or any mail relay that processes mail on behalf of third parties, enabling ARC sealing now is sensible. Waiting for DKIM2 to standardize before turning on ARC would mean years of broken legitimate mail flowing through your infrastructure.

The second consequence is that any ARC implementation you deploy today may need to be updated as DKIM2 ships. Treat your ARC key management, your DNS records, and your gateway configuration as things that will eventually need to be revisited. Do not treat ARC as a permanent final state.

Practical guidance for operators

If you run a mailing list or any kind of mail relay that modifies messages and forwards them onward, ARC sealing is a small operational change with a large payoff. The steps are roughly: generate or repurpose a DKIM key for ARC (typically a different selector than your signing key), publish the public key in DNS as a regular DKIM record at that selector, configure your list manager or gateway to sign on each outgoing hop, and verify with a test message to a DMARC p=reject tenant.

If you run a forwarding service (for example, a hosted business email that forwards to Gmail or Microsoft 365), the same pattern applies. ARC sealing plus careful preservation of the original message body and the original From header are the two most important pieces. Some operators also choose to DKIM re-sign the forwarded message under their own domain so receivers have a fresh signature to evaluate.

If you receive mail into a DMARC p=reject tenant, your inbound pipeline already supports ARC validation in most cases. What you can add is operational visibility. Look at the raw headers of forwarded mail from senders who complain that their mail is being rejected. If ARC headers are present and the chain validates, your gateway should be honoring them. If a forwarder is not sealing and you cannot convince them to start, your practical options are limited: keep DMARC at p=quarantine for that sender\'s traffic, or accept that their forwarded mail will need to be re-routed.

A concrete aggregate-report signal that ARC is in use is a consistent DKIM signing domain that does not match the From domain but does match a domain you operate as a relay. If your DMARC reports show, for example, that your mailing list manager\'s DKIM key is signing messages from your customer domains, that is ARC sealing working as intended. Monitoring this over time is a useful sanity check after enabling ARC.

A tool like DMARCFlow watches your aggregate reports and surfaces DKIM signing domains you do not recognize, which is the operational complement to spending time with ARC sealing on the relay. It is not a fix for ARC, and it is not a way to debug ARC chains, but it is the way to confirm that what you think is happening at the relay is actually reaching the receiver as intended. One practical use: if your DMARC reports stop showing your mailing list manager\'s signing domain after you enable ARC, something has gone wrong at the relay and the chain is not being preserved.

A concrete worked example helps. Imagine you operate a mailing list at lists.example.com and your customer domains (customer-a.com, customer-b.com) are at DMARC p=reject. After you enable ARC sealing on the list, your DMARC aggregate reports should start showing lists.example.com as the DKIM signing domain for messages that originally came from customer-a.com and customer-b.com. That is the visible signal that ARC is doing its job - the original DKIM signature is gone (because the list modified the message) but ARC is preserving the authentication chain so the final receiver honors the original alignment. If the signing domain in your reports shifts away from lists.example.com back to a customer domain or to nothing at all, the chain broke somewhere between the list manager and the receiver and you have a configuration problem to find.

FAQ

Is ARC a replacement for DMARC?
No. ARC preserves original authentication results so a receiver can make a more informed decision. It does not make a non-aligned message aligned. DMARC remains the layer that tells the receiver what to do when authentication fails, and ARC only matters if the receiver has chosen to honor a validated chain instead of falling back to plain DMARC.

Does ARC work with every mail server?
No. ARC requires the intermediary to participate by signing, and the receiver to participate by validating. Most major mailbox providers validate ARC. Sealing is less universal. Mailing lists, forwarding services, ESPs, and security gateways vary widely. If a critical intermediary in your path does not seal, ARC will not help your DMARC p=reject policy.

What happens if ARC validation fails?
If the chain breaks (a seal does not verify, or the chain has been tampered with), the receiver falls back to standard DMARC evaluation. ARC provides no special treatment for failed validation. A valid chain is rewarded; an invalid one is treated as if ARC were absent.

Should I enable ARC sealing on my mailing list?
If any of your subscribers enforce DMARC at p=reject, yes. Without ARC sealing, your list messages will start failing alignment for those subscribers. ARC sealing plus DKIM re-signing is the standard mitigation. If none of your subscribers are at p=reject, ARC is optional but worth enabling for forward compatibility.

Is ARC production-grade?
ARC has been implemented across most major providers and is in production use. The protocol itself is still labeled Experimental in RFC 8617, and there is a real possibility that some of its concepts will be folded into DKIMv2. Treat ARC as a current best practice, not as a permanent standard.

Does DMARCFlow implement ARC?
No. DMARCFlow is a sender-side monitoring and reporting product. ARC is a receiver-side and relay-side concept. DMARCFlow can help you verify that ARC is working on your sending side by showing whether ARC seals are reaching your receivers in your aggregate reports, but it is not an ARC tool.

Where can I read the original ARC specification?
RFC 8617, published by the IETF in July 2019. The current DMARCbis and DKIMv2 working group drafts are the natural follow-on reading if you are designing a new implementation.

Where to read the original sources

RFC 8617 - The Authenticated Received Chain (ARC) Protocol - the canonical specification.
IETF DMARCbis working group - current drafts and discussions on the successor protocol that may incorporate ARC concepts.
Authenticated Received Chain on Wikipedia - the broader category context, including the link to DKIMv2 discussion.