Why DMARC Alignment Fails on Forwarded Emails

When forwarded emails fail DMARC alignment, the problem is almost never the sender's DMARC policy. It is the forwarding or mailing list server reshaping the message in ways that break SPF, DKIM, or both. Understanding why this happens, and what you can actually do about it, requires a clear picture of what forwarding does to an email.

What Happens to an Email When It Gets Forwarded

Email forwarding is not a clean relay. When a message passes through a forwarder, the forwarder usually creates a new delivery envelope and may rewrite headers, add content, or reformat the message body. This reshaping is normal and invisible to most users, but it has specific consequences for email authentication.

Here is the critical distinction: the envelope sender (the Return-Path header used for SPF) and the From header (the one users see and the one DMARC checks) are two separate things. A forwarder may send the forwarded message from its own servers with its own envelope, while displaying the original sender's From address to the recipient.

When a forwarding server reshapes the message, it can break DKIM signatures that were applied by the original sender. If the forwarder adds headers, modifies the message body, or re-encodes parts of the MIME structure, any DKIM signature covering those elements becomes invalid. The receiving server sees a broken DKIM result, not a valid one.

This is why forwarded emails can fail authentication even when the original sender has a perfectly configured DKIM signature and DMARC policy.

How DMARC Checks Each Part of a Forwarded Email

DMARC has two separate checks that work together:

SPF alignment verifies that the domain in the envelope sender (Return-Path) matches the domain in the From header. When a forwarder sends from its own infrastructure, the envelope sender is the forwarder's domain, not the original sender's. This fails alignment unless the domains happen to match at the organizational level.

DKIM alignment verifies that the domain in a valid DKIM signature matches the From header domain. Since forwarding often breaks DKIM signatures, this check fails too.

This is where pf=relaxed comes in. The DMARC record tag pf=relaxed means alignment must match at the organizational domain level, not the exact subdomain level. If your From header is newsletter@example.com and your organizational domain is example.com, a DKIM or SPF result from subdomain.example.com passes with pf=relaxed but would fail with pf=strict.

The important limitation of pf=relaxed is this: it relaxes the domain match requirement. It does not fix broken DKIM signatures. It does not fix an incorrect envelope sender. If the forwarder's envelope sender domain is forwarder.com and the From header is example.com, relaxed alignment still fails because those are different organizational domains.

If you are seeing DMARC failures on forwarded emails and pf=relaxed is already set, the problem is not your alignment mode. The problem is that the forwarder is reshaping the message in a way that invalidates authentication.

Common Forwarding Scenarios That Break DMARC

Personal email forwarding (Gmail to Outlook, Outlook to Yahoo, etc.) usually preserves the original From header but sends from the forwarding service's own servers. SPF fails because the forwarder is not authorized to send for the original sender's domain. DKIM may survive if the original signature covers enough of the message, but many forwarding services re-encode MIME content in ways that break DKIM.

Mailing list redistribution (Mailchimp-style newsletters, industry digest services) often adds list-specific headers, footer unsubscribe links, or tracking pixels. Any of these changes can break DKIM signatures. Many mailing lists also use their own envelope sender domain, causing SPF alignment failures.

Internal-to-external forwarding on corporate mail servers (Exchange, Microsoft 365) is a common source of unexpected DMARC failures. When an internal rule forwards a message to an external recipient, the internal server's transport layer may reshape headers or use a different envelope sender. If the original sender has a strict DMARC policy, these forwarded messages fail.

Auto-forwarding rules on Microsoft 365 are a frequent culprit. When a user sets up an inbox rule to forward messages to a personal Gmail account, Exchange Online may deliver those messages with its own envelope while preserving the original From header. Microsoft 365's own authentication passes internally, but when the forwarded message reaches Gmail, Gmail evaluates it against the original sender's DMARC policy and may reject or quarantine it.

How to Diagnose Forwarding-Related DMARC Failures

The clearest signal is in your DMARC aggregate reports. Look for fail disposition results where the source IP belongs to a known forwarding or mailing list service rather than your own sending infrastructure. The source_type field in a raw DMARC report will often identify the organizational source of the relay.

Common forwarding service IPs to look for:

Major consumer email providers (Gmail, Yahoo, Outlook.com) when they act as forwarders

Bulk mailing platforms that redistribute content

Corporate mail services that handle forwarding rules

The dkim_result and spf_result fields tell you which check failed. A fail on DKIM with no valid signature usually means the message was reshaped. A fail on SPF with a forwarding service as the source usually means the envelope sender was rewritten.

If you do not currently receive DMARC aggregate reports, you are flying blind on this. Most domain providers send DMARC reports to the address specified in the rua tag of your DMARC record. Without them, you cannot tell the difference between a forwarding problem and a genuine authentication misconfiguration.

Using a DMARC monitoring tool like DMARCFlow lets you track forwarding failures over time, see which forwarding services are causing the most failures, and spot trends without having to parse raw report files manually. This is especially useful when you have multiple forwarding paths in place and need to prioritize which ones to address first.

What You Can Actually Do About Forwarded Email DMARC Failures

There are four practical approaches, depending on your situation:

Ask your forwarder to implement SRS. Sender Rewriting Scheme (SRS, defined in IETF drafts and implemented across major forwarding platforms) is the standards-based fix for forwarder-side DMARC failures. SRS rewrites the envelope sender at the forwarding boundary so that SPF alignment passes, while preserving enough information to route bounce messages back to the original sender. If your forwarder is a mailing list service or an email service provider, ask whether they support SRS or are working on it. Some major providers already implement it.

Configure forwarding rules to preserve original authentication. On Exchange Online and similar platforms, you can configure transport rules that do not add extra headers or re-encode MIME content when forwarding. This preserves the original DKIM signature. However, the envelope sender issue remains because the forwarder is still sending from its own infrastructure.

Adjust your own DMARC policy if the forwarding is legitimate. If the forwarding failures are from a known, trusted source (such as an internal IT system that legitimately forwards certain emails), you can create a DMARC override using rua reporting to monitor the scope of the problem, then consider whether p=quarantine instead of p=reject is appropriate until the forwarder addresses the issue. This is a temporary measure, not a permanent fix.

Use DMARC monitoring to track and triage forwarding failures. Forwarding-related DMARC failures are often harmless: the recipient may still receive the email, just with a different delivery path. But without visibility into your DMARC reports, you cannot tell the difference between a benign forwarding issue and something more serious. DMARCFlow aggregates your DMARC reports automatically, tracks failure patterns over time, and flags new forwarding sources you have not seen before. This means you can distinguish between a known mailing list that has always reshaped your content (and is therefore low priority) and a new forwarding source that might warrant investigation.

Should You Worry About Forwarding Failures in Your DMARC Reports?

Not all DMARC failures indicate a security problem. Forwarding-related failures are usually benign from a threat perspective. The forwarded email is not being rejected because of malicious activity. It is being caught by a mismatch between what the forwarder does and what the original sender's DMARC policy expects.

However, forwarding failures can mask more serious problems. If you see DMARC fail results from IP addresses that are not recognized forwarding services, that could indicate someone is attempting to relay through your domain, which is a different kind of problem.

The practical rule: use DMARC aggregate reports to classify each failure. Forwarder-shaped failures are noise. Non-forwarder failures from unexpected sources deserve investigation.