What Is ARC? Authenticated Received Chain [2026]

What Is ARC (Authenticated Received Chain)?

ARC (Authenticated Received Chain) is an email authentication protocol that solves a fundamental problem: when messages pass through mailing lists, forwarding services, or security gateways, SPF and DKIM authentication often breaks. ARC preserves the original authentication results so the final receiver can still evaluate the message’s legitimacy.

Without ARC, forwarded mail that was originally legitimate can fail DMARC checks and get rejected or quarantined. ARC creates a verifiable chain of custody, allowing receivers to trust messages that passed authentication at an earlier hop—even if they fail at the final destination.

ARC is defined in RFC 8617, an Experimental RFC published in July 2019. Gmail, Microsoft 365, and Fastmail add and validate ARC headers, but how much weight a receiver gives a chain differs from one provider to the next; see provider support.

The Problem ARC Solves: Email Forwarding Breaks DMARC

Email forwarding creates authentication failures because SPF and DKIM checks happen at the final receiver, not at intermediate hops. Here’s why that’s a problem:

SPF breaks on forwarding:

1. Alice sends email from alice.com (authorized IP: 192.0.2.1)
2. The message arrives at a mailing list at list.org
3. The list forwards it to Bob at bob.com
4. Bob’s server checks SPF—it sees the sending IP is list.org’s server (198.51.100.5), not alice.com’s
5. SPF fails because the IP doesn’t match alice.com’s SPF record

DKIM breaks when messages are modified:

1. Alice’s original message has a valid DKIM signature
2. The mailing list adds a footer: "Unsubscribe: https://list.org/unsub"
3. The message body has changed, so the DKIM signature no longer matches
4. DKIM fails at Bob’s server

The result: Bob’s server sees SPF fail + DKIM fail = DMARC fail. If alice.com has a DMARC policy of p=reject, Bob never receives the legitimate message. For a deeper look at diagnosing these issues, see our DMARC failure troubleshooting guide.

ARC fixes this by capturing and preserving the authentication results from when the message first arrived at list.org, before forwarding broke everything.

How ARC Works (RFC 8617)

Each intermediary in the email path that implements ARC adds three header fields to the message. These headers are numbered with an instance counter (i=1, i=2, etc.), creating a verifiable chain.

When the final receiver evaluates the message:

1. Validate the ARC chain — verify each seal and signature in reverse order (newest to oldest)
2. Check the earliest authentication results — did the message pass SPF/DKIM when it first entered the chain?
3. Factor ARC into the DMARC decision — if the chain is valid and from a trusted intermediary, the receiver may override a DMARC failure

ARC doesn’t replace DMARC. It provides additional context that receivers can use to make better decisions about forwarded mail. You can inspect these chains step-by-step with our ARC chain analyzer.

The Three ARC Header Fields

Each intermediary adds these three headers:

ARC-Authentication-Results

Records the authentication results (SPF, DKIM, DMARC) as evaluated by this intermediary. This is the same format as the standard Authentication-Results header, but prefixed with ARC- and assigned an instance number.

Example:

ARC-Authentication-Results: i=1; list.org;
  spf=pass smtp.mailfrom=alice.com;
  dkim=pass header.d=alice.com header.s=selector1;
  dmarc=pass header.from=alice.com

This shows that when the message arrived at list.org (instance 1), SPF, DKIM, and DMARC all passed.

ARC-Message-Signature

A DKIM-like cryptographic signature covering the message headers and body at this hop. This proves the intermediary evaluated the message in its current state.

Example:

ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;
  d=list.org; s=arc-2024; t=1709251200;
  h=from:to:subject:date:message-id:dkim-signature;
  bh=7aEhL5q3iP... (body hash);
  b=dGhlIHN... (signature)

The d= tag identifies the intermediary (list.org), and the signature covers the message headers and body hash.

ARC-Seal

A signature covering all previous ARC headers (all earlier ARC-Authentication-Results, ARC-Message-Signature, and ARC-Seal headers). This creates the chain of trust.

Example:

ARC-Seal: i=1; a=rsa-sha256; cv=none; d=list.org; s=arc-2024;
  t=1709251200;
  b=aGVhZGVy... (signature covering previous ARC headers)

The cv= (chain validation) tag indicates the validation status of the previous chain:

• cv=none — This is the first hop, no previous chain exists
• cv=pass — The previous ARC chain validated successfully
• cv=fail — The previous chain was broken

To see a complete ARC set read line by line inside a raw header dump, including the cv= value at each hop, follow how to read email headers in trust order.

ARC Chain Structure: A Real-World Example

Here’s what an ARC chain looks like after a message passes through two intermediaries (for a genuine production chain with cv=fail debugging, see this real two-hop ARC chain, header by header):

From: alice@alice.com
To: bob@bob.com
Subject: Team Update
DKIM-Signature: v=1; a=rsa-sha256; d=alice.com; s=selector1; ...

ARC-Seal: i=2; a=rsa-sha256; cv=pass; d=gateway.example; s=arc; ...
ARC-Message-Signature: i=2; a=rsa-sha256; d=gateway.example; s=arc; ...
ARC-Authentication-Results: i=2; gateway.example;
  arc=pass (i=1 spf=pass dkim=pass dmarc=pass);
  spf=pass smtp.mailfrom=list.org;
  dkim=fail reason="body modified"

ARC-Seal: i=1; a=rsa-sha256; cv=none; d=list.org; s=arc-2024; ...
ARC-Message-Signature: i=1; a=rsa-sha256; d=list.org; s=arc-2024; ...
ARC-Authentication-Results: i=1; list.org;
  spf=pass smtp.mailfrom=alice.com;
  dkim=pass header.d=alice.com;
  dmarc=pass header.from=alice.com

[Body: Team update message with list footer added by list.org]

Chain breakdown:

1. Instance 1 (list.org): Message arrived from alice.com with SPF, DKIM, and DMARC all passing. List added ARC headers and forwarded the message.
2. Instance 2 (gateway.example): Security gateway received the message from list.org. It validates the i=1 ARC chain (cv=pass), sees SPF still passes but DKIM now fails (list modified the body). It adds its own ARC headers before delivering to Bob.

When Bob’s server evaluates this message:

• Current SPF/DKIM checks may fail
• But the ARC chain validates back to instance 1, where everything passed
• Bob’s server can trust the message because list.org and gateway.example are trusted ARC sealers

ARC and DMARC: How They Work Together

ARC doesn’t replace DMARC—it informs DMARC decisions. Here’s the relationship:

Without ARC (strict DMARC enforcement):

1. Message arrives at receiver
2. Receiver checks SPF → fail (forwarding broke it)
3. Receiver checks DKIM → fail (message was modified)
4. DMARC fails because both SPF and DKIM failed
5. If sender’s policy is p=reject, message is rejected

With ARC (DMARC + ARC context):

1. Message arrives with ARC chain
2. Receiver validates ARC chain → pass
3. Receiver checks ARC-Authentication-Results at i=1 → SPF/DKIM/DMARC all passed when message first entered the chain
4. Receiver verifies the intermediary is a trusted ARC sealer (e.g., list.org is on the receiver’s allowlist)
5. Receiver overrides the DMARC failure and delivers the message

This is why ARC is critical for mailing lists and forwarding services. It allows legitimate mail to flow even when forwarding breaks SPF and DKIM.

ARC vs DMARC

ARC and DMARC are complementary protocols, not competitors. DMARC (RFC 9989) is a policy protocol: the domain owner publishes a DNS record telling receivers what to do when a message fails SPF and DKIM alignment, and where to send reports. ARC (RFC 8617) is an evidence protocol: intermediaries record the authentication results they observed so the final receiver has context when a forwarded message fails those same checks.

In short: DMARC decides, ARC informs the decision. A valid ARC chain from a trusted sealer can rescue legitimate forwarded mail that would otherwise be rejected under p=reject — but ARC never weakens your policy for mail that was already failing authentication at its first hop. If you own a domain, deploy DMARC; ARC is added for you by the intermediaries your mail passes through.

ARC vs DKIM

Key difference: DKIM is added once by the sender. ARC is added by every intermediary in the chain, creating a cumulative audit trail.

Who Adds ARC Headers?

ARC is implemented by intermediaries that modify or forward email:

• Mailing list servers (Mailman, Listserv, Google Groups, Sympa)
• Email forwarding services (university alumni forwarding, vanity domain forwarding)
• Email security gateways (Mimecast, Proofpoint, Barracuda)
• Cloud email providers (Gmail/Workspace, Microsoft 365, Fastmail)

You don’t configure ARC for your domain. There’s no ARC DNS record. Intermediaries sign ARC headers using their own DKIM keys.

ARC can still surface in your DMARC aggregate reports. There is no ARC element in the report XML. Instead, RFC 8617 §7.2.2 lets a receiver that overrode a DMARC failure because of ARC add a <reason> of type local_policy to that row, with the chain result (for example arc=pass) and the sealing domains in the reason’s <comment>. Reporting it is optional, so a row without a reason does not prove ARC was ignored.

Provider Support for ARC

What the major mailbox providers and list software do with ARC:

Trusted ARC sealers: Receivers maintain allowlists of intermediaries they trust to add accurate ARC headers. If an intermediary isn’t on the allowlist, the receiver may ignore the ARC chain even if it validates cryptographically.

Microsoft 365 lets you configure trusted sealers for your organization. For example, if your company routes inbound mail through a third-party email security gateway, you can add the gateway’s signing domain as a trusted sealer so ARC chains from that gateway are honored. Google Workspace has no equivalent setting: Gmail validates ARC, but which sealers it trusts is decided by Google, not by the Workspace administrator.

Yahoo and Fastmail show how far receivers diverge. Yahoo told the IETF DMARC working group that it has “not been applying ARC headers to any email”, that accepting ARC from other senders “has DECREASED our ability to identify email that our users do not wish to receive”, and that its trusted list is “now extremely short” with no new senders being added. Fastmail adds and verifies ARC but “doesn’t treat it as having any spam prediction value”. A valid chain is evidence a receiver may use, never a guarantee of delivery.

ARC in Microsoft 365 and Gmail

The two largest email providers both add and validate ARC headers, but only Microsoft 365 gives administrators a trusted-sealer list to manage.

Gmail / Google Workspace:

Google adds ARC headers when forwarding messages through Google Groups and other internal routing, and Gmail validates ARC chains on inbound mail. Unlike Microsoft 365, Google Workspace has no administrator setting for trusted ARC sealers: Google’s ARC documentation describes the headers and names no control. The closest-sounding item in the Admin console, Authenticate email (Apps → Google Workspace → Gmail → Authenticate email), only sets up DKIM signing for your own outbound mail. Which sealers Gmail trusts is decided by Google; Google does not document that list and admins cannot add to it.

If a third-party gateway such as Mimecast or Proofpoint sits in front of Google Workspace, the control that matters is the inbound gateway setting, not ARC:

1. Open the Admin console → Apps → Google Workspace → Gmail → Spam, Phishing and Malware
2. In the Inbound gateway setting, add the gateway’s public IP addresses or ranges
3. Optionally turn on Automatically detect external IP. Gmail then scans the Received headers for the first public IP that is not in your gateway list and uses it as the source IP for SPF and spam evaluation. With it off, Gmail looks only one hop back

Gmail does not enforce the sender’s DMARC policy on messages that arrive from a configured inbound gateway, so make sure the gateway itself enforces DMARC.

Microsoft 365 / Exchange Online:

Microsoft 365 adds ARC headers during message routing and validates incoming chains. To add trusted ARC sealers:

1. Open the Microsoft Defender portal (security.microsoft.com) → Email & collaboration → Policies & rules → Threat policies
2. Under Rules, open Email authentication settings → ARC tab → Add, and enter the sealer’s signing domain. It must match the d= value in the gateway’s ARC-Seal and ARC-Message-Signature headers
3. Alternatively, use PowerShell: Set-ArcConfig -Identity default -ArcTrustedSealers "gateway.example.com". -ArcTrustedSealers replaces the whole list, so include the sealers you already trust when adding a new one

This is critical if you route email through a third-party security gateway (like Mimecast or Proofpoint) before delivery to Microsoft 365. Without adding the gateway as a trusted sealer, ARC chains from that gateway may be ignored, and legitimate forwarded mail could fail DMARC. When Mimecast is the gateway and inbound mail is being held with “DNS Authentication: DMARC Fail”, the Mimecast-side diagnosis and the Microsoft 365 trusted-sealer fix are covered end to end in fixing DMARC fail in Mimecast.

Who Should Implement ARC

ARC is implemented by intermediaries, not domain owners. If you run any of these services, you should add ARC signing:

• Mailing list servers — Mailman 3.2+, Sympa, and Google Groups already add ARC. If you run a self-hosted list, ensure your software supports ARC or upgrade to a version that does.
• Email forwarding services — University alumni forwarding, vanity domain forwarding, or any .forward relay that changes the envelope sender.
• Email security gateways — Any service that sits between the internet and the recipient’s mail server, modifying headers or scanning content.
• Internal email routing — Organizations that route mail through multiple internal hops (e.g., compliance scanning → DLP → delivery) should add ARC at each hop.

If you’re a domain owner (sending email from your domain), you don’t need to implement ARC. Focus on SPF, DKIM, and DMARC instead. You’ll benefit from ARC passively — when receivers see a valid ARC chain on forwarded mail from your domain, they’ll be more likely to deliver it even if current SPF/DKIM checks fail. To see how your domain handles forwarded mail today, test your domain’s ARC readiness.

Troubleshooting ARC Failures

When ARC chains fail validation (cv=fail), messages lose the benefit of preserved authentication results. Common causes and fixes:

1. DKIM key rotation broke the chain

If the intermediary rotated its DKIM key after signing the ARC headers, the old public key may no longer be published in DNS. The receiver can’t verify the ARC-Message-Signature or ARC-Seal.

Fix: Publish old DKIM keys for at least 7 days after rotation. Use a different selector for ARC signing than for outbound DKIM to allow independent key management.

2. Clock skew between servers

ARC signatures include a timestamp (t=). If the signing server’s clock is significantly different from the verifying server’s, the signature may be rejected.

Fix: Ensure all mail servers use NTP for time synchronization. Most receivers allow a tolerance of several minutes, but larger discrepancies cause failures.

3. An intermediary modified the message after ARC signing

If a hop adds or modifies headers after the ARC-Message-Signature was computed, the signature breaks. This commonly happens with spam filters or content scanners that run after ARC signing.

Fix: ARC signing must happen last in the message processing pipeline. If your gateway adds headers (like X-Spam-Status), ensure ARC signing occurs after all modifications.

4. Missing or out-of-order ARC headers

Each instance must have exactly three headers (ARC-Authentication-Results, ARC-Message-Signature, ARC-Seal) with matching instance numbers. If any header is missing or the numbering is inconsistent, the chain fails.

Fix: Verify that your ARC implementation adds all three headers with the correct instance number. Check for intermediaries that strip or reorder headers.

When ARC Doesn’t Help

ARC has limitations:

1. The intermediary doesn’t implement ARC

If the mailing list or forwarder doesn’t add ARC headers, there’s no chain to validate. The message will fail DMARC like it always did.

2. The receiver doesn’t trust the sealer

Even if the ARC chain validates, if the receiver doesn’t recognize the intermediary as a trusted sealer, it may ignore the chain. This is a policy decision, not a technical failure.

3. The chain is broken (cv=fail)

If any seal or signature in the chain is invalid, the entire chain fails. Common causes:

• An intermediary modified the message after adding ARC headers
• Clock skew caused signature timestamps to be rejected
• A DKIM key was rotated and the old public key is no longer published

4. The original message failed authentication

If the message failed SPF/DKIM/DMARC when it first arrived at the intermediary (i=1), ARC preserves that failure. A valid ARC chain with i=1 showing dmarc=fail won’t help—it just proves the message was already failing authentication before forwarding.

ARC’s Standing at the IETF

RFC 8617 is an Experimental RFC, not an Internet Standard. The IETF DMARC working group has adopted a draft, Reclassifying ARC as Historic, that would obsolete it. That draft has not been approved, so RFC 8617 remains the current specification. DKIM2, the successor the IETF DKIM working group is drafting, is designed to address the shortcomings of ARC and builds its own per-hop chain of custody on that experience.

None of this changes what receivers do with a chain today: Gmail and Microsoft 365 still validate ARC, and the Microsoft 365 trusted-sealer list still decides whether a gateway’s chain is honored. For the timeline and the objections, see whether ARC is being deprecated; for what replaces it, see DKIM2 explained.

Frequently Asked Questions

What is Authenticated Received Chain (ARC)?

ARC is an email authentication protocol defined in RFC 8617 that preserves authentication results as messages pass through intermediaries like mailing lists, forwarding services, or email security gateways. It creates a verifiable chain of custody using three header fields: ARC-Authentication-Results, ARC-Message-Signature, and ARC-Seal.

How does ARC fix DMARC failures from forwarding?

When email passes through a forwarding service or mailing list, SPF and DKIM often break. ARC captures the original authentication results before the message is modified, allowing the final receiver to see that the message was legitimate when it entered the forwarding chain, even if current SPF/DKIM checks fail.

What is the difference between ARC and DKIM?

DKIM signs the original message to verify the sender’s identity, but the signature breaks if the message is modified during forwarding. ARC doesn’t replace DKIM — it preserves the original DKIM result and adds a chain of signatures from each intermediary, creating a verifiable audit trail through the forwarding path.

Does Gmail support ARC?

Yes. Gmail and Google Workspace both support ARC. Google adds ARC headers when forwarding messages and validates ARC chains on incoming mail. If a message fails DMARC but has a valid ARC chain from a trusted sealer, Gmail may deliver it instead of rejecting it. Google Workspace administrators cannot choose which ARC sealers Gmail trusts; there is no trusted-sealer setting in the Admin console.

Do I need to configure ARC for my domain?

No. Individual domain owners don’t configure ARC. It’s implemented by intermediaries (mailing lists, forwarding services, email security gateways) that modify or relay messages. A receiver that overrides a DMARC failure because of ARC can note it in your DMARC aggregate reports, but you don’t need to set up DNS records or manage ARC signing yourself.

Is ARC the same as DMARC?

No. DMARC is a policy protocol that tells receivers what to do when SPF or DKIM fails. ARC preserves authentication results through forwarding chains so receivers have additional context when making DMARC decisions. ARC doesn’t replace DMARC — it supplements it by solving the forwarding problem that causes legitimate mail to fail DMARC checks.

What is a trusted ARC sealer?

A trusted ARC sealer is an intermediary (like a mailing list or email gateway) whose ARC signatures a receiver has chosen to honor. Receivers maintain allowlists of trusted sealers. If the intermediary isn’t on the list, the receiver may ignore the ARC chain even if it validates cryptographically. Microsoft 365 lets administrators manage their own trusted sealer list. Gmail decides sealer trust internally and offers no admin setting for it.

Does Microsoft 365 support ARC?

Yes. Microsoft 365 and Exchange Online add ARC headers when forwarding messages and validate incoming ARC chains. You can configure trusted ARC sealers in Exchange Online using PowerShell (Set-ArcConfig -Identity default -ArcTrustedSealers "gateway.example.com") or the Microsoft Defender portal. This is important if you use third-party email security gateways that modify messages before delivery.

What does ARC-Authentication-Results i=1 mean?

The i=1 in ARC-Authentication-Results indicates this is the first instance in the ARC chain — the first intermediary that processed the message. The instance number increments at each hop (i=2, i=3, etc.). The i=1 results are the most important because they show the authentication state when the message first entered the forwarding chain, before any modifications could break SPF or DKIM.

Is ARC required for email authentication?

No. ARC is not required and has no DNS records to configure. It’s an optional protocol implemented by email intermediaries to preserve authentication results through forwarding. However, if your organization uses mailing lists or email forwarding and you’ve set a DMARC policy of p=quarantine or p=reject, ARC from trusted intermediaries prevents legitimate forwarded mail from being blocked.

Related Protocols

• DMARC — ARC provides context for DMARC policy decisions on forwarded mail
• SPF — ARC preserves original SPF results when forwarding breaks SPF alignment
• DKIM — ARC preserves original DKIM results when message modification breaks DKIM signatures