How Email Forwarding Breaks DMARC Alignment

The Problem Looks Like Spoofing. It Is Not.

You have DMARC set to p=none. You are considering moving to p=quarantine. Then you check your aggregate report and see hundreds of DMARC failures in a single day. Your first thought: someone is spoofing your domain.

In many cases, the actual cause is not spoofing at all. It is forwarding.

When a forwarded message fails DMARC, the failure is real. But the reason is not malicious. An email that was legitimately sent from your domain got forwarded by an intermediate server, and the forwarding process broke the DMARC alignment check. The message was real. The authentication still passed. But DMARC says fail because it compares the From header domain against the Return-Path domain, and those two no longer match after forwarding.

This catches many administrators off guard. It is also the most common reason organizations stall at p=none when they expected to move to enforcement within a few months.

If you are reading your DMARC reports and seeing this pattern, the challenge is not just understanding it. It is also about having the cross-receiver visibility to confirm the pattern is forwarding and not spoofing before you move to enforcement.

Why Forwarding Breaks DMARC

To understand the failure, you need to know what changes when mail gets forwarded.

Every email has two sender addresses that matter for authentication. The From header is what the recipient sees. The Return-Path, also called the Envelope-From, is the actual delivery address that mail servers use during SMTP. When you send an email directly, both addresses typically belong to your domain, so DMARC alignment passes easily.

When an intermediate mail server forwards the message, it typically rewrites the Return-Path to itself. This is normal behavior -- the forwarder needs to receive the message so it can relay it onward. The From header stays the same (still your domain), but the Return-Path now points to the forwarder. SPF checks the forwarder's server, not yours. Alignment compares the From domain against the Return-Path domain. Those two do not match, so DMARC fails.

DKIM behaves differently. A valid DKIM signature on the original message is preserved through forwarding because the message content has not changed. However, DKIM alignment still checks the DKIM-Signature domain against the From domain. If your DKIM is signed with a selector on the same domain as the From address, alignment passes. If your DKIM uses a different subdomain or a third-party sending platform, alignment fails too.

Most forwarded email fails DMARC on the SPF alignment path, not the DKIM path. But either way, the result is the same: DMARC reports a failure for mail that was never spoofed.

What Mailing Lists and Auto-Forwarders Do to DMARC

Not all forwarders behave the same way. The effect on DMARC depends on how the forwarder handles the message.

ISP-to-ISP forwarding -- Gmail forwarding to a personal ISP, Outlook.com forwarding to another provider. The forwarder rewrites the Return-Path to itself. SPF fails. DKIM may survive. DMARC fails.

Mailing list forwarding -- Google Groups, Mailman, Listserve. Most mailing list software changes the From header to the list address and adds its own Reply-To pointing back to the list. This explicitly breaks alignment. Some lists also strip DKIM signatures. If you are running a mailing list and your members use DMARC, you will see consistent failures from your list server's domain.

Auto-forwarding on the same domain -- If a user sets up a rule to forward work email to a personal Gmail account, the SPF check runs against your mail server, which passes. But the Return-Path is your server, not Gmail. The From is your domain, so alignment might still pass if your DMARC record is set up correctly. However, if Gmail later forwards that message again to another system, the chain breaks.

strong> -- If a user sets up a rule to forward work email to a personal Gmail account, the SPF check runs against your mail server, which passes. But the Return-Path is your server, not Gmail. The From is your domain, so alignment might still pass if your DMARC record is set up correctly. However, if Gmail later forwards that message again to another system, the chain breaks.

Each forwarder type produces a different failure pattern. That distinction matters for reading your reports.

How to Tell Forwarding Failures Apart from Spoofing

Your DMARC aggregate reports show you the failure. They do not always clearly explain the cause. Here is how to distinguish forwarding from spoofing in practice.

Spoofing typically shows failures to many unrelated target domains. Attackers send to whatever addresses they can find. Your report will show a wide variety of destination servers, many of which you have never sent mail to.

Forwardingstrong> typically shows failures to the same small set of forwarder domains. Your report will show repeated failures from known forwarders -- Gmail, Microsoft Online, Yahoo, your vendor's relay server. The volume may be high, but the destination domains are limited and consistent.

You are looking for patterns: same source IP, same destination domain, repeated failures from the same handful of domains. That pattern means forwarding, not spoofing.

Another clue: if you see failures from a destination domain that also receives successful mail from your domain through a different path, the failure is almost certainly forwarding. Spoofing attacks do not produce mixed success-and-failure patterns -- they fail everywhere.

This is where cross-receiver visibility matters. If you have DMARCFlow, you can see which receivers are reporting the failures, whether the same forwarder domains show up consistently across all receivers, and whether the failure volume spikes when you send to known forwarding-heavy recipients. Without that cross-receiver view, you are inferring the pattern from a single receiver's aggregate report -- and a single receiver only shows you part of the picture.

Options for Handling Forwarding Before Moving to p=quarantine or p=reject

If you want to move to enforcement but forwarding failures are blocking the move, you have several options.

Subdomain isolation is the cleanest long-term approach. Move all legitimate sending to a subdomain like mail.example.comcode> and keep the apex domain for marketing and transactional mail only. The apex domain can stay at p=none or p=quarantine. The sending subdomain gets its own DMARC record at p=reject. Forwarding failures on the apex domain do not affect your sending subdomain. This is the approach most large organizations eventually adopt.

Communicate with your forwarders -- if you know a vendor or partner is forwarding your mail, contact them and ask about their relay configuration. Some forwarders can add a Sender header or use a redirect-style forward that preserves the original Return-Path. This is not universally supported, but it is worth asking.

Accept the forwarding risk -- if forwarding represents a small percentage of your total failures and the business risk is acceptable, you can simply note in your policy documentation that forwarding failures are expected and not actionable. When the failure volume is low enough that it does not mask real spoofing, this is a defensible position.

Use a forwarding-aware gatewaystrong> -- some advanced email gateways can handle forwarded mail by re-aligning DMARC on behalf of the forwarder. This is not standard behavior and requires specific gateway configuration, but it eliminates the forwarding problem for affected messages.

Does ARC Solve This?

ARC (Authenticated Received Chain) was added to DMARC specifically to address forwarding. It works by having each server in the forwarding chain add a header that records the authentication results at each hop. The idea is that the final receiver can look at the ARC header and see that an earlier server authenticated the message, even if the final SPF and DKIM checks fail.

In practice, ARC adoption is real but incomplete. Gmail, Yahoo, and Comcast all respect ARC. Many corporate mail systems and smaller receivers do not. If a large percentage of your legitimate forwarded mail goes through ARC-aware receivers, ARC significantly reduces your forwarding-related DMARC failures. If your forwarding chain goes through legacy systems, ARC does not help.

ARC is not a universal solution today. It is a reason for optimism and a factor in planning your long-term DMARC roadmap, but it is not something you can rely on to solve your current p=none-to-enforcement transition.

How DMARCFlow Helps You Monitor Forwarding Without Moving Blindly

The most common mistake organizations make when moving from p=none to p=quarantine is doing it without clear visibility into which failures are forwarding and which are spoofing.

If forwarding failures are real and consistent, moving to enforcement will break legitimate mail flows. If spoofing failures are real, moving to enforcement protects your domain. You cannot make that call without cross-receiver visibility.

DMARCFlow aggregates aggregate reports from multiple receivers and shows you the failure patterns in a structured view. You can see which target domains are causing failures, which source IPs are sending unauthenticated mail, and whether the failure patterns look like forwarding or spoofing. That visibility lets you move to p=quarantine or p=reject with evidence rather than guesswork.

Forwarding failures will not disappear from your reports after you move to enforcement. But with the right monitoring in place, you will know exactly what they are and whether they are worth resolving.

---

FAQ

Q: Is it normal for forwarded email to fail DMARC?
A: Yes. When an intermediate server forwards mail, it rewrites the Return-Path to itself. SPF then authenticates the forwarder, not the original sender. The From header still shows the original sender, so DMARC alignment fails. This is working as designed.

Q: Can I exclude forwarding failures from my DMARC policy?strong>
A: No. DMARC does not have a mechanism to exclude specific failure causes. You can only set policy to none, quarantine, or reject for your domain as a whole. However, you can monitor forwarding failures separately and address them before moving to enforcement.

Q: Does DKIM survive forwarding?
A: Usually yes. A valid DKIM signature on the original message is preserved because the message content is not modified. However, DKIM alignment compares the DKIM-Signature domain against the From header domain. If your DKIM selector is on a subdomain or a third-party sending platform, alignment can still fail even with a valid signature.

Q: What percentage of my failures is acceptable before moving to p=reject?
A: There is no universal threshold. The goal is to ensure that real spoofing failures are not lost in the noise of expected forwarding failures. If forwarding represents a small fraction of your total volume, it does not block enforcement. If forwarding failures dominate your failure reports, resolve those first.

Q: Does ARC work everywhere?
A: No. Major consumer email providers (Gmail, Yahoo, Comcast) respect ARC. Many corporate mail systems and smaller providers do not yet implement it. ARC is an important step toward solving the forwarding problem but it is not universally adopted.