What Is ARC and Do You Need It

Learn what ARC is, how it helps preserve email authentication results during forwarding, and when domain owners, mail providers or gateways may need it.

By CheckDomainHealth Editorial Team Reviewed by Dionis Ceban Updated Jun 28, 2026 8 min read Advanced

Introduction

ARC, or Authenticated Received Chain, is an email authentication mechanism designed to preserve authentication results as a message passes through forwarding services, mailing lists, gateways or filters.

ARC is not a replacement for SPF, DKIM or DMARC. It is an additional layer that helps receivers understand whether a message was authenticated before it was forwarded or modified. Most normal domain owners do not need to configure ARC directly, but it can matter for mail providers, forwarders, security gateways and mailing-list systems.

Quick answer

Quick answer

ARC helps preserve SPF, DKIM and DMARC authentication results when an email is forwarded or processed by an intermediate system. Most businesses should focus first on SPF, DKIM and DMARC. ARC is mainly relevant for mailbox providers, forwarders, mailing lists and email security gateways.

What is ARC?

ARC stands for Authenticated Received Chain. It allows an intermediate mail server to record the authentication results it saw when it received a message, then seal that information before forwarding the message onward.

ARC can help the final receiver answer questions like:

  • Did SPF pass before forwarding?
  • Did DKIM pass before the message was modified?
  • Did DMARC pass at an earlier step?
  • Which intermediate system handled the message?

ARC is most useful when forwarding or message modification causes SPF, DKIM or DMARC to fail later.

Why ARC exists

Forwarding can break normal authentication.

Example: A message from example.com passes SPF, DKIM and DMARC when it reaches a forwarding service. The forwarding service then sends it to another mailbox. The final receiver sees the forwarding server IP, not the original sending server, so SPF may fail. If the message was modified, DKIM may also fail.

ARC helps by letting the forwarding system preserve the earlier authentication result.

ARC does not automatically make bad mail trusted. Receivers still decide whether to trust the ARC chain.

How ARC works

  1. A mail server receives a message.
  2. It checks SPF, DKIM and DMARC.
  3. It records those results in ARC headers.
  4. It seals the ARC chain with a signature.
  5. It forwards or processes the message.
  6. The next receiver can review the ARC chain.

ARC creates a chain of custody for authentication results as the message passes through trusted intermediaries.

ARC headers

ARC-Authentication-Results

Shows authentication results observed by the intermediate server.

ARC-Message-Signature

Signs parts of the message and ARC information.

ARC-Seal

Seals the ARC set and helps preserve the chain.

Most users do not manually edit ARC headers. They are added by mail servers, forwarding systems or security gateways that support ARC.

When ARC is useful

Email forwarding

Forwarded mail may fail SPF because the final receiver sees the forwarder’s IP.

Mailing lists

Mailing lists may modify subject lines, footers or headers, which can break DKIM.

Email security gateways

Gateways may scan, rewrite or route messages before final delivery.

Mailbox providers

Large providers can use ARC to evaluate authentication history.

Helpdesk systems

Support platforms may process and resend messages in ways that affect authentication.

ARC is most useful when an intermediate system is trusted and handles mail responsibly.

Do you need ARC?

Most ordinary domain owners do not need to configure ARC directly.

You probably do not need to configure ARC if:

  • You only send normal business email
  • You use Google Workspace, Microsoft 365 or a standard email provider
  • You are still setting up SPF, DKIM and DMARC
  • You do not operate forwarding or gateway infrastructure

You may need to care about ARC if:

  • You run a forwarding service
  • You operate a mailing list
  • You manage an email security gateway
  • You run a mailbox provider
  • You process and resend email at scale
  • Forwarded messages commonly fail DMARC

For most businesses, the priority is SPF, DKIM, DMARC and proper provider authentication before ARC.

Why this matters

Why this matters

ARC matters because legitimate forwarded email can fail SPF, DKIM or DMARC after passing through intermediate systems. Without ARC, the final receiver may not have a reliable way to see that the message passed authentication before forwarding.

However, ARC is not a deliverability shortcut. A receiver must trust the ARC-sealing system, and bad senders cannot simply use ARC to bypass authentication.

How to check ARC

ARC is usually checked in message headers, not only DNS records.

When checking ARC, review

These five checks help evaluate ARC in real messages.

Message headers

Look for ARC-Seal, ARC-Message-Signature and ARC-Authentication-Results.

Forwarding path

Check whether the message passed through a forwarder, gateway or mailing list.

Original authentication

Review SPF, DKIM and DMARC results before forwarding.

Final authentication

Check whether SPF, DKIM or DMARC failed after forwarding.

Trusted intermediary

Decide whether the ARC-sealing system is a trusted mail handler.

Check DMARC first

Use DMARC Checker to confirm your SPF, DKIM and DMARC foundation before worrying about ARC.

Run DMARC Check →

Common problems

Forwarded mail fails SPF

Medium

The final receiver sees the forwarder’s IP instead of the original sending IP.

Next step: Use DKIM and DMARC alignment where possible. ARC may help receivers evaluate the original authentication result.

Mailing list modifies message

Medium

Subject tags, footers or header changes can break DKIM.

Next step: Use mailing-list settings that preserve DKIM where possible, or rely on trusted ARC handling.

ARC headers missing

Low

The forwarding service or gateway may not support ARC.

Next step: Check whether the forwarding platform supports ARC signing.

ARC chain is broken

Medium

A receiver may not trust the ARC chain if signatures are invalid or incomplete.

Next step: Review the intermediate mail systems and header integrity.

Receiver does not trust ARC signer

Medium

ARC only helps if the final receiver trusts the intermediate system.

Next step: Use reputable forwarding or gateway providers.

ARC expected to fix bad authentication

High

ARC cannot replace SPF, DKIM or DMARC.

Next step: Fix primary authentication first.

Domain owner tries to add ARC in DNS

Low

ARC is not normally configured as a simple DNS TXT record by domain owners.

Next step: Configure ARC only in mail server, gateway or forwarding software if you operate that infrastructure.

How to approach ARC

  1. Step 1: Fix SPF, DKIM and DMARC first

    ARC should not be used as a substitute for core email authentication.

  2. Step 2: Identify forwarding or gateway systems

    Find where messages are forwarded, filtered, rewritten or resent.

  3. Step 3: Check message headers

    Look for ARC headers and compare original and final authentication results.

  4. Step 4: Use providers that support ARC

    If forwarding is important, choose reputable platforms that support modern authentication handling.

  5. Step 5: Preserve DKIM where possible

    Avoid unnecessary message modifications that break DKIM signatures.

  6. Step 6: Review DMARC reports

    Use reports to see whether failures are caused by forwarding, third-party senders or spoofing.

  7. Step 7: Configure ARC only if you operate the mail system

    If you run a gateway, forwarder or mailing list, configure ARC in the mail software according to that platform’s documentation.

ARC example

Forwarding scenario
Original sender:
newsletter@example.com

First receiver / forwarder:
forwarder.example.net

Original authentication:
SPF: pass
DKIM: pass
DMARC: pass

After forwarding:
SPF: fail
DKIM: pass or fail
DMARC: may fail

ARC role:
The forwarder can record and seal the original authentication results so the final receiver can review them.
Example ARC headers
ARC-Authentication-Results:
ARC-Message-Signature:
ARC-Seal:

This is a simplified example. Real ARC headers are longer and should be evaluated by receiving mail systems or email security tools.

ARC vs SPF/DKIM/DMARC

SPF

Authorizes sending servers for a domain.

DKIM

Signs outgoing messages.

DMARC

Checks SPF/DKIM alignment with the visible From domain.

ARC

Preserves authentication results across forwarding or intermediate handling.

ARC works after normal authentication. It does not replace normal authentication.

Frequently asked questions

What is ARC in email?

ARC is Authenticated Received Chain. It helps preserve email authentication results when a message is forwarded or processed by intermediaries.

Does ARC replace SPF, DKIM or DMARC?

No. ARC depends on normal authentication results and helps preserve them across forwarding.

Do normal domain owners need ARC?

Usually no. Most businesses should focus first on SPF, DKIM and DMARC.

Who should use ARC?

Forwarding services, mailbox providers, mailing lists, gateways and platforms that process or resend mail may benefit from ARC.

Can ARC fix DMARC failures?

ARC may help receivers understand why forwarded mail failed DMARC, but it does not guarantee acceptance.

Is ARC configured in DNS?

Usually no. ARC is implemented by mail servers, forwarding systems or security gateways, not as a normal DNS record.

Why does forwarded email fail authentication?

Forwarding can change the sending IP or modify the message, causing SPF or DKIM to fail at the final receiver.

Use these free tools to verify your configuration after applying changes.

Browse all Email Authentication guides →

Need help applying this fix?

Send us your domain, report link or issue details. CheckDomainHealth will review the request and route it to the right technical team if hands-on support is needed.

Get Help Run Domain Health Check

Was this guide helpful?

Your feedback helps us improve our guides for everyone.