Why DMARC Fails for Forwarded Email (and What to Do About It)

You have DMARC set up. SPF and DKIM both pass when you test them. Then you discover that forwarded emails from your domain are failing DMARC - and you have no idea why.

This is one of the most common DMARC problems administrators run into. It is not a configuration error. It is a fundamental aspect of how email forwarding works, and understanding it requires a clear picture of what DMARC actually checks.

What DMARC Actually Validates

Most people first learn that DMARC checks SPF and DKIM. That is correct, but incomplete. how-dmarc-works DMARC validates two separate things:

1. Authentication - Did SPF and DKIM pass? 2. Alignment - Does the authenticated sender match the domain in the From header?

Both must pass for a DMARC check to succeed. This is where forwarding causes problems.

When you forward an email, the forwarding server re-sends it using its own SMTP infrastructure. The SPF check happens against the forwarding server's IP, not your original mail server. The DKIM signature - if one exists - may or may not survive the forwarding process depending on how the forwarding server handles headers.

More critically, the From header still shows your domain, but the SMTP envelope shows the forwarding server's domain. DMARC sees this mismatch and fails the alignment check, even though the email is legitimate.

The Forwarding Chain Step by Step

Here is what happens when a forwarded email moves through the chain:

Step 1 - Original sender. Alice owns example.com and sends an email to Bob at forwarding.example. The email has a valid SPF record, a DKIM signature from example.com, and a From header showing alice@example.com.

Step 2 - Forwarding server receives the email. SPF passes because the sending IP is authorized. DKIM passes because the signature is valid. DMARC passes because the SMTP envelope domain (example.com) matches the From header domain (example.com).

Step 3 - Forwarding server forwards to Bob's final inbox. The forwarding server opens a new SMTP connection to deliver the email to Bob. It keeps the original From header (alice@example.com) because that is what the recipient expects to see. But it uses its own SMTP envelope smtp-envelope-vs-from-header, meaning the MAIL FROM domain is now forwarding.example.

Step 4 - Bob's mail system checks DMARC. SPF checks the forwarding server's IP against forwarding.example's SPF record. That fails because forwarding.example did not authorize this IP. DKIM may fail if the forwarding server stripped or altered the signature. Alignment fails because the domain in the SMTP envelope does not match the From header. DMARC fails.

The forwarding server did nothing wrong. It faithfully delivered the email. But DMARC sees a fundamental mismatch between who sent the email (forwarding.example) and whose domain appears in the From header (example.com).

Why This Problem Is Getting More Common

Forwarding used to be a niche concern. Now it is everywhere. Remote work drove adoption of email forwarding to personal accounts. Cloud migrations create forwarding chains between old and new domains. Marketing platforms forward transactional emails. Legal discovery tools forward everything.

Every one of these forwarding paths is a potential DMARC failure waiting to happen. And when DMARC fails, the forwarded email either lands in quarantine or gets rejected entirely. Legitimate messages disappear without any notice to the sender or the recipient.

What Administrators Can Do About Forwarding Failures

There are four practical approaches, each with different tradeoffs. srs-sender-rewriting-scheme

Option 1 - Sender Rewriting Scheme (SRS)

SRS modifies the SMTP envelope address at the forwarding point so that SPF validates against the original sender's domain instead of the forwarding server. When the forwarded email bounces, SRS routes the bounce back to the original sender.

The forwarding server rewrites the MAIL FROM from alice@example.com to SRS0=abc=example.com@forwarding.example. The encoded portion SRS0=abc=example.com tells any downstream SRS-aware server to route bounces back through the original domain. When the receiving server checks SPF, it queries example.com's SPF record and gets a pass because example.com authorized the original sending IP.

SRS has honest limitations. Not all mail servers support it. Some forwarding services strip SRS addresses. It adds complexity to the forwarding infrastructure. And it requires consistent implementation across every forwarding hop - a chain with one non-SRS-aware server in the middle breaks.

Option 2 - List Moderation and Mailing List Modes

Mailing lists handle this differently. Instead of forwarding mail as-is, they re-send it from their own domain with their own DKIM signature. The From header may show the original sender, the list address, or both. Most mailing list operators publish an SPF record that authorizes their own sending infrastructure.

If you run a mailing list, enabling list-mode handling ensures DMARC passes through correctly. If you rely on third-party mailing lists, check whether they handle DMARC compatibility or whether they simply forward mail and hope for the best.

Option 3 - Third-Party Forwarding Services

Commercial forwarding services often have DMARC-compatible infrastructure. They maintain their own SPF records, apply DKIM signatures on your behalf, and handle the alignment problem at their layer. Some offer dashboard views of forwarding-specific failures.

If your organization relies heavily on email forwarding, using a managed service with proper DMARC support is usually more reliable than implementing SRS yourself.

Option 4 - Disable Forwarding

Sometimes the right answer is to stop forwarding. If forwarding is not a core part of your workflow, routing mail through a proper mail gateway with DMARC-aware handling eliminates the problem entirely.

How to Monitor Forwarded Mail Failures

Before you can fix forwarding problems, you need to see them. DMARC aggregate reports are the primary tool.

Every day, participating mail servers send aggregate reports to the address listed in your DMARC record's rua tag. These reports contain a summary of authentication results for emails claiming to be from your domain, including:

- Which IPs are sending mail on behalf of your domain - What percentage of those emails pass or fail DMARC - What failure types are occurring (SPF fail, DKIM fail, alignment fail) - Which receiving domains are processing your mail

For forwarded mail failures specifically, you are looking for alignment failures where the sending IP belongs to a known forwarding service and the failure mode is alignment rather than pure authentication failure.

Manually reviewing aggregate reports is time-consuming. dmarc-aggregate-reports Services that parse and visualize these reports make it much easier to spot forwarding-related failures quickly. DMARCFlow is built to handle this - it processes your aggregate reports and surfaces patterns like recurring forwarding failures from specific services, sudden increases in alignment failures, and receiving domains that have unusual failure rates.

When the Problem Cannot Be Fixed

Some forwarding situations have no good solution.

If a business partner forwards your transactional emails to their internal systems and their mail infrastructure does not support SRS or list-mode, you cannot make DMARC pass for those forwarded messages without either changing their infrastructure or loosening your DMARC policy.

In these cases, the practical options are:

1. Accept that forwarded mail may be rejected or quarantined and monitor how often it happens 2. Ask recipients to add your sending domain to their allowlist 3. Switch to a different delivery method that does not rely on forwarding

DMARC reporting tells you exactly how often forwarded mail failures occur and which receiving domains are affected. Use that data to make an informed decision rather than guessing.

The Bottom Line

Forwarded email fails DMARC because forwarding changes the relationship between the sending infrastructure and the From header domain. This is not a bug - it is how DMARC is designed to work. The design prevents exactly the kind of spoofing that forwarding would otherwise enable.

The fix depends on your forwarding scenario. SRS works for server-to-server forwarding if all hops support it. List-mode handling works for mailing lists. Managed forwarding services work if you can delegate the problem. And monitoring gives you visibility into how often forwarding failures actually affect your users.

If you want to see which forwarding services are currently generating failures against your domain, DMARCFlow can pull that from your aggregate reports in minutes.