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.
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
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
- A mail server receives a message.
- It checks SPF, DKIM and DMARC.
- It records those results in ARC headers.
- It seals the ARC chain with a signature.
- It forwards or processes the message.
- 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
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.
Common problems
Forwarded mail fails SPF
MediumThe 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
MediumSubject 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
LowThe forwarding service or gateway may not support ARC.
Next step: Check whether the forwarding platform supports ARC signing.
ARC chain is broken
MediumA 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
MediumARC only helps if the final receiver trusts the intermediate system.
Next step: Use reputable forwarding or gateway providers.
ARC expected to fix bad authentication
HighARC cannot replace SPF, DKIM or DMARC.
Next step: Fix primary authentication first.
Domain owner tries to add ARC in DNS
LowARC 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
-
Step 1: Fix SPF, DKIM and DMARC first
ARC should not be used as a substitute for core email authentication.
-
Step 2: Identify forwarding or gateway systems
Find where messages are forwarded, filtered, rewritten or resent.
-
Step 3: Check message headers
Look for ARC headers and compare original and final authentication results.
-
Step 4: Use providers that support ARC
If forwarding is important, choose reputable platforms that support modern authentication handling.
-
Step 5: Preserve DKIM where possible
Avoid unnecessary message modifications that break DKIM signatures.
-
Step 6: Review DMARC reports
Use reports to see whether failures are caused by forwarding, third-party senders or spoofing.
-
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
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.
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.
Related tools
Use these free tools to verify your configuration after applying changes.
Related guides
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.
Was this guide helpful?
Your feedback helps us improve our guides for everyone.
Thanks for your feedback!