Quick ARC reference
ARC (Authenticated Received Chain) is an email authentication extension that lets intermediaries (mailing lists, forwarders, gateways) preserve a record of the original authentication results when they modify a message in ways that would otherwise break SPF, DKIM, or DMARC. Without ARC, a forwarded or list-distributed message often fails authentication at the final recipient even when the original sender authenticated correctly.
| What it does | Carries proof that an intermediary saw the message pass authentication, so the final receiver can decide to trust the chain |
| RFC | RFC 8617, published July 2019 |
| Who sets ARC headers | Intermediaries: mailing lists, forwarders, email gateways, security proxies |
| Who reads ARC headers | Final mailbox providers when DMARC fails: Gmail, Microsoft, Yahoo and others |
| Replaces DMARC? | No. ARC supplements DMARC for cases where forwarding or list traffic would otherwise fail it |
| Three header fields | ARC-Authentication-Results (AAR), ARC-Message-Signature (AMS), ARC-Seal (AS) |
What is ARC?
ARC is an email authentication framework that solves a specific problem: messages that pass SPF, DKIM, and DMARC at the original sender often fail those same checks at the final recipient because an intermediary in the middle modified the message. Mailing list software prepends [List-Name] to subject lines, adds footers with unsubscribe links, or replaces the From address with the list’s address. Forwarding services rewrite headers. Each of these changes is legitimate but breaks DKIM signatures or SPF alignment, and the final mailbox receiver sees a DMARC failure.
Before ARC, the only options were either to relax DMARC enforcement (defeating the point) or to live with broken delivery from mailing lists. ARC provides a third option: the intermediary signs a record of the authentication results it saw, and the final receiver can choose to trust that signed record when its own DMARC check fails.
The standard was published as RFC 8617 in July 2019, developed by an IETF working group including engineers from Google, Microsoft, Yahoo, ValiMail and others. As of 2026, ARC is implemented at all major mailbox providers and supported by mainstream mailing list software (Mailman 3, GNU Mailman, Discourse mailing list mode, Google Groups internally).
The problem ARC solves
Consider the path of a message sent to a mailing list:
- Alice at
alice@acme.comsends a message tolist@example.org. The message passes SPF (Alice’s IP is in acme.com’s SPF), passes DKIM (signed by acme.com’s selector), and passes DMARC (aligned with acme.com). - The list software at example.org receives the message, prepends
[Example List]to the subject line, appends an unsubscribe footer to the body, and redistributes to all subscribers. - Bob at
bob@gmail.comreceives the modified message. Gmail checks SPF: the envelope sender is nowbounces@example.org(the list’s bounce address), notalice@acme.com. SPF fails to align with the From address. Gmail checks DKIM: the signature acme.com applied no longer validates because the subject and body were modified. DKIM fails. DMARC fails. - If acme.com has
p=reject, Gmail rejects the message. Bob never sees it.
The problem is that the breakage happened at step 2, by a legitimate intermediary doing its job. Without ARC, the only ways to fix this are:
- The list rewrites the From address to its own (defeats personal sender identity).
- The sender’s DMARC stays at
p=none(defeats the point of DMARC). - The list and sender coordinate exceptions per-list (does not scale).
ARC adds a fourth option: the list signs an attestation saying “I saw this message pass DMARC for acme.com before I modified it.” The final receiver can verify the list’s signature, walk the ARC chain back to the original sender, and choose to deliver the message based on the chain’s trust signals.
How ARC works: three headers
Each intermediary that supports ARC adds three header fields on its way through, all signed by the intermediary’s DKIM-style key:
1. ARC-Authentication-Results (AAR)
A snapshot of the authentication results the intermediary saw when it received the message: SPF status, DKIM status, DMARC status, and any other relevant signals (spf=pass, dkim=pass, dmarc=pass). This is essentially a copy of the Authentication-Results header at that hop.
2. ARC-Message-Signature (AMS)
A DKIM-style signature over the headers and body of the message as the intermediary saw them, including any modifications the intermediary made (such as a subject prefix or footer). This is the intermediary’s signature on the message at this hop.
3. ARC-Seal (AS)
A signature over the ARC headers themselves (the AAR, the AMS, and any prior ARC headers from previous hops). This is what makes the chain tamper-resistant: each hop seals the entire prior chain plus its own additions.
Each hop’s three headers carry an instance number (i=1, i=2, etc.) so receivers can reconstruct the order. A message that passes through 3 ARC-supporting intermediaries arrives with 9 ARC headers total (3 sets of 3).
ARC validation flow at the receiver
When a final mailbox provider (Gmail, Microsoft, Yahoo) receives a message that fails DMARC, it can optionally consult ARC:
- Check for ARC headers. If no ARC chain exists, fall through to standard DMARC failure handling.
- Validate the chain integrity. Each ARC-Seal must validate against the corresponding intermediary’s public key (published in DNS, just like DKIM). If any seal fails, the chain is invalid and ignored.
- Validate the chain’s authentication trail. Walk the AAR records backward. The earliest AAR should show the message passing DMARC for the original sender’s domain. Each subsequent AAR should be consistent with what the intermediary observed.
- Decide whether to trust the chain. This is the soft part. ARC does not mandate “if ARC validates, deliver”. Each receiver applies its own trust policy: trust ARC chains only from known intermediaries (a whitelist of trusted lists and forwarders), trust chains that meet certain criteria, or reject all ARC signals from unknown sources. Gmail and Microsoft publish their trust logic in part; the rest is operational.
- Apply the trust decision. If the chain is trusted, the message is delivered as if DMARC had passed. If not, the standard DMARC failure handling applies.
The critical nuance is that ARC validation is not automatic acceptance. A spammer cannot bypass DMARC by adding ARC headers, because the receiver decides whether to trust each chain. ARC is a tool to help receivers make better decisions about already-suspicious traffic, not a way to override authentication failures.
When ARC headers are set (and when they aren’t)
ARC is set by intermediaries, not by original senders. Specifically:
- Mailing list software: Mailman 3 (since 3.3), GNU Mailman, Sympa, Discourse mailing list mode, Google Groups (internally), and most modern list managers. Older Mailman 2.x does not support ARC.
- Forwarders: Major mailbox providers that offer forwarding (Gmail’s forwarding feature, Outlook’s forwarding, iCloud’s email aliases) sign ARC when they forward.
- Email security gateways: Proofpoint, Mimecast, Microsoft Defender for Office 365, Cisco Secure Email and others add ARC when they relay messages after scanning.
- Some ESPs: A few large ESPs add ARC for their outbound infrastructure, although this is less common because ESPs are usually the original sender, not an intermediary.
An original sender (the first hop from a user’s mail client to their ESP or MTA) does not set ARC. The first ARC header is set by the first intermediary downstream, if any.
ARC and mailing lists in detail
The mailing list scenario is where ARC has the most impact. Before ARC, list operators faced an unworkable choice:
- Option A: rewrite the From address to the list’s own address. Solves DMARC but destroys personal sender identity. Replies go to the list, not the author. Threading breaks. List culture changes.
- Option B: leave the From address as the original sender. Personal identity preserved, but DMARC at the receiver fails because the list’s modifications broke DKIM. Messages reject or quarantine, especially when the original sender’s domain publishes
p=reject.
ARC enables a third path: leave the From address as the original sender, and add ARC headers attesting that DMARC passed before the list modified the message. Receivers that trust the list operator deliver the message anyway. Receivers that don’t trust the list still reject, but the burden shifts: a list that wants its messages delivered needs to operate cleanly enough to be trusted by major receivers.
Mailman 3 introduced ARC support in version 3.3. Operators who upgraded from Mailman 2 to Mailman 3 saw measurable delivery improvements at Gmail and Yahoo specifically because of ARC adoption. The same pattern played out at Discourse and other community platforms.
Provider and software support (2026)
| System | Signs ARC? | Validates ARC? | Notes |
|---|---|---|---|
| Gmail (Google Workspace) | Yes (when forwarding) | Yes | Trusts a curated set of intermediaries; full logic not public |
| Microsoft 365 / Outlook.com | Yes (when relaying) | Yes | Added ARC support in 2020; tied to anti-phish and DMARC override policies |
| Yahoo Mail | Yes | Yes | ARC co-author; deep integration |
| Apple iCloud Mail | Partial | Yes | Less public information; validation observed in production |
| Mailman 3 (3.3+) | Yes | n/a (list software) | Configuration in mm_cfg.py |
| Mailman 2.x | No | n/a | Upgrade path: migrate to Mailman 3 |
| Discourse (mailing list mode) | Yes | n/a | Supported since 2.8 |
| Google Groups | Yes (internal) | n/a | Transparent to administrators |
| Proofpoint, Mimecast, Microsoft Defender | Yes | Yes | Standard in modern enterprise security gateways |
10 common ARC misunderstandings
- “ARC replaces DMARC.” It doesn’t. ARC is a supplement that helps when DMARC fails for non-malicious reasons (forwarding, lists). DMARC remains the primary authentication framework.
- “I need to set up ARC on my sending domain.” Usually no. ARC is for intermediaries. If you are the original sender, you set up SPF, DKIM, and DMARC. ARC is added downstream by lists and forwarders.
- “ARC validates means the message is trusted.” Not automatically. The receiver decides whether to trust each ARC chain. Spammers cannot bypass DMARC by adding ARC headers.
- “ARC headers stay even after the message is delivered.” Yes, but mostly for debugging. End users rarely see them. They live in the raw headers, useful for forensic analysis when a delivery problem occurs.
- “If my mailing list uses ARC, all my messages get delivered.” Only true if the receiver trusts your list. Receiver-side trust policy is the gate.
- “ARC works the same at every provider.” No. Trust policies vary. Gmail’s logic differs from Microsoft’s, which differs from Yahoo’s. Some receivers ignore ARC entirely.
- “ARC requires its own DNS records.” Each intermediary that signs ARC needs a public key in DNS (similar to DKIM), but the original sender does not publish ARC-specific records.
- “ARC slows down message processing.” Negligible. ARC validation adds a few DNS queries per chain, which receivers cache aggressively.
- “My ESP should be setting ARC for me.” Usually not, because the ESP is the original sender (or first hop), not an intermediary. ARC is added by what’s downstream of the ESP, not by the ESP itself.
- “ARC is a Google standard.” Google led the working group with Microsoft, Yahoo, ValiMail and others. It is an IETF standard (RFC 8617), not a Google product.
ARC FAQ
Do I need to set up ARC for my sending domain?
Almost certainly not. ARC is set by intermediaries (mailing lists, forwarders, security gateways), not by original senders. If you send mail directly to recipients via your ESP, ARC is not relevant on your side. Set up SPF, DKIM, and DMARC instead. ARC matters only if you operate a mailing list, a forwarding service, or an email gateway that modifies messages in transit.
Can ARC be used to bypass DMARC?
No. The receiver decides whether to trust each ARC chain. A spammer adding ARC headers to a fraudulent message produces a chain the receiver does not trust, so the message still fails DMARC handling. ARC is a tool for receivers to make better decisions about already-suspicious traffic from intermediaries, not a backdoor around authentication.
Why do mailing list messages still fail DMARC even with ARC?
Several reasons. The list software may not be ARC-enabled (Mailman 2.x, for example, doesn’t sign ARC). The final receiver may not trust the list operator (each receiver maintains its own trust policy). The ARC chain may have broken at some hop (a non-ARC intermediary in the middle invalidates the chain). Or the original sender’s DMARC policy may be so strict that ARC trust signals don’t override it. Diagnose by examining the message headers in the receiver’s mailbox.
Is ARC necessary if I use a modern ESP?
Not for outbound. Your ESP is the original sender, not an intermediary. ARC matters only when an intermediary downstream of your ESP modifies your messages, which happens primarily for mailing list distribution. For typical transactional or marketing email going from ESP to recipient inbox, ARC has no role.
Where do I see the ARC headers on a delivered message?
In the raw message headers. In Gmail, click the three-dot menu on a message and select “Show original”. In Outlook, View > Source. Look for headers starting with ARC-Authentication-Results:, ARC-Message-Signature:, and ARC-Seal:. Each has an i= instance number indicating the position in the chain.
Does ARC work for forwarded emails?
Yes. Forwarding services like Gmail’s auto-forward, Outlook’s forwarding, and most consumer mailbox providers’ forwarding features sign ARC when they relay a message. The final receiver of the forwarded message can validate the ARC chain to see the original authentication results. This is one of ARC’s biggest practical wins: forwarded mail used to fail DMARC routinely; with ARC and a trusted forwarder, it now delivers cleanly.
Final words
ARC is plumbing. Most senders never need to touch it directly because ARC is the job of the systems in the middle, not the systems at the edges. But if you run a mailing list, a community forum that distributes mail, an email gateway, or a forwarding service, ARC is what allows your traffic to coexist with strict DMARC policies at receivers.
The standard’s broader value is conceptual: it acknowledges that real-world email passes through many hands, and that pure end-to-end authentication models (SPF, DKIM, DMARC) don’t handle that reality cleanly on their own. ARC adds a layer of trust about the trip, not just the origin.
For broader context, see our guides on DMARC, SPF, DKIM, and the Deliverability hub.
Related RFCs and standards
ARC (RFC 8617) sits on top of the existing email authentication stack. Understanding the surrounding RFCs helps explain why ARC exists and how it interacts with them:
| RFC | Standard | Relationship to ARC |
|---|---|---|
| RFC 7208 | SPF (Sender Policy Framework) | ARC preserves the SPF result observed by an intermediary, so the final receiver can trust it even after forwarding breaks the original SPF alignment. |
| RFC 6376 | DKIM (DomainKeys Identified Mail) | DKIM signatures often break when intermediaries modify the message body or headers. ARC’s AMS (ARC-Message-Signature) is essentially a DKIM signature scoped to the ARC context. |
| RFC 7489 | DMARC (Domain-based Message Authentication) | DMARC failures at strict enforcement (p=reject) would otherwise block legitimate mailing list and forwarded traffic. ARC provides receivers a signed way to know the original message did pass authentication. |
| RFC 8601 | Authentication-Results header | The Authentication-Results header format that ARC’s AAR (ARC-Authentication-Results) uses to record the observed authentication state at each hop. |
| RFC 5321 | SMTP protocol | The underlying transport protocol. ARC operates at the message-header level, not the SMTP transport level, but understanding SMTP hops is essential to understanding where ARC records get added. |
Frequently Asked Questions
What is RFC 8617 in plain English?
RFC 8617 is the IETF standard that defines ARC (Authenticated Received Chain). It gives mailing lists, forwarders, and other intermediaries a way to record the fact that an email passed SPF, DKIM, and DMARC when they first received it, so that the final mailbox provider can trust that record even when the intermediary’s modifications break the original authentication.
Do I need to configure ARC as a sender?
No. ARC headers are added by intermediaries (mailing lists, forwarders, security gateways), not by original senders. As a sender you still authenticate with SPF, DKIM, and DMARC. ARC only becomes relevant when your outbound mail passes through a mailing list or forwarding service that participates in the ARC chain.
Does Gmail support ARC?
Yes. Gmail was one of the earliest adopters of ARC and validates ARC chains when incoming mail fails DMARC due to forwarding or list modifications. Google Groups also adds ARC headers on outgoing list traffic. Microsoft (Outlook.com, Exchange Online) and Yahoo also support ARC verification.
Does ARC replace DMARC?
No. ARC supplements DMARC. DMARC is the policy layer that tells receivers what to do when authentication fails. ARC gives receivers additional signed evidence to make that decision correctly when a forwarding chain broke the original DMARC alignment. Deploy both.
What are the three ARC header fields?
ARC-Authentication-Results (AAR) records the SPF/DKIM/DMARC results observed by an intermediary. ARC-Message-Signature (AMS) is a DKIM-style signature over the message as the intermediary received it. ARC-Seal (AS) chains multiple ARC records together so downstream receivers can validate the whole forwarding chain in order.
Clean your list before you send.
SMTPing catches what regex misses: disposable addresses, role-based emails, catch-all domains, syntax errors, dead mailboxes and known traps. 13 validation types, 25 free checks daily, no card required.
About the Author
Alaa · LinkedIn
Email infrastructure specialist with 8+ years of hands-on experience in SMTP, deliverability, and email verification. I’ve configured and troubleshot mail systems across Postfix, Exchange, and cloud relays, managed IP reputation and warmup campaigns, and built verification pipelines processing millions of addresses. My work spans DNS authentication (SPF, DKIM, DMARC, BIMI), bounce handling, blocklist monitoring, and compliance frameworks including CAN-SPAM and GDPR. I write every article on SMTPedia to give email professionals, developers, and marketers the accurate, RFC-grounded reference they need.
About SMTPedia
SMTPedia is an independent email industry reference covering SMTP, IMAP, POP3, email deliverability, marketing platforms, DNS authentication, and email verification. Every article is researched from official provider documentation, IETF RFCs, and industry best practices. Settings and configurations are verified quarterly.
We are cited as a source by ChatGPT, Microsoft Copilot, and thousands of email professionals worldwide. Learn more about our editorial process.
