Forwarders break DMARC by modifying messages in transit. ARC (RFC 8617) preserves authentication results across hops. How it works, who supports it, and the limits.
Why Forwarding Breaks DMARC
A forwarder is any system that receives a message and re-sends it to a different destination. The category includes:
- Mailing lists that distribute one message to many subscribers
- Corporate gateways that scan and route mail
- Auto-forwarding rules in Gmail, Outlook, and similar
- Aliasing services that map one address to another
- Anti-spam systems that re-inject mail after scanning
When any of these systems forward a message, three things change:
1. The connection IP changes. The message arrives at the recipient from the forwarder's IP, not the original sender's. SPF, which authenticates IPs, fails because the forwarder's IP is not in the original sender's SPF record.
2. Headers may be modified. Mailing lists frequently rewrite the Subject ("[list-name] Original subject"), add prefixes, or insert footers. Any modification to signed headers breaks the DKIM signature.
3. The body may be modified. Footers added, formatting changes, attachment processing—all of these alter the body in ways that invalidate DKIM signatures that covered the body.
After forwarding, the message arrives at its final destination with broken authentication. SPF fails. DKIM fails. DMARC, which requires either SPF or DKIM to align with the visible From-domain, fails by extension.
For senders at DMARC p=reject, this means the message is rejected outright. For senders at p=quarantine, the message goes to spam. The recipient never sees mail that the original sender legitimately sent.
This is the core problem ARC addresses.
What ARC Actually Does
ARC (Authenticated Received Chain), specified in RFC 8617 published in 2019, lets each forwarder along the delivery path cryptographically record the authentication state it observed when it received the message.
When a forwarder receives a message and decides to forward it, it adds three headers:
ARC-Authentication-Results: A snapshot of the SPF, DKIM, and DMARC results the forwarder observed.ARC-Message-Signature: A DKIM-style signature over the message as the forwarder received it.ARC-Seal: A signature that locks in the previous two headers and any prior ARC headers in the chain.
The next hop (the next forwarder, or the final recipient) sees these headers and can verify them. If the chain is intact, the receiver knows what the original authentication looked like before the message was modified, even though current SPF and DKIM checks fail.
ARC does not prevent forwarders from breaking DMARC. It preserves a record of what the authentication looked like before the breakage, so the final receiver can choose to honor that record instead of failing the message.
The ARC Chain in Practice
A message that goes from sender → mailing list → recipient looks like this in headers (simplified):
1Original sender (yourbrand.com):
2 From: newsletter@yourbrand.com
3 DKIM-Signature: d=yourbrand.com; ...
4 [SPF passes for yourbrand.com sending IP]
5
6Mailing list adds:
7 ARC-Authentication-Results: i=1; mx.list.example.com;
8 spf=pass; dkim=pass; dmarc=pass header.from=yourbrand.com
9 ARC-Message-Signature: i=1; d=list.example.com; ...
10 ARC-Seal: i=1; d=list.example.com; cv=none; ...
11 [Subject rewritten to "[mylist] Original subject"]
12 [Body footer appended]
13
14Final recipient (Gmail) sees:
15 Current SPF/DKIM/DMARC: fail (because of list modifications)
16 But: ARC chain shows i=1 result was clean
17 Verdict: Trust the ARC chain, deliver to inboxThe i=1 parameter indicates the position in the chain. If the message goes through multiple forwarders, each adds their own ARC headers with i=2, i=3, etc. The chain is cumulative.
The cv= parameter on ARC-Seal indicates the validity of the prior chain: none for the first ARC entry, pass if the prior chain validated, fail if it did not.
Who Supports ARC
ARC adoption is uneven. The major implementations:
Senders/forwarders that sign ARC:
- Gmail (signs ARC when forwarding mail)
- Microsoft 365 (signs ARC for Exchange Online forwarding)
- Most major mailing list managers (Mailman 3, GNU Mailman with patches)
- Some ESPs in forwarding scenarios
Receivers that verify ARC:
- Gmail
- Microsoft 365
- Yahoo
- Apple Mail (limited)
- Some enterprise security gateways
Where ARC support is weak or absent:
- Smaller mailbox providers (regional ISPs, niche providers)
- Older mailing list software
- Academic and corporate mail systems running legacy infrastructure
- Most consumer ISPs
The practical effect: a message forwarded between two ARC-supporting systems benefits from chain preservation. A message forwarded through a system that does not implement ARC has no ARC headers added, and the chain is incomplete or absent. Final receivers without ARC verification ignore the headers regardless.
ARC works best in the scenarios where it is least needed (Gmail-to-Gmail forwarding, where reputation is already established) and works worst in the scenarios where it would help most (forwarding into legacy corporate systems).
What ARC Does Not Fix
ARC is not a complete solution. The limits worth understanding:
1. ARC does not authenticate the original sender. It authenticates a snapshot of what the original authentication was. If the first forwarder lies claims SPF and DKIM passed when they did not ARC has no mechanism to detect that. Chain integrity depends on trusting each link.
2. ARC trust is reputation-based, not cryptographic. Receivers decide whether to honor an ARC chain based on the reputation of the signing forwarders. Gmail trusts ARC signatures from Microsoft. Microsoft trusts ARC signatures from Gmail. A new ARC signer with no reputation produces ARC headers that receivers may ignore. Implementing ARC at your mailing list does not automatically mean Gmail will honor your signatures.
3. ARC requires both endpoints to implement it. A forwarder that signs ARC produces headers, but if the receiver does not verify ARC, the headers are ignored. The receiver continues to fail the message based on broken SPF/DKIM. Adoption gaps mean ARC helps in some forwarding paths and not others.
4. ARC does not solve the alignment problem in transit. If your mail is being forwarded through a corporate gateway that strips DKIM signatures or rewrites the From-header, ARC at best preserves the original authentication record. The current authentication is still broken. Receivers without ARC verification still see broken authentication.
5. ARC does not address content-level filtering. A message with intact ARC chain but spam-like content is still subject to content-based filtering. ARC is an authentication mechanism, not a free pass.
What This Means for Senders
ARC is primarily a forwarder-and-receiver concern, not a sender concern. There is no "ARC-compliant" configuration you implement on your sending domain. ARC works in your favor (or does not) based on what the systems handling your mail in transit choose to do.
That said, three things are within sender control:
1. Authenticate cleanly at the source. ARC preserves what it sees at the first hop. If your original SPF, DKIM, and DMARC are clean, the ARC chain starts from a verified state. If they are broken at the source, no amount of ARC downstream can help.
2. Use providers and forwarders that implement ARC. Choosing an ESP, mailing list manager, or corporate mail gateway that signs ARC means your mail gets the benefit of chain preservation when forwarded. Most major providers have implemented ARC; verify before assuming.
3. Monitor DMARC reports for forwarding-related failures. DMARC aggregate reports show you which sources are failing authentication. A persistent pattern of failures from forwarders mailing list IPs, university mail systems, corporate gateways indicates ARC is not bridging the gap for those paths. Sometimes the right response is accepting the loss; other times it is reaching out to the forwarder operator.
Diagnosing Forwarding Failures with DMARC Reports
When DMARC aggregate reports show authentication failures, distinguishing forwarding failures from genuine spoofing matters. The pattern looks like this in the XML:
1<row>
2 <source_ip>198.51.100.42</source_ip>
3 <count>847</count>
4 <policy_evaluated>
5 <disposition>none</disposition>
6 <dkim>fail</dkim>
7 <spf>fail</spf>
8 </policy_evaluated>
9</row>
10<auth_results>
11 <dkim>
12 <domain>yourbrand.com</domain>
13 <result>fail</result>
14 </dkim>
15 <spf>
16 <domain>list.example.org</domain>
17 <result>pass</result>
18 </spf>
19</auth_results>Reading this:
- The source IP belongs to
list.example.org, not your sending infrastructure. - DKIM fails for
yourbrand.com(signature broken in transit). - SPF passes for
list.example.org(the forwarder's own SPF authenticates its IP).
This is the signature of a mailing list or forwarder, not spoofing. The forwarder is sending mail that originated with you, modified it, and produced authentication results that fail for your domain but pass for theirs.
For a sender at DMARC p=reject, these messages are being rejected at the receiver. That is a real cost—legitimate subscribers are not seeing your mail because of forwarding breakage. Whether to address this depends on volume and the importance of the affected subscribers.
The contrast with genuine spoofing: spoofing usually shows IPs from sending infrastructure unrelated to your sender's normal sources, with authentication failing for both your domain and any forwarder identity (because there is no forwarder—it is just an attacker).
When to Move from p=reject to p=quarantine for Forwarder-Heavy Traffic
A practical scenario: a B2B sender pushes mail to corporate audiences, where forwarding through corporate gateways is common. DMARC at p=reject rejects forwarded messages. The sender sees deliverability complaints from customers whose corporate IT teams forward mail aggressively.
The conventional advice is "fix the forwarding," but in practice, you cannot fix someone else's gateway. The realistic options:
1. Accept the loss. A small percentage of forwarded mail will fail. For most senders, this is acceptable the protection from spoofing outweighs the cost of forwarding failures.
2. Move to p=quarantine. Quarantine still affects forwarded mail (it lands in spam), but recipients can fish it out manually. For senders who genuinely cannot tolerate losing forwarded mail, quarantine is the compromise.
3. Stay at p=none for the most-affected subdomain. If a specific subdomain handles primarily forwarded mail (e.g., list.yourbrand.com), keep that subdomain at p=none while keeping enforcement on the parent domain. The cost is reduced spoofing protection on the subdomain, traded for forwarder-friendly delivery.
The decision depends on the threat model. For brands that are actively impersonated in phishing attacks, p=reject everywhere is correct even with forwarding loss. For B2B senders whose mail is mostly internal-facing, p=quarantine is often the better balance.
Frequently Asked Questions
Can I sign ARC headers myself if I run a mailing list?
Will signing ARC at my mailing list make Gmail accept the forwarded mail?
Does ARC apply to BIMI?
Is ARC the same as a "trusted forwarder" mechanism?
Why does ARC adoption seem so uneven?
Does ARC affect inbox placement directly?
Should I monitor ARC results in DMARC reports?
Key Takeaways
- Forwarding breaks DMARC. SPF fails because the forwarder's IP is not in the original SPF record; DKIM fails because the message body or headers are modified in transit.
- ARC (Authenticated Received Chain, RFC 8617) lets each forwarder cryptographically vouch for the original authentication state, preserving the chain across hops.
- ARC is implemented by Gmail, Microsoft 365, Yahoo, and most major ESPs. Adoption is uneven in legacy corporate and academic mail infrastructure.
- ARC works for you when forwarders implement it. There is no sender-side configuration that makes mail "ARC-compliant."
- ARC trust is reputation-based, not purely cryptographic. New ARC signers may not be honored until receivers establish reputation.
- For senders mailing into forwarding-heavy environments, the choice between p=reject and p=quarantine is a real tradeoff. Pick based on threat model.
- DMARC reports distinguish forwarding failures from spoofing through the source IP and the pattern of failures. Forwarder IPs with their own passing SPF are usually legitimate forwarding, not attacks.
If you are working through DMARC implementation in order, this article complements Understanding DMARC Policies on the enforcement side and Why DMARC Alignment Matters More Than DMARC Itself on the authentication mechanics. For diagnosing forwarding failures via aggregate reports, The DMARC Aggregate Report Stack covers the tooling side.
ARC is a partial fix to a fundamental problem in email's architecture: messages were never designed to survive modification in transit. ARC patches that gracefully where adopted, and not at all where adoption lags. Plan accordingly.
Related articles
Deliverability Incident Response: A Playbook for the First 4 Hours
When email reputation collapses, the first 4 hours determine the recovery timeline. Triage, containment, communication the operational playbook teams actually need.
List Hygiene Beyond Bounces: Engagement-Based Suppression Strategies
Bounce-based list cleaning is decades behind modern deliverability. The 90/180/365-day engagement model, sunset policies, and re-engagement that actually works.
Blocklist Remediation Playbook: Spamhaus, SORBS, and UCEPROTECT
How to remove your IP or domain from Spamhaus, SORBS, UCEPROTECT, and other blocklists. Which lists matter, which to ignore, and the delisting process for each.