Why Forwarded Emails Fail DMARC Authentication

Why do forwarded emails fail DMARC, even when SPF and DKIM pass?

Because forwarding changes the mail server that sends the message, but not the From address that DMARC checks.

When you send an email directly, your mail server's IP address appears in the SMTP conversation, SPF passes because your domain's SPF record includes your mail server, and DKIM passes because your server signs the message with your domain's key. DMARC alignment sees both results matching your From header and the mail delivers normally.

When an email is forwarded, the original message arrives at the forwarder's mail server first. The forwarder then re-injects it into a fresh SMTP session toward the recipient. The forwarder's server IP becomes the sending IP. The From header, which is what users see, still shows the original sender's domain. But DMARC does not check the From header for alignment. It checks the Envelope From, which the forwarder has rewritten to its own address. And it checks DKIM alignment against the signing domain, which may also not match the From header after reinjection.

That mismatch is where the failure starts.

What happens to SPF when an email is forwarded

SPF is checked against the immediate sending mail server's IP address at delivery time. When a forwarder reinjects a message, it is the forwarder's IP that gets SPF checked, not the original sender's.

The Envelope From (also called Return-Path) is rewritten to the forwarding account's address during reinjection. This means SPF is evaluated for the forwarder's domain, not the original sender's domain.

The original sender's SPF record, which may correctly cover their own mail servers, never gets evaluated against the forwarder's IP. And even if the forwarder's SPF record passes for the forwarder's domain, that domain does not match the From header (sender.com) in DMARC alignment terms.

So SPF passes. But DMARC alignment fails. Those are two different things.

What happens to DKIM when an email is forwarded

DKIM signatures from the original sender should survive forwarding in most cases, since DKIM signs the message body and headers, which typically persist through the forwarding process.

But there are two ways DKIM can still fail after forwarding.

First, alignment. A DKIM signature is valid for the signing domain, which must align with the From header domain for DMARC to pass. If the original sender used a subdomain like mail.sender.com for DKIM but the From header is just sender.com, that alignment fails before forwarding enters the picture at all.

Second, message transformation. Some forwarding services modify the message body during reinjection in ways that break DKIM signatures. This is more common with mailing list managers and automated forwarding services than with simple inbox-to-inbox forwarding.

In short: DKIM signatures from the original sender may survive forwarding, but alignment is still the failure point in most cases.

The exact sequence of a forwarding failure

Here is the concrete scenario:

1. alice@example.com sends a message to newsletter@forwarderservice.com
2. The forwarderservice.com MTA receives the message, rewrites the Envelope From to newsletter@forwarderservice.com, and reinjects it toward bob@gmail.com
3. At delivery time, Gmail's MTA sees the sending IP as forwarderservice.com's server
4. Gmail checks SPF for forwarderservice.com (which passes, since forwarderservice.com's SPF covers their servers)
5. Gmail checks DKIM: if the original DKIM signature from example.com survives and aligns with the From header, this passes too
6. Gmail checks DMARC alignment: the authenticated Envelope From (forwarderservice.com) does not match the From header domain (example.com)
7. DMARC fails

This is not a bug. This is the intended security behavior. DMARC is designed to prevent exactly this kind of cross-domain injection, where mail appears to come from one domain but is actually sent through another.

What ARC does and does not fix

ARC (Authenticated Received Chain), defined in RFC 8617, was designed to solve the forwarding authentication problem.

Each MTA in the forwarding chain adds an ARC header recording the authentication results it observed at each step. The final recipient's MTA can then see the full chain: the message was authenticated as example.com at the origin, passed through forwarderservice.com, and arrived at its current location.

This would let mailbox providers treat a legitimate forwarding chain differently from spoofed mail. The theory is sound.

The problem is adoption. Until major mailbox providers consistently check ARC and factor it into delivery decisions, ARC does not help forwarded mail pass DMARC at most destinations. Google, Microsoft, and other large providers have varying levels of ARC support. None treat ARC as equivalent to a passing DMARC result.

ARC is the right long-term answer. It is not a practical solution today.

What senders can do about forwarding failures

The options are limited. The sender cannot control what forwarders do with their mail. But some steps reduce the impact:

Use p=quarantine while validating your forwarding paths. Setting p=reject when you have legitimate forwarding in your user base will break that mail. Starting with p=quarantine gives you time to see how much forwarding actually affects your delivery before switching to reject.

Check your aggregate reports. DMARC aggregate reports (sent to your RUA address) show which domains are receiving your mail and what authentication results they see. If forwarding is causing failures, aggregate reports will show elevated DMARC failure rates for specific destination domains. The data is there; it is just hard to read in raw XML form.

This is where DMARCFlow fits. Aggregate reports are XML and require a parser to make sense of. DMARCFlow reads your aggregate reports and shows you which destination domains are seeing DMARC alignment failures and whether those failures look like forwarding (SPF and DKIM pass individually, alignment fails) or like genuine authentication problems. Before you move to p=reject, that context matters.

Use subdomain sending for high-forwarding mail streams. Marketing newsletters and automated notifications have higher forwarding rates than transactional mail. Sending these from a subdomain like mail.example.com with its own SPF/DKIM/DMARC policy means forwarding failures on those streams do not affect your main domain's reputation or policy decisions.

Identify which forwarding paths affect your mail. Some forwarding services offer authenticated forwarding or preserve From header alignment better. DMARCFlow aggregate report parsing makes it straightforward to see which destination domains appear repeatedly in your failure data, so you can investigate specific forwarding paths before making policy changes.

What recipients can do about forwarded mail getting blocked

If you are the recipient and forwarded mail is being blocked or filtered because of DMARC failures, the options are on your side:

Distinguish forwarding failures from genuine spoofing. A forwarding-related DMARC failure shows SPF and DKIM individually passing while alignment fails. A spoofing attempt typically shows one or both authentication methods failing entirely. Check your mail logs or DMARC reports to tell the difference before assuming the worst about the sender.

Some providers offer safe sender overrides. Microsoft Outlook, Gmail, and other providers have settings that allow specific senders through even when DMARC fails. These overrides bypass DMARC results, which also means they bypass protection against spoofed mail from those addresses. Use them with awareness of the tradeoff.

Flag forwarded mail rather than blocking it. If your mail system supports it, routing forwarded mail to a quarantine folder for manual review instead of rejecting it outright lets legitimate forwarded mail through while keeping spoofed mail contained.

Frequently asked questions

Does setting p=none in my DMARC record make forwarded mail work?

No. The p=none policy tells receiving mail servers to take no action when DMARC fails. It does not change whether forwarding breaks DMARC alignment. The failure still happens; the consequence is just suppressed.

Can I set up SPF so forwarded mail passes automatically?

Not without the forwarder's cooperation. SPF is evaluated against the immediate sending MTA's IP address. If the forwarder's server is sending the message to your mailbox, SPF will be checked for the forwarder's domain, not the original sender's. You would need the forwarder to preserve the original Envelope From, which most forwarding services do not do.

Why does Gmail-to-Gmail forwarding work more reliably than other forwarding paths?

Gmail uses internal routing that preserves ARC headers and has high ARC awareness across its infrastructure. When mail stays entirely within Google's ecosystem during forwarding, authentication information is more likely to survive the journey. This does not mean forwarded mail always passes DMARC within Gmail. It means it fails less often than forwarding through independent mail services.

Is there a standard that fixes the forwarding problem properly?

ARC is the intended solution. Until adoption reaches the level where major mailbox providers factor ARC into delivery decisions as a matter of course, forwarding will continue to cause DMARC alignment failures for mail that passes through any MTA that rewrites the Envelope From.

Can I use DMARCFlow to see which forwarding paths are causing failures?

Yes. DMARCFlow parses aggregate reports and identifies which destination domains are seeing DMARC alignment failures. If specific forwarding services or destination domains appear repeatedly in your failure data, that is a signal worth investigating before you tighten your DMARC policy to p=reject.

The practical summary

Forwarded mail fails DMARC because the forwarder's mail server rewrites the SMTP Envelope From, which breaks SPF alignment. DKIM signatures may or may not survive forwarding, but alignment is the core problem either way.

This is not a misconfiguration you can fix on your end. It is a consequence of how SMTP forwarding works and what DMARC is designed to protect against.

Your options: use aggregate reports to understand how much forwarding affects your mail, use subdomain sending to isolate forwarding-heavy mail streams, and wait for ARC adoption to improve. Until then, p=none or p=quarantine is the practical policy for any domain with a user base that forwards mail.