Why DMARC Passes for Forwarded Email But Still Fails Alignment - and What ARC Solves

The Confusion: SPF and DKIM Pass, But DMARC Fails

You're looking at a DMARC report and something doesn't add up. Your domain's SPF record is correct. Your DKIM signature is validating. But DMARC is showing as failed for a message you sent.

The message was forwarded.

This catches domain owners off guard every time. The assumption is that if SPF and DKIM both pass, DMARC should follow. It doesn't  and the reason is in the design of DMARC itself, not in a misconfiguration.

Authentication and Alignment Are Two Different Things

SPF and DKIM are authentication mechanisms. They answer the question: "Was this email actually sent from the server it claims to be from?"

DMARC adds something different: alignment. It answers the question: "Does the domain that sent this email match the domain it's claiming to be from?"

These are two separate checks. A message can pass SPF, pass DKIM, and still fail DMARC  because alignment is a gate on top of authentication, not a byproduct of it.

This distinction matters most when email gets forwarded.

Why Forwarding Breaks DMARC Alignment

Here's what happens step by step when email is forwarded:

1. Alice at company.com sends an email to a mailing list or forwarder. The message is signed by company.com's DKIM key. SPF checks out because the mail came from company.com's mail server.

2. The forwarder receives the message and redistribute it. The forwarder's SMTP server is now the sender. The original MAIL FROM may be rewritten. The forwarder is acting as the new sender for delivery purposes.

3. The final receiver checks DMARC against the forwarder's domain. DMARC alignment evaluates the domains in the SMTP conversation, not the domains from the original email headers. The receiver sees the forwarder's domain, not company.com.

4. Alignment fails. company.com ≠ forwarder.com. DMARC fails, even though the message was originally authenticated by company.com's SPF and DKIM.

This is the key point: the failure isn't because something was configured wrong. It's because the forwarder's infrastructure is responsible for the message at the point of delivery. DMARC is doing exactly what it was designed to do, enforcing that the domains align, but the chain of custody has changed.

RFC 9989 (DMARC bis) addresses this through alignment extension mechanisms discussed in Section 4.4.3, acknowledging that forwarding is a legitimate mail-flow pattern that creates real tension with strict alignment requirements.

What ARC Is - and What It Actually Solves

ARC (Authenticated Received Chain, RFC 8612) was designed to solve the forwarding problem specifically. Rather than rewriting DMARC's rules, it adds visibility.

When an intermediary, a forwarder, mailing list, or gateway, processes a message, it adds three ARC header fields:

• ARC-Seal: A signature that proves the intermediary was there and processed the message
• ARC-Message-Signature: A signature covering the message headers at that hop
• ARC-Authentication-Results: The authentication results (SPF, DKIM, DMARC) observed at that hop

Each intermediary in the forwarding chain adds its own results. By the time the message reaches the final receiver, there is a documented chain of every authentication decision made along the way.

Receivers that support ARC can look back through this chain and see the original authentication from company.com, even though the final SMTP hop came from forwarder.com. This gives receivers enough context to make a more informed delivery decision rather than flat-out rejecting because the final alignment check failed.

What ARC Doesn't Do

ARC doesn't rewrite DMARC. Receivers that don't support ARC still apply standard DMARC checks. The forwarder's domain still fails alignment at the final hop if ARC is not in play.

And even when ARC is supported, it doesn't guarantee delivery. It gives the receiver more information, it doesn't override their DMARC policy. A receiver with p=reject will still reject messages where alignment fails, even with a full ARC chain showing the original authentication was clean.

What You Can Do About Forwarded Mail and DMARC

If you control the forwarder: implement ARC signing. This is the forwarding infrastructure's way of documenting "we received this from company.com and here's what we observed." Many modern mailing list platforms and gateways support ARC natively.

If you receive forwarded mail: you can configure your DMARC policy to account for forwarding chains. Specifically, if your receiver supports ARC, you can use the ARC-Authentication-Results to inform delivery rather than treating a final-hop DMARC failure as an automatic rejection.

If you're investigating DMARC failures: check whether ARC headers are present in messages that are failing. If they are, the failure may be expected, the result of a forwarding chain, not a spoofing attempt. If they aren't, you may be dealing with a different kind of alignment failure.

How to See These Patterns in Your DMARC Reports

When forwarded mail fails DMARC, you'll see it in your aggregate reports , to recice these you need a DMARC provider like DMARCFlow, as alignment failures from domains you don't recognize. Without context, this looks like an attack. With ARC header awareness, it becomes distinguishable noise, a sign of normal mail flow, not a threat.

DMARCFlow aggregates these failures and can help you identify when alignment failures are attributable to forwarding chains rather than spoofing. This matters because blanket blocking forwarded mail can break legitimate communication and the difference shows up in your DMARC data if you know how to read it.

Summary

• SPF and DKIM passing does not automatically mean DMARC passes
• DMARC alignment is a separate gate that checks whether the sending domain matches the authenticated domain
• Forwarding breaks alignment because the forwarder becomes the sender at the SMTP level
• ARC documents the authentication chain at each hop so receivers can see the original auth even when alignment fails at the final hop
• ARC doesn't override DMARC - it adds visibility
• Check your DMARC reports for forwarding-related alignment failures and look for ARC headers to distinguish them from spoofing attempts

FAQ

Does enabling ARC automatically fix DMARC failures for forwarded mail? No. ARC provides information about the authentication chain; it doesn't change how receivers apply DMARC policy. A receiver with p=reject will still reject aligned failures even with ARC present.

Can I prevent forwarded mail from failing DMARC? Not from the sender side. The receiver's handling of forwarded mail - including whether they honor ARC - is outside your control. What you can do is monitor the pattern in your DMARC reports and determine whether forwarded mail is causing the failures you're seeing.

Does RFC 9989 (DMARC bis) address forwarding specifically? Yes. Section 4.4.3 discusses alignment and extension technologies, and Section 7 covers interoperability,  including how forwarding and relaying interact with DMARC alignment requirements.