ARC Authentication Chain Guide [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 and is supported by major email providers including Gmail, Microsoft 365, Yahoo, and Fastmail.

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

ARC Chain Structure: A Real-World Example

Here’s what an ARC chain looks like after a message passes through two intermediaries:

From: [email protected]
To: [email protected]
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 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, Yahoo)

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

However, you’ll see ARC results in your DMARC aggregate reports. Look for <arc> tags in the XML reports—they show whether messages were delivered based on ARC chain validation.

Provider Support for ARC

Major email providers that add and validate 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.

Google and Microsoft allow you to configure trusted sealers for your organization. For example, if your company uses a third-party email security gateway, you can add it as a trusted sealer so ARC chains from that gateway are honored.

ARC in Microsoft 365 and Gmail

The two largest email providers both fully support ARC, but configure trusted sealers differently.

Gmail / Google Workspace:

Google adds ARC headers when forwarding messages through Google Groups and other internal routing. To configure trusted ARC sealers in Google Workspace:

1. Open the Admin Console → Apps → Google Workspace → Gmail → Authentication
2. Add the intermediary’s signing domain to the “ARC Trusted Sealers” list
3. Gmail will honor ARC chains signed by those domains when evaluating DMARC results

Google automatically trusts ARC chains from well-known intermediaries. You only need to add custom sealers for third-party gateways specific to your organization.

Microsoft 365 / Exchange Online:

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

1. Open Microsoft 365 Defender → Email & collaboration → Policies → Threat policies
2. Under “Email authentication settings,” add trusted ARC sealer domains
3. Alternatively, use PowerShell: Set-ArcConfig -Identity default -ArcTrustedSealers "gateway.example.com"

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.

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.

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.

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.

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. You’ll see ARC results 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. Gmail and Microsoft 365 both allow administrators to configure their trusted sealer lists.

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 365 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