How to implement ARC (Authenticated Received Chain) and how does it affect DMARC failures from forwarding?
Published 21 Jul 2025
Updated 12 Aug 2026
11 min read
Summarize with
Updated on 12 Aug 2026: We updated this guide for RFC 9989 and clearer ARC validation and reporting guidance.
If you are the original sender, you usually do not implement ARC to fix forwarding-related DMARC failures. ARC is added by the system that receives, forwards, relays, or modifies mail. That system records what SPF, DKIM, and DMARC looked like before it changed the message path.
Treat ARC as evidence, not as a sender-side repair. It does not make DMARC pass. It gives the final receiver a signed chain showing that a trusted intermediary saw valid authentication before forwarding. The receiver then decides whether to accept that evidence.
- Sender-side answer: If you send campaigns through SFMC or another ESP, there is no ARC switch that stops recipient auto-forwards from failing DMARC.
- Forwarder-side answer: If you operate a forwarder, mailing list, helpdesk relay, or inbound gateway, that is where ARC belongs.
- DMARC impact: ARC can lead to a receiver policy override, but the DMARC result itself can still show fail in reports.
- Immediate work: Make your own DKIM, SPF, and DMARC setup clean, then use reports to separate real sender issues from normal forwarding noise.
Direct answer
To implement ARC, you need control of the mail system that receives a message and then sends it onward. That system validates the inbound message, writes ARC-Authentication-Results, signs the message with ARC-Message-Signature, then seals the current chain with ARC-Seal. The header format is defined in RFC 8617. Each ARC set has one of each header, and all three share the same sequential instance number.
If your problem is automated recipient forwarding, your sender platform cannot add meaningful ARC after the fact. The forwarding system has to add it because ARC is a statement about what happened at that intermediary hop. A sender stamping ARC on its own outbound mail is not useful for recipient forwarding, because there is no prior hop to preserve.
Do not chase ARC in the wrong place
When a recipient auto-forwards your message, SPF often fails because the forwarding server is not in your SPF record. DKIM survives only if the forwarder leaves the signed content intact. DMARC then fails if neither SPF nor DKIM passes with a domain matching the visible From domain.
- Do: Check whether your normal outbound mail passes before forwarding.
- Do: Track aggregate reports and policy overrides in a DMARC monitoring workflow.
- Do not: Assume ARC will remove every forwarded failure from reports.
For a deeper sender-side playbook on this exact failure pattern, keep a separate checklist for forwarded DMARC failures.
What ARC changes in forwarded mail
Forwarding changes the authentication question. The final receiver is no longer seeing mail directly from the sender's approved infrastructure. ARC lets each intermediary say what it saw when it handled the message, then sign that statement so the next receiver can verify the chain.
Flowchart showing ARC sealing at a forwarding hop before final delivery.
The important detail is that ARC does not rewrite the original authentication result. If SPF broke because of forwarding, SPF still broke. If DKIM broke because a list footer changed the body, DKIM still broke. ARC adds context that helps the receiver decide whether the failure is acceptable.
Without ARC
- SPF: The final receiver sees the forwarder's IP, not the original sender's approved IP.
- DKIM: The signature passes only if the forwarded message content stayed intact.
- DMARC: The receiver has limited evidence that the message was valid before forwarding.
With trusted ARC
- SPF: The final SPF result can still fail after forwarding.
- DKIM: DKIM can pass or fail, depending on message changes.
- DMARC: The receiver can use the ARC chain as local policy evidence.
Representative ARC headerstext
ARC-Authentication-Results: i=1; mx.forwarder.example; spf=pass smtp.mailfrom=sender.example dkim=pass header.d=sender.example dmarc=pass header.from=sender.example ARC-Message-Signature: i=1; a=rsa-sha256; d=forwarder.example; s=arc1; bh=...; b=... ARC-Seal: i=1; a=rsa-sha256; d=forwarder.example; s=arc1; cv=none; b=...
When you should implement ARC
You should implement ARC when your system is an intermediary. That means you receive mail, make a forwarding or relay decision, then send the message onward. The common cases are mailbox forwarding, mailing lists, inbound security gateways, helpdesk reply forwarding, and routing systems that preserve the original From address.
|
|
|
|---|---|---|
Original sender | Usually none | No prior hop to seal |
Forwarder | Seal chain | It changes the route |
Mailing list | Seal after checks | It changes content |
Receiver | Trust sealers | It decides policy |
ARC ownership by role
Recipient administrators also have an ARC-related task: deciding which sealers they trust. In Microsoft 365, admins can configure trusted ARC sealers so local policy can consider ARC results for known intermediaries. Match the configured domain to the d= value in ARC-Seal, and trust only services that the organization uses and has verified.
SFMC and similar ESPs
If your ESP is only sending your original marketing or transactional mail, ARC is not the missing setting. The ESP should sign DKIM correctly, use a proper MAIL FROM setup for SPF where supported, and send compliant mail. ARC only becomes relevant for the ESP if it also runs a forwarding path, such as reply forwarding or inbound relay handling.
How to implement ARC if you control the forwarder
If you do control the forwarding infrastructure, the job is closer to DKIM signing than to adding a DNS-only record. You need cryptographic signing, a selector key, stable header handling, and receiver testing.
- Place: Add ARC at the outbound edge of the forwarder after all message and header changes, but before delivery onward.
- Verify: Run SPF, DKIM, and DMARC checks on the message as received, then validate any existing ARC chain.
- Record: Write ARC-Authentication-Results with the observed results and the next continuous i= instance number.
- Sign: Add ARC-Message-Signature over the selected headers and message body, using the same instance number.
- Seal: Add ARC-Seal with cv=none at i=1, cv=pass when the prior chain validates, or cv=fail when it does not.
- Publish: Publish the public key for the ARC selector under the signing domain's _domainkey namespace.
- Test: Send real forwarded messages, inspect the full header sets, confirm continuous instance numbers, and compare DMARC report patterns.
ARC selector key shapedns
arc1._domainkey.forwarder.example. TXT "v=DKIM1; k=rsa; p=MIIB..."
A failed ARC chain does not repair itself at a later hop. Receivers have no reason to use it as trustworthy authentication context. Authenticate the inbound message before sealing, make every content change before sealing, and keep the selector key available in DNS.
What senders should do instead
If you are the sender seeing forwarded DMARC failures, the practical fix is not ARC. First, prove that direct mail passes. Then look at forwarded traffic as a reporting and policy problem.
Start with a domain health check for the sending domain, then validate the live record with a DMARC checker. The goal is to rule out simple sender-side failures before treating forwarding as the cause.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
Once the basics pass, look at aggregate XML reports. Forwarding often appears as DMARC fail with a policy override, especially after a domain moves beyond p=none. If the receiver applies local policy, the message can be accepted even when the reported SPF and DKIM domain-match results say fail.
Example DMARC policy states under RFC 9989dns
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com v=DMARC1; p=quarantine; t=y; rua=mailto:dmarc-reports@example.com v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com v=DMARC1; p=reject; t=y; rua=mailto:dmarc-reports@example.com v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com
RFC 9989 removed pct, so pct=25 is no longer a current rollout method. Its t=y tag requests test mode before enforcement. The RFC also advises against p=reject on general-purpose email domains, so choose the policy according to how the domain is used and what its reports show.
- Confirm: Direct sends pass DKIM with your visible From domain.
- Separate: Group failures by source IP, reporter, and policy override reason.
- Stabilize: Keep DKIM signatures resilient by avoiding content changes after signing.
- Stage: Use monitoring and test mode before applying quarantine or reject to a controlled sending domain.
How ARC changes DMARC reporting
ARC affects delivery decisions more than it affects the basic DMARC pass or fail line. Forwarded messages can still appear as DMARC failures in reports. The useful question is whether the receiver changed the disposition because it trusted an intermediary.
Standard DMARC aggregate reports require SPF and DKIM results, but they do not require a standalone ARC result. A reporter can put ARC details in a policy override comment or an extension. Confirm arc=pass in the received message's Authentication-Results header when you need evidence that the chain itself validated.
|
|
|
|---|---|---|
DMARC fail | Final domain match failed | Check source |
Override reason | Receiver changed disposition | Track trend |
ARC detail | Reporter supplied context | Confirm in headers |
No override | Published policy applied | Review risk |
Forwarding signals in reports
How to triage forwarded failures
Use these bands as operational buckets for investigation, not as a universal deliverability score.
Known forwarding
Monitor
Failures map to expected consumer or business forwarding paths.
Unknown source
Investigate
The source does not match any approved sender or known forwarder.
Direct failure
Fix first
Mail fails before any forwarding or policy override appears.
Override accepted
Track
Receiver policy allowed the message despite a DMARC fail result.
The key reporting mistake is treating every forwarded fail as proof that your DMARC program is broken. Some of that traffic is normal. The risk is missing the sources that fail before forwarding, fail without any override, or use your domain without permission.
Suped workflow for ARC and forwarding
Suped's product turns aggregate DMARC XML into sending sources, authentication results, policy effects, and guided fixes. For ARC-related forwarding, use those views to distinguish sender-owned failures from intermediary behavior that the original sender cannot change.
In Suped, review the sending source, DKIM result, SPF result, DMARC result, and any policy override reason before classifying a failure as sender-owned or forwarding-owned. For teams that want less DNS handling, Hosted DMARC supports policy changes without repeated manual record edits.
DMARC records drawer showing filters, record rows, authentication results, and CSV export
The workflow keeps SPF, DKIM, and blocklist (blacklist) signals separate. An ARC pass can explain a trusted forwarding override, but it does not prove that the sending source has a clean reputation.
Practical Suped checks
- Sources: Identify whether failures come from approved senders, forwarders, or unknown infrastructure.
- Issues: Use automated issue detection and guided fix steps for sender-owned problems.
- Alerts: Catch sudden authentication drops instead of waiting for a manual report review.
- Policy: Test DMARC policy changes while watching forwarding-related failure patterns.
Views from the trenches
Best practices
Separate sender authentication problems from forwarder effects before changing policy or DNS.
Monitor aggregate XML reports so policy overrides and forwarding patterns are visible.
Ask forwarders to seal mail only when they validate the message before modifying it.
Common pitfalls
Treating ARC as a sender-side switch wastes time when the sender has no inbound hop.
Reading every DMARC fail as a sender fault hides normal forwarding and local policy.
Expecting ARC to force delivery ignores that receivers decide which sealers to trust.
Expert tips
Keep DKIM stable through forwarding by avoiding body changes before the next hop.
Use policy overrides in reports to separate accepted forwarded mail from rejected mail.
Test ARC with real forwarded messages because header-only checks miss receiver trust.
Marketer from Email Geeks says ARC belongs on the forwarding or mailing list system, not on the original sender's outbound platform.
2024-01-19 - Email Geeks
Marketer from Email Geeks says an ESP only needs ARC when it also runs a forwarding path, such as reply forwarding.
2024-01-19 - Email Geeks
The practical answer
If you are sending mail, do not spend the project trying to add ARC to outbound campaigns as a fix for recipient forwarding. Spend it making direct authentication clean, choosing a DMARC policy that fits the domain's use, and reading reports carefully enough to separate forwarding from abuse.
If you operate the forwarder, ARC is worth implementing because you are the system that can preserve the original authentication state. If you operate the receiver, ARC is useful only when you trust the sealer and your local policy is ready to use that evidence.
For most sender teams, the useful answer is simpler: fix what you control, monitor what you cannot control, and avoid treating normal forwarding failures as proof that the sending platform needs ARC.
