Why DMARC Fails for Forwarded Emails

Your email is passing SPF and DKIM checks. Your DMARC record is published correctly. But when a recipient forwards your message to someone else, that second recipient gets a rejection. No bounce, no explanation. Just silence.

This is one of the most common DMARC failures administrators encounter, and it confuses people because the signal seems wrong: how can legitimate mail fail authentication after forwarding?

The short answer is that forwarding changes the envelope sender, which breaks DMARC alignment even when SPF and DKIM both pass. Here is the full chain of what happens.

What Actually Happens When an Email Is Forwarded

Email has two sender addresses: the envelope sender (RFC5321.MailFrom) and the header sender (RFC5322.From). The envelope sender controls bounce routing and SPF checks. The header sender is what the recipient sees as the "from" address.

When your mail server sends a message directly to a recipient, both addresses typically come from your domain. SPF checks the envelope sender against your server's IP. DKIM signs parts of the message including the From header using your domain's key. DMARC checks that the domain in the From header aligns with the domains used for SPF and DKIM. Everything matches, everything passes.

When a forwarding server receives your message and forwards it onward, it typically rewrites the envelope sender to its own domain. The forwarding server's MX accepts the message, then sends it on to the final destination. From the final recipient's perspective, the message came from the forwarding server, not from your domain.

This is where the chain breaks.

Why DMARC Fails But SPF and DKIM Still Pass

The key distinction is between authentication and alignment.

Authentication (SPF and DKIM) tells you whether the sending server is authorized and whether the message was signed correctly. Alignment (DMARC) tells you whether those authenticated domains match the From header domain.

When an email is forwarded, here is what typically happens:

SPF: The forwarding server sends the message from its own IP, so SPF checks against your domain's SPF record would fail. However, many forwarders do not bother with SPF for forwarded mail - they simply relay it. The final recipient may see the forwarding server's SPF result, not your domain's.

DKIM: The original DKIM signature, if one was applied by your mail server, usually survives forwarding. The signature covers message content, not the envelope. As long as the message content is not modified in transit, DKIM remains valid.

DMARC alignment: This is where forwarding breaks the chain. DMARC requires the domain used in SPF (the envelope sender domain) or the domain used in DKIM (the signing domain) to match the From header domain. After forwarding, the envelope sender is the forwarding server's domain, not yours. The DKIM signature may still be valid, but if the signing domain is checked against the From header and they do not match, DMARC alignment fails.

The most common scenario: your DKIM signature passes, your SPF check passes at some point in the chain, but DMARC alignment fails because the envelope sender domain (the forwarding server) does not match your From header domain. The message looks like it came from your domain in the headers, but the envelope says it came from somewhere else.

This is why you can see "SPF pass" and "DKIM pass" in your DMARC reports while still seeing failures. The authentication passes; the alignment does not.

What You Can Do About Forwarded Email Failures

The solutions split into two sides: what senders can do, and what recipients or forwarders can do.

Solutions for Senders

1. Use ARC (Authenticated Received Chain)
ARC is a proposed standard (RFC 8617) that lets intermediate servers like forwarders add a header documenting the authentication results at each step. The final recipient's mail system can see the original authentication chain and make a more informed decision.

If you are a sender and your recipients use ARC-aware mail systems, forwarded mail is more likely to be handled correctly because the original authentication results are preserved. This is the proper, standards-based fix for the forwarding problem.

2. Monitor your DMARC reports for forwarding patterns
This is where DMARCFlow makes a practical difference. Your DMARC aggregate reports tell you exactly which IPs are sending mail that fails alignment against your domain. When a forwarding server rewrites your envelope sender and causes alignment failures, those failures show up in your reports as DKIM or SPF alignment errors from IPs you do not recognize.

Without a tool to parse these reports, you see raw XML that most people cannot interpret. DMARCFlow turns those reports into a readable summary showing which forwarding servers are causing failures, how frequently, and which domains are affected. This gives you the information to decide whether to whitelist a specific forwarding service, reach out to affected recipients, or accept that certain forwarding paths will generate failures.

3. Whitelist forwarding servers
If you know specific forwarding servers handle your mail legitimately, you can add their IP ranges to your SPF record as authorized senders. This is a pragmatic workaround for known forwarding patterns, though it does not scale well if forwarding paths change frequently.

Solutions for Recipients and Forwarders

1. Implement ARC as a forwarder
If you operate a forwarding service, implementing ARC and adding the authentication chain to forwarded messages is the correct approach. It preserves the original sender's authentication intent and prevents legitimate mail from being rejected downstream.

2. Use a list-ID header
Some mailing lists and forwarders add a List-ID header that identifies the forwarding service. Some mail systems use this as a signal, though it is less standardized than ARC and not a reliable fix on its own.

3. Configure forwarding to preserve envelope sender
Some forwarding setups can be configured to preserve the original envelope sender rather than rewriting it. This depends on the forwarding software and is not always straightforward, but it prevents alignment failures from occurring in the first place.

How to Spot Forwarding Issues in Your DMARC Reports

Forwarding failures show up in your DMARC aggregate reports as alignment failures. Specifically, you will see DKIM failures or SPF failures where the authenticated domain does not match your From header domain.

The telltale sign is a forwarding pattern: you see failures consistently from IP ranges that do not belong to your organization but are handling your mail. The source IP is a known forwarding or mailing service. The failure reason is alignment, not authentication.

With DMARCFlow, you can filter your aggregate reports specifically for alignment failures and identify which forwarding services are generating the most failures. This matters because not all forwarding is visible to you - you only learn about it when a recipient complains or when you look at your reports.

Without this monitoring, forwarding failures are invisible. You only hear about them when a recipient says they are not getting mail they expected, by which point the problem has already affected delivery.

FAQ

Does forwarded mail always fail DMARC?
Not always. If the forwarding server preserves the original envelope sender and passes through the original DKIM signature without modification, alignment can still pass. In practice, many forwarding setups rewrite the envelope sender, which causes alignment to fail.

Can I just tell my recipients not to forward mail?
That is not a realistic option for most organizations. Forwarding is a normal email behavior, particularly for mailing lists, distribution groups, and personal email accounts.

Does Gmail forward mail with ARC?
Gmail and some other major providers support ARC. When Gmail forwards mail to another provider, it adds ARC headers documenting the original authentication results. This helps preserve authentication intent through subsequent forwards.

Will fixing forwarding issues improve my deliverability?
If forwarding is causing legitimate mail to be rejected or filtered, fixing forwarding issues can improve deliverability for affected recipients. It is not the only deliverability factor, but it removes a specific failure mode.

Is there a DMARC record tag that fixes forwarding?
No. DMARC does not have a mechanism to whitelist forwarding servers or exempt forwarded mail from alignment checks. The solutions are architectural (ARC), operational (whitelisting in SPF), or monitoring-based (understanding your failure reports).

Summary

Forwarding breaks DMARC because it changes the envelope sender, which causes DMARC alignment to fail even when SPF and DKIM both pass. The forwarding server's domain becomes the effective sender in the envelope, while the From header still shows the original sender. DMARC flags this as a mismatch.

The proper fix is ARC, which preserves authentication results through the forwarding chain. Until ARC is universally adopted, the practical options are monitoring your DMARC reports to understand the scope of forwarding failures, whitelisting known forwarding servers in your SPF record, and working with recipients who have forwarding issues.

If you want to see which forwarding servers are generating DMARC failures for your domain, DMARCFlow parses your aggregate reports and surfaces these patterns clearly. It does not fix forwarding for you, but it tells you exactly what is happening and which forwarding services are causing the most failures.

---

Have a DMARC question you want explained?