Blog · Dmarc
Why Email Forwarding Breaks DMARC Without Any Warning
You check your DMARC aggregate report. A chunk of legitimate email from a known contact is failing authentication. You did not change anything. Your domain records are fine. The failures just appeared.
The cause is usually forwarding. And it is more common than most administrators realize.
Forwarding breaks DMARC silently. No bounce. No warning. Just a line in your aggregate report showing that something failed, and you trying to figure out if it is a real problem or noise.
Here is exactly why it happens and what to do about it.
How Email Forwarding Changes the Sender
To understand the failure, you need to know about two sender addresses that every email carries.
RFC5322.From is the display address. It is what the recipient sees as the sender. It is the address that matters for human trust and that most mail clients show. When you open an email and see "From: alice@example.com", that is the RFC5322.From.
RFC5321.MailFrom is the return-path. It is the technical sender address used during SMTP delivery. Mail servers use it to route bounces and delivery confirmations. Most recipients never see it.
Most of the time, both addresses match your domain. When you send email directly from your own mail server, both sender addresses carry your domain. SPF validates the RFC5321.MailFrom. DKIM signs the RFC5322.From. DMARC alignment checks that they match.
Forwarding breaks this. When a forwarder relays a message, it inserts itself as the new RFC5321.MailFrom. The RFC5322.From stays the same, but the return-path now points to the forwarder's domain. Your original sending infrastructure is no longer in the envelope. It has been replaced.
Why SPF Fails First When Mail Is Forwarded
SPF validates the RFC5321.MailFrom domain against the sending server's IP address. When your mail server sends directly, the RFC5321.MailFrom is your domain and SPF checks your server's IP against your SPF record. That passes.
After forwarding, the RFC5321.MailFrom becomes the forwarder's domain. The forwarder's IP replaces yours in the SPF check. Unless the forwarder's IP is explicitly listed in your SPF record, SPF fails.
This is the first point of failure in the forwarding chain. Most administrators see this as an SPF fail and assume something is misconfigured on their end. Usually it is just forwarding.
What Happens to DKIM Through a Forwarder
DKIM behaves differently depending on whether the forwarder modifies signed headers.
When a message is DKIM-signed by the original sender and the forwarder does not touch the signed headers, DKIM survives the journey. The signature stays valid because DKIM validates the message content, not the envelope.
Most major forwarding systems (Gmail, Yahoo, Microsoft 365, Google Workspace) preserve DKIM signatures when forwarding internally or to compatible receivers. The header content does not change, so the signature still verifies.
However, some forwarding setups modify headers or re-format the message during relay, which strips the DKIM signature. When that happens, both SPF and DKIM fail.
Whether DKIM survives depends entirely on the forwarder's behavior. This is why some forwarded emails fail DKIM and others do not, even from the same sender.
Why DMARC Alignment Fails Even When DKIM Passes
This is the part that causes the most confusion.
DMARC has two checks: authentication and alignment. SPF and DKIM are authentication checks. They tell you whether the sending server is authorized. Alignment is a separate check. It asks: does the authenticated domain match the domain the recipient sees in the From header?
Specifically, DMARC alignment checks whether the domain in the RFC5322.From header matches the domain that passed SPF or the domain that signed DKIM.
For SPF, alignment means the RFC5321.MailFrom domain must match the RFC5322.From domain.
For DKIM, alignment means the domain in the DKIM signature's "d=" tag must match the RFC5322.From domain.
After forwarding, neither of these is true. The RFC5321.MailFrom is the forwarder's domain. The DKIM signature, if it survives, still signs the original sending domain. But alignment between the original From domain and the forwarder domain fails.
This is why a forwarded email can have DKIM pass but DMARC fail. The authentication passed (the message was signed by the original domain), but the alignment check failed because the forwarding server's domain does not match the From header domain.
How to Identify Forwarding Failures in Your DMARC Aggregate Reports
Aggregate reports arrive as XML files. They contain authentication results for every message a receiver processed from your domain during the reporting period. Here is how to find forwarding failures in them.
Look at the source IP first. The sending IP in the report belongs to the forwarder, not your mail server. If you see auth results from IP addresses you do not recognize and they are not your own sending infrastructure, check whether they belong to a known forwarding service.
Check the auth_method field. A forwarding failure typically shows up as SPF fail or DKIM fail (or both) alongside a sending IP that belongs to a webmail provider, SaaS platform, or forwarding service rather than your own mail infrastructure.
Compare against your known sending sources. If the failing source IPs correspond to a legitimate forwarding path you know about (a legacy email system, a mailing list, a CRM that relays on your behalf), those failures are forwarding noise, not spoofing.
This is where DMARCFlow earns its place. Reading aggregate reports manually to find forwarding patterns is time-consuming. A DMARC monitoring tool that parses and indexes report data lets you sort by source IP, auth method, and destination domain in seconds. You can run a forwarding audit in minutes rather than staring at raw XML for hours. The goal is to know, before you move to enforcement, whether your failures are threats or artifacts.
Look for patterns by destination domain. If failures concentrate at specific recipient domains, those domains may be forwarding your mail through a chain that breaks authentication. If failures spread across many different destination domains and source IPs you cannot identify, that pattern looks more like spoofing.
Forwarding failures typically show up as low-volume, consistent failures to specific domains. High-volume, many-destination failures are more likely to indicate actual spoofing.
The ARC Header: How Some Forwarders Try to Help
Authenticated Received Chain (ARC) is an email header that forwarders can add to preserve authentication context through a forwarding chain. RFC 8617 defines it.
When a forwarder adds an ARC header, it records the authentication results from the original delivery in a chain of signatures. Each intermediate server in the forwarding chain can add its own ARC header with the auth results it observed.
The idea is that the final receiving mailbox provider can see: "This message was authenticated by example.com's original server, passed SPF and DKIM there, and was then relayed through these intermediate servers." Even if DMARC alignment fails at the final hop, ARC provides context.
However, ARC does not automatically fix DMARC alignment failures. It is informational. Receiving mailbox providers may use ARC to inform delivery decisions, but they are not required to. Most large providers (Gmail, Yahoo) do evaluate ARC when present, but the weight they give it varies and is not publicly standardized.
The DMARC "np" tag (RFC 8601) was specifically designed to address forwarding. When a forwarder adds an auth result using the np tag, it signals that it has added its own authentication without breaking the original DMARC alignment. This allows forwarders to participate in the authentication chain without being treated as spoofers. In practice, np tag support among forwarders is growing but not yet universal.
Should Forwarding Failures Stop Your Move to DMARC Enforcement?
The short answer: usually not, if you audit first.
Forwarding failures are delivery artifacts, not security incidents. They represent how certain receiving systems handle your mail, not how attackers impersonate your domain. Threat actors do not send through the same forwarding chains your legitimate contacts use.
Before moving to p=reject, review your aggregate reports and ask two questions:
1. What percentage of my total volume comes from forwarding failures? 2. Do I recognize the forwarding sources as legitimate paths?
If your forwarding failures are below 5 to 10 percent of total volume and the forwarding sources are identifiable (known webmail providers, known SaaS platforms), you can move to enforcement. Most receiving mailbox providers still deliver mail from known forwarders even when DMARC alignment fails, because they use additional trust signals beyond DMARC.
If your failures are concentrated at a small number of specific forwarders you control or can contact, you may be able to reduce the failure rate by talking to those forwarders about ARC support or np tag implementation. Some enterprise forwarding systems (legacy Exchange relay configurations, on-premises mail gateways) can be updated to preserve or re-sign DKIM, which eliminates the alignment failure.
Use a DMARC monitoring tool to run your forwarding audit before you commit to enforcement. The question is not whether you have any forwarding-related failures - you almost certainly do. The question is whether those failures represent a small, known, manageable slice of your total sending volume.
Quick Reference: How Forwarding Breaks DMARC
| Stage | What Changes | Authentication Impact |
|---|---|---|
| Original send | None | SPF passes, DKIM may pass, DMARC alignment passes |
| Forwarder relays | RFC5321.MailFrom becomes forwarder domain | SPF checks forwarder IP against forwarder domain (fails if forwarder not in your SPF) |
| Forwarder may modify headers | DKIM signature stripped if headers changed | DKIM fails (if stripped) or DKIM passes with original domain signature |
| Final delivery | RFC5322.From still shows original sender | DMARC alignment fails: original From domain does not match forwarder domain |
The RFC5322.From never changes in forwarding. The envelope sender (RFC5321.MailFrom) always changes. DMARC alignment is the check that catches this mismatch.
FAQ
Does email forwarding break DMARC? Yes. When a forwarder relays a message, it replaces the RFC5321.MailFrom with its own domain. This breaks SPF alignment. If the forwarder also modifies signed headers, DKIM fails too. DMARC alignment fails because the authenticated domain does not match the visible From header domain.
Why does DMARC fail for forwarded emails even when SPF and DKIM pass? SPF can pass for the forwarder's domain even though the original From header shows your domain. DKIM may survive if the forwarder does not modify headers. But DMARC alignment fails because alignment checks whether the authenticated domain matches the From header domain - and after forwarding, they are different.
How can I tell if a DMARC failure is from forwarding or from spoofing? Forwarding failures typically come from known webmail or SaaS IP addresses, concentrate at specific destination domains, and show consistent patterns over time. Spoofing failures usually come from unrelated IP addresses you cannot identify and target many different recipient domains. Check your aggregate report source IPs against your known sending infrastructure.
Can I move to DMARC p=reject if I have forwarding in my email ecosystem? Usually yes, if the forwarding failures represent a small, identifiable portion of your total volume. Audit your aggregate reports first. If you recognize the forwarding sources and they account for less than 5 to 10 percent of your traffic, enforcement is generally safe.
What does the ARC header do for forwarded email? ARC adds a chain of authentication context through the forwarding chain. Each relay server adds its auth results to the ARC header chain. Receiving mailbox providers can read this chain to see the original authentication even if DMARC alignment fails at final delivery. However, ARC is informational, not binding.
What is the DMARC np tag? The np tag (RFC 8601) allows forwarders to add authentication results to a message without breaking the original DMARC alignment. When a forwarder uses the np tag, it tells receiving servers that it has added its own auth context, so the original DMARC alignment failure from forwarding should not be treated as a hard fail.