How to implement ARC (Authenticated Received Chain) and how does it affect DMARC failures from forwarding?
Published 21 Jul 2025
Updated 20 Oct 2026
11 min read
Summarize with
Updated on 20 Oct 2026: We clarified ARC setup and validation, added an SRS comparison, and corrected DMARC reporting and test-mode 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.
ARC preserves signed authentication history. It does not make DMARC pass. The chain records what intermediaries observed, including failures. The final receiver decides whether to trust those results and apply a policy override.
- If you send campaigns through SFMC or another ESP, there is no ARC switch that stops recipient auto-forwards from failing DMARC.
- If you operate a forwarder, mailing list, helpdesk relay, or inbound gateway, that is where ARC belongs.
- ARC can lead to a receiver policy override, but the DMARC result itself can still show fail in reports.
- Make your own DKIM, SPF, and DMARC setup clean, then use reports to separate real sender issues from normal forwarding noise.
How ARC sealing works
To implement ARC for forwarding, you need control of the mail system that receives a message and then sends it onward. That system checks authentication on receipt, completes its message changes, writes ARC-Authentication-Results, signs the outgoing message with ARC-Message-Signature, then seals the chain with ARC-Seal. The protocol is defined in RFC 8617. Each ARC set has one of each header, and all three share the same sequential instance number. RFC 8617 remains an Experimental RFC.
Your sending platform cannot record what a later recipient forwarder received. That intermediary must add its own ARC set. A sender's existing ARC set does not replace authentication checks and sealing at the forwarding hop.
Why forwarding causes DMARC failures
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.
- Check whether your normal outbound mail passes before forwarding.
- 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. This applies to automatic forwarding and mailing-list redistribution that retain the original From address. A manual forward that creates a new outer message authenticates that new message separately.
ARC forwarding flow: original sender, first receiver, ARC seal, forwarded hop, and final receiver.
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 checks the forwarder's IP instead of the original sender's approved IP.
- DKIM can survive forwarding if the signed headers and body remain valid under its canonicalization rules.
- DMARC fails if neither passing SPF nor passing DKIM has the required domain match with the visible From domain.
With trusted ARC
- The final SPF result can still fail after forwarding.
- DKIM can pass or fail, depending on changes to signed content.
- The receiver can use a validated ARC chain from a trusted sealer as evidence for a local policy override.
Abbreviated ARC header set, not a complete signaturetext
ARC-Seal: i=1; a=rsa-sha256; d=forwarder.example; s=arc1; cv=none; b=... ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=forwarder.example; s=arc1; h=from:to:subject:date:message-id; bh=...; b=... 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
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 | Cannot control later recipient forwarding |
Forwarder | Seal chain | It changes the route |
Mailing list | Check before changes, seal afterward | It changes content |
Receiver | Validate chains and assess 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. An arc=pass result verifies chain validity; it does not establish that the sealer's authentication claims are accurate or trusted.
SFMC and similar ESPs
If your ESP is only sending your original marketing or transactional mail, focus on correct DKIM signing and a MAIL FROM domain that matches the visible From domain for SPF where supported. ARC sealing becomes relevant when the ESP also runs a forwarding path, such as reply forwarding or inbound relay handling.
How to implement ARC if you control the forwarder
If you control the forwarding infrastructure, enable ARC signing and validation in the mail server or its supported ARC module. Configure a signing domain, selector, and private key. A DNS record alone does not enable ARC.
- Configure ARC signing and validation in the forwarder, using authentication results generated by your own trusted inbound checks.
- Publish the ARC selector's public key under the signing domain's _domainkey namespace before enabling signing.
- Run SPF, DKIM, and DMARC checks on the message as received, then validate any existing ARC chain before modifying the message.
- Complete every message and header change, including any local DKIM signing, before adding the new ARC set.
- Write ARC-Authentication-Results with the recorded inbound results and the next continuous i= instance number, starting at i=1.
- Add ARC-Message-Signature over the outgoing signed headers and message body, using the same instance number.
- Add ARC-Seal with cv=none at i=1, cv=pass when the prior chain validates, or cv=fail when an existing chain fails validation.
- Test unchanged forwarding and a mailing-list footer through the real delivery path. Inspect the final receiver's Authentication-Results and override decision; successful delivery alone does not prove ARC was used.
ARC selector key shape, replace with a real public keydns
arc1._domainkey.forwarder.example. TXT "v=DKIM1; k=rsa; p=MIIB..."
A failed ARC chain cannot be repaired at a later hop. Treat it as absent for ARC-based overrides, and do not delete it to restart at i=1. A non-ARC hop does not automatically break the chain, but changing signed content without adding a new ARC set can break validation. See RFC 8617 for the sealing and validation rules.
ARC vs. SRS for forwarded DMARC failures
Sender Rewriting Scheme (SRS) rewrites the SMTP MAIL FROM, often shown as Return-Path, so a forwarder can pass SPF using its own domain. It leaves the visible From address unchanged. That SPF pass usually does not satisfy DMARC for the original sender because the domains do not match. Microsoft's SRS documentation explains this limitation.
ARC preserves signed authentication history. A forwarder can use SRS and ARC together: SRS handles the envelope sender, while ARC supplies evidence for receiver policy decisions when the original DKIM signature no longer passes. If DKIM still passes with the required match to the visible From domain, DMARC can pass without an ARC override.
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.
Alternative DMARC policy records, publish only onedns
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 marks pct as historic. Its t=y test mode requests one level less enforcement: p=quarantine requests none, while p=reject requests quarantine. Receivers using the older specification ignore the unknown t tag, so do not rely on it as a universal safety control. Publish only one of the example records at _dmarc for the domain. RFC 9989 advises against p=reject on general-purpose email domains; choose policy according to actual domain use and reporting.
- Confirm that direct sends pass DKIM with the required match to your visible From domain.
- Group failures by source IP, reporter, and policy override reason.
- Keep DKIM signatures resilient by avoiding changes to signed content after signing.
- Start with p=none and review reports before enforcement. If you use t=y, verify receiver behavior rather than assuming every receiver honors test mode.
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.
RFC 9990 requires SPF and DKIM results in aggregate reports, but no standalone ARC result. A reporter can include ARC context in an override comment or extension. Check trusted_forwarder, mailing_list, and local_policy reasons, then compare disposition with the published policy. These reasons do not prove ARC was used. Confirm arc=pass in Authentication-Results added by the final receiver, not an untrusted header supplied earlier in transit.
For Microsoft 365, trusted ARC sealer guidance identifies compauth=pass reason=130 in the final Authentication-Results header as evidence of a trusted ARC override. An arc=pass result or a delivered message alone does not establish that an override occurred.
|
|
|
|---|---|---|
DMARC fail | Final domain match failed | Check source |
Override reason | Reporter explains a policy exception | Check reason and disposition |
ARC detail | Reporter supplied context | Confirm in headers |
No override reason | No explanation recorded; outcome needs checking | Compare policy, disposition, and receiver logs |
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.
Policy override
Track
Reported DMARC disposition differs from the published policy; confirm final delivery separately.
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 DMARC reporting platform groups aggregate XML by sending source and shows authentication results and reported policy outcomes. 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
An ARC pass does not prove that a message is safe or guarantee inbox placement. Use the receiver's filtering results and delivery logs alongside authentication reports.
Practical Suped checks
- Identify whether failures come from approved senders, forwarders, or unknown infrastructure.
- Use automated issue detection and guided fix steps for sender-owned problems.
- Catch sudden authentication drops instead of waiting for a manual report review.
- 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 record inbound checks before modifying mail, then seal after all changes.
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 valid through forwarding by preserving signed headers and body content after signing.
Compare reported DMARC dispositions with delivery logs; an override alone cannot prove delivery.
Test ARC on the real forwarding path; inbox placement alone does not prove a trusted ARC override.
Marketer view
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 view
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
Frequently asked questions
Not for normal outbound campaigns. ARC has to be added by the forwarding system that handles the message after the original send.
No. ARC records earlier authentication results. If a trusted intermediary recorded a DMARC pass before forwarding changed the message, the receiver can use that evidence for a local policy override while still reporting DMARC as fail.
Forwarders, mailing lists, gateways, and relay systems that receive mail and send it onward should add ARC when they can validate the inbound message first.
No. ARC is not a prerequisite for a DMARC policy change. Confirm clean direct authentication and review aggregate reports first. RFC 9989 advises against p=reject for general-purpose email domains, so base the policy on the domain's actual use.
Monitor source IPs, DKIM results, SPF results, DMARC policy outcomes, and policy override reasons. In Suped, those signals help separate sender-owned fixes from forwarding behavior.
Send a message through the real forwarding path. Check for exactly one ARC-Authentication-Results, ARC-Message-Signature, and ARC-Seal per instance, with continuous i= values starting at 1 and no more than 50 sets. The first seal uses cv=none; later valid sets use cv=pass. Verify the latest message signature and every seal using the public selector keys. Earlier message signatures can fail after legitimate modifications without invalidating the chain. Confirm arc=pass and the override decision in results added by the final receiver.
