Why Forwarded Emails Fail DMARC Alignment

If you have ever seen an email pass SPF and DKIM checks but still fail DMARC, you are not imagining it. Forwarding is one of the most common causes of this exact pattern.

The confusion comes from assuming that passing SPF or DKIM means passing DMARC. They measure different things.

SPF and DKIM pass. DMARC fails. Why?

SPF verifies that the sending mail server is authorized for the domain in the envelope-sender (the MAIL FROM address). DKIM adds a cryptographic signature tied to the sending domain. Both of these can pass even when email has been forwarded, because forwarding does not necessarily break either check.

DMARC does something separate. It checks whether the domain in the From-header (the address your recipients see) aligns with the domain that passed SPF or DKIM. This is the alignment check.

When a message gets forwarded, the envelope-sender may change to the forwarding server. The From-header stays the same. If the forwarding server is not authorized for the original From-header domain, SPF alignment fails. If the forwarding server signs with its own DKIM key instead of the original domain, DKIM alignment fails. Either alignment failure causes DMARC to fail, even when the underlying SPF and DKIM checks on the intermediate server both pass.

This is not a bug. It is how DMARC is designed to work. The protocol was built to catch spoofing, and forwarding involves a genuine change of responsible sending entity.

What actually happens during forwarding

A typical forwarding scenario looks like this:

1. Alice sends from alice@example.com to bob@forwardingservice.com
2. The forwarding service receives the message, then resends it to charlie@gmail.com
3. The forwarding service may set its own envelope-sender (MAIL FROM)
4. The From-header still shows alice@example.com
5. When the forwarding service sends through its own mail servers, SPF may pass for the forwarding service domain
6. DKIM may be signed by the forwarding service domain, not alice@example.com
7. The receiving server (Gmail, in this example) checks DMARC alignment against alice@example.com
8. Neither SPF nor DKIM alignment matches alice@example.com, so DMARC fails

The same logic applies to mailing lists. When Mailman, Sympa, Google Groups, or any other mailing list software relays messages for a domain, it typically handles SPF and DKIM for its own infrastructure. The list then forwards on behalf of the original sender. The From-header remains the original sender domain, but the relaying infrastructure is now responsible for delivery. DMARC sees a mismatch.

Common forwarding scenarios that break DMARC

Personal email forwarding rules. Many employees set up rules to forward work email to a personal Gmail or Outlook account. The company mail server delivers to the personal account. When the personal account forwards onward, that second leg breaks DMARC alignment for the company domain.

Mailing lists. Most mailing list software relays messages by resending from its own infrastructure. The From-header keeps the original author address, but the list server is now the sending entity. DMARC alignment fails unless the list operator has specifically configured ARC or signing.

Cloud email routing services. Services that route inbound mail through a third party for filtering or archiving often resend from their own servers after processing. If the service does not sign with the customer domain DKIM key and does not align the MAIL FROM, DMARC breaks.

Shared mailboxes with forwarding configured. A shared mailbox that forwards to an external address goes through the same mechanism. The company server delivers to the shared mailbox, which then forwards externally. That second hop typically breaks alignment for the original sender domain.

How to diagnose forwarding failures in DMARC reports

DMARC aggregate reports (rua) show the outcome of authentication checks at each receiving domain. When forwarding is causing failures, you typically see:

A high volume of DKIM alignment failures (dkim=fail) with the forwarding domain as the evaluated domain
SPF alignment failures (spf=fail) where the envelope-sender domain does not match the From-header
Failure counts concentrated among a small number of specific source IPs (the forwarding infrastructure)

A practical way to surface this: filter aggregate reports for DKIM alignment failures, then group by source IP. If a handful of IPs account for most failures and they belong to known forwarding services (Google Groups, Microsoft Mailing List services, Mailman servers, etc.), you have identified forwarding as the cause.

DMARCFlow surfaces these patterns directly in its forwarding failure view, showing you which forwarding sources generate the most DMARC noise and which From-header domains they affect. This makes it faster to distinguish forwarding patterns from actual spoofing campaigns, especially in environments with high report volume.

What operators and domain owners can do

For domain owners at p=none who are considering an upgrade:

Before moving to p=quarantine or p=reject, audit your aggregate reports for forwarding patterns. If legitimate forwarding sources are generating failures, those failures will become rejections or quarantines once you upgrade. Identify them first. DMARCFlow's forwarding report view shows you which source IPs are generating alignment failures and which From-header domains they touch, so you can spot legitimate forwarding before it becomes a rejection problem.

For mailing list operators:

Authenticated Received Chain (ARC) is the standard mechanism for mailing lists to preserve original sender information through the relay. ARC adds a chain of intermediate results to the message header, telling receiving servers that the original sender authenticated correctly and that the forwarding was authorized. Many modern mailing list packages support ARC. If yours does not, it is worth evaluating alternatives that do.

Sender Rewriting Scheme (SRS) is another option. SRS rewrites the envelope-sender so that SPF passes through the forwarding hop. It is simpler than ARC but has its own tradeoffs.

For companies with employee forwarding policies:

If employees forward work email externally, document this in your DMARC implementation plan. Users who forward to personal Gmail accounts from the company webmail interface are creating a second leg that will break DMARC once your policy is enforced.

For IT teams managing cloud email routing:

If your email routing service is breaking DMARC alignment, configure it to sign outbound messages with your customer domain DKIM key and to preserve MAIL FROM alignment. Most major services support this; it usually requires explicit configuration.

FAQ

Does telling users to stop forwarding fix DMARC failures?

Not always. MTA-level forwarding (server-side rules, mailing lists) happens without user action. You need to address the infrastructure-level forwarding, not just user behavior.

If I turn off forwarding entirely, will my DMARC pass rate improve?

For your own domain sending through your own infrastructure, yes. But forwarding from other domains to your infrastructure is their problem, not yours. Their DMARC alignment will fail when they forward to you if they have not set up forwarding correctly.

Does ARC fix DMARC failures permanently?

ARC preserves authentication results through the forwarding chain, but it requires receiving servers to honor ARC. Most major email providers (Google, Microsoft, Yahoo) do check ARC. It is not a universal solution but it significantly reduces false rejections for mailing list traffic.

My DMARC report shows failures from my own domain. Is this spoofing?

Probably not. If the source IPs belong to your own email infrastructure, it is more likely that a forwarding rule, mailing list, or internal routing system is causing alignment failures. Check the source IPs against your known forwarding infrastructure before assuming it is external spoofing.

Bottom line

Forwarded emails fail DMARC alignment because forwarding changes which server is responsible for sending, and that does not match the From-header domain. SPF and DKIM pass because they measure different things. This is working as designed.

If you are planning a DMARC policy upgrade, audit forwarding patterns first. If you operate a mailing list, implement ARC. If you use an email routing service, configure it to preserve alignment. DMARC aggregate reports will show you exactly where forwarding is causing failures. Tools that surface these patterns clearly can save significant investigation time.

The question to answer from your aggregate reports: are my DMARC failures from forwarding, from spoofing, or from both? The answer determines what action to take.