Why DMARC Fails When Emails Are Forwarded

When you forward an email, the authentication results can become contradictory. SPF passes. DKIM passes. Yet DMARC fails. This catches many admins off guard - and the fix isn't always obvious.

The reason forwarding breaks DMARC comes down to one thing: the From header domain no longer matches the path the message took to get to the destination.

How DMARC alignment works

DMARC has a rule called alignment. For a message to pass DMARC, the domain in the From header must align with either the domain that passed SPF or the domain that signed with DKIM.

SPF alignment checks the Return-Path header (also called the envelope sender). The domain in the Return-Path must match or be a subdomain of the From header domain.

DKIM alignment checks the d= domain in the DKIM signature. That domain must match or be a subdomain of the From header domain.

When a message is forwarded, the Return-Path almost always changes. The forwarding service or mailing list becomes the new envelope sender. That new Return-Path domain won't match the original From header domain - so SPF alignment fails. If the forwarding service also rewrites headers or doesn't DKIM-sign the forwarded message, DKIM alignment fails too. You can end up with SPF and DKIM both passing individually but DMARC failing because neither aligns with From.

Why forwarding services create this problem

A forwarding service typically receives mail for your address and re-sends it to a different destination. The envelope sender becomes the forwarding service's domain. The new Received headers show a different path. The original Return-Path is gone or replaced.

Mailing lists are the same. The list re-sends the message with its own envelope sender. Many mailing lists also rewrite the From header to show the list address rather than the original sender, which is another alignment failure on its own.

This is not a bug. It's how these systems work. The DMARC spec was designed to prevent sender spoofing, and the same mechanism that stops spoofing also catches legitimate forwarding when alignment isn't preserved.

What actually fixes it

ARC (Authenticated Received Chain)

ARC is a DMARC-adjacent standard that preserves the original authentication results through a forwarding chain. It adds a chain of signatures - one per hop - recording what SPF, DKIM, and DMARC returned at each step. Receivers that support ARC can look at the ARC results and make a more informed decision rather than treating the message as an outright failure.

ARC doesn't fix the underlying alignment problem. But it gives receiving servers a way to trust forwarded mail that has a clean ARC chain. If you run a forwarding service or mailing list, implementing ARC is one of the most practical steps you can take.

SRS (Sender Rewriting Scheme)

SRS rewrites the envelope sender when mail is forwarded so that SPF alignment is preserved. Instead of using the forwarding service's domain as the new envelope sender, SRS constructs a rewritten address that encodes the original sender's domain in a way that passes SPF at the destination.

The rewritten envelope sender looks something like: user=originaldomain.com@forwarding-service.com. When the destination checks SPF, it looks up the forwarding service's SPF record - which is valid - and alignment passes because the original domain appears in the rewritten address.

SRS has different implementations (SRSlite, SRS+, BH-compatible). Not all forwarding services implement SRS correctly. Some old implementations have their own quirks and edge cases. It's not a universal guarantee, but it is the most direct fix for the SPF alignment problem.

Custom From with DKIM signing

Some forwarding services let you set a custom From domain and sign outbound mail with DKIM on your behalf. If the service can DKIM-sign with your domain - not its own - DKIM alignment passes and DMARC passes. This requires the forwarding service to have DKIM key infrastructure set up for your domain, which isn't always supported.

This approach is also not without risk. You're delegating DKIM signing authority to a third party. If that service gets compromised or misconfigures keys, your domain's DKIM is compromised too.

Author Domain Signing Practices (ADSP)

ADSP is an older extension that tells receivers "any mail that appears to be from this domain must be DKIM-signed." It's largely obsolete now and not widely honored. Most receivers treat ADSP as advisory at best. Don't rely on it as a forwarding fix.

Configure a subdomain for forwarding

One option is to use a dedicated subdomain for forwarding purposes. Set up SPF, DKIM, and DMARC on that subdomain specifically so that forwarding from the main domain doesn't trigger failures on the main domain's policy. This doesn't fix the problem - it isolates it. It's a workaround, not a solution, and it adds operational complexity.

What doesn't fix it

Setting p=none - which tells receivers to take no action on failures - is the most common response to this problem. It makes sense as a temporary measure while you implement a real fix. But it is not a fix. It simply ignores the failure. Forwarding chains will still fail alignment, and you won't see that failure in your reports unless you also look at aggregate reports with a tool like DMARCFlow.

Switching to Alignment=relaxed doesn't help here either. Relaxed alignment allows subdomains, which is already the default in most DMARC implementations. It doesn't solve the core problem of envelope sender rewrite.

What you should actually do

1. Check your aggregate reports. If you're seeing DMARC failures on forwarded mail, the failure mode will be visible in the source elements of your DMARC XML reports. You need to be collecting those reports somewhere. DMARCFlow automates that collection and groups failures by type, so you can distinguish forwarding-related failures from actual spoofing.

2. If you're running a forwarding service or mailing list, implement ARC. This is the most responsible fix for your users.

3. If you're forwarding through a service that supports SRS, enable it. Confirm that alignment passes after enabling.

4. If you control the sending domain and you're getting failures from forwarding chains you can't fix, set up DMARC aggregate report monitoring so you can see the volume and source of failures. If the failures are from forwarding and not from spoofing, you can set policy to quarantine rather than reject to avoid breaking legitimate forwarded mail.

5. If your domain is being forwarded by third parties without your knowledge - for example, someone set up a mailing list on your domain without telling you - your aggregate reports will show it. That's a signal to track down who is forwarding your mail and why.

The forwarding problem isn't solvable by changing your DMARC policy alone. It requires understanding which hop in the chain is breaking alignment, then fixing or working around that specific hop.