Why DMARC Fails on Forwarded Email and How to Fix It

Forwarded email fails DMARC because forwarding rewrites the From header or changes the SMTP identity that DMARC authenticates against. The receiving server in a forwarding chain is not the same entity that DMARC was configured to expect, so authentication results that were valid at the original hop become invalid by the time the message reaches the final destination.

This is not a bug. It is how DMARC is designed to work. The protocol authenticates the organization that sent the message, and forwarding fundamentally changes that organizational chain.

The technical mechanism: SPF, DKIM, and From header rewriting

DMARC works by checking two authentication results: SPF and DKIM. Both are tied to specific identities that forwarding disrupts.

SPF breaks on forward because the forwarding server is not in your SPF record.

When your mail server sends a message, it uses your domain in the EHLO/HELO command. Your SPF record authorizes your mail server IP addresses to send mail for your domain. When that message gets forwarded, the forwarding server receives it and forwards it onward from its own IP. The destination server sees a message from your domain coming from an IP that is not in your SPF record. SPF fails. If your DMARC policy requires SPF to pass, the message fails DMARC.

DKIM breaks on forward if headers or body are modified.

DKIM signs specific headers and optionally the body. A forwarding server that adds Received headers does not break DKIM. But many forwarding scenarios involve more than that. Mailing list servers often rewrite the Subject header, add footer text, or modify headers for threading. Some enterprise mail gateways re-envelop messages. Any of these changes can invalidate the DKIM signature, causing DKIM to fail at the receiving server.

DMARC alignment fails because neither SPF nor DKIM can match the original domain after forwarding.

DMARC has a concept called alignment. Even when SPF or DKIM passes technically, the authenticated domain must align with the From header domain. SPF alignment checks whether the domain in the EHLO/HELO command matches the domain in the From header. DKIM alignment checks whether the domain in the DKIM signature matches the From header domain. After forwarding, neither condition holds reliably. The forwarding server IP appears in SMTP transactions, and any header modifications can break DKIM.

Which forwarding scenarios cause the most failures

Not all forwarding is equal in the eyes of DMARC. Here is where it breaks most often.

Personal email forwarding rules.

Some users set up their mail client or provider to automatically forward all incoming mail to a personal Gmail or Outlook address. The destination receives mail that appears to come from the original sending domain but is relayed through an unauthorized server. SPF fails. DKIM may survive if no headers were modified, but without SPF alignment, DMARC fails.

Mailing list servers.

Mailing list servers are the most disruptive to DMARC. They typically forward messages from subscribers to the list membership. The From header still shows the original sender, but the mailing list server is the sending entity. Most major mailing list software (Mailman, Sympa, Microsoft 365 distribution lists) rewrites headers for threading or adds list-specific footer content, which invalidates DKIM signatures. SPF also fails because the forwarding server IP is not in the original sender SPF record.

Enterprise mail gateway forwarding.

Some organizations route mail through a third-party gateway for filtering or archiving before delivering it to the final mailbox. If the gateway does not apply proper DKIM signing or does not preserve the forwarding chain correctly, DMARC failures can appear in aggregate reports even though the original sender is legitimate.

Auto-forwarding via domain-level rules.

Domain-level forwarding rules, often configured at the DNS or hosting provider level, forward all mail from one domain to another. This is common during domain migrations or when consolidating email accounts. The same SPF and DKIM alignment failures occur, but at a larger scale.

How to fix or work around DMARC failures on forwarded email

There are three main approaches, depending on who controls the forwarding infrastructure and how much engineering effort is available.

SRS: Sender Rewriting Scheme.

SRS modifies the envelope sender (Return-Path) during forwarding so that SPF passes at the destination. The forwarding server rewrites the envelope sender domain to its own domain, then includes the original sender address in a rewritten address. The receiving server sees SPF passing for the forwarder domain, not the original sender domain. DMARC alignment then depends on DKIM. SRS is the standard approach for mailing list operators and large forwarding services. It requires the forwarder to implement SRS support. Several open-source SRS implementations exist, including the Perl Mail::SRS package and Go-based alternatives.

ARC: Authenticated Received Chain.

ARC is a more recent addition to the email authentication ecosystem and is specifically designed for forwarding and mailing list scenarios. It adds a chain of intermediate authentication results to each message header. The first receiving server (such as a mailing list server or forwarding service) adds an ARC-Seal header that records the authentication results it observed. The next server in the chain can read this seal and understand that the message passed through a legitimate intermediate server before reaching the final destination. Some receiving servers, including several large email providers, use ARC to make more informed trust decisions about forwarded messages. ARC does not replace DMARC. It supplements it by preserving authentication context across a forwarding chain.

List-Unsubscribe and mailing list best practices.

For mailing list operators, RFC 8058 specifies a one-click list-unsubscribe mechanism. List operators should publish List-Unsubscribe-Post header fields and ensure List-Unsubscribe links work correctly. This does not fix DMARC failures directly, but it reduces the incentive for recipients to mark messages as spam, which protects the sender reputation. Mailing list operators should also consider moving to a model where the list server appears as the sender rather than trying to forward while preserving the original From header.

For organizations receiving forwarded mail that fails DMARC.

If your organization receives legitimate forwarded mail that fails DMARC, the options are limited from your side. You can work with the sender to implement ARC, or you can configure your mail gateway to handle forwarded mail as a trusted forwarding scenario. Some enterprise email providers allow administrators to create inbound rules that exempt forwarded mail from strict DMARC enforcement. This is a configuration decision that depends on your mail gateway and the importance of the forwarded traffic.

How DMARCFlow helps monitor forwarded email failures

Forwarding-related DMARC failures are invisible without aggregate report monitoring. Unlike SPF or DKIM failures that show up in mail server logs, DMARC failures from forwarding only appear in the daily aggregate reports that receiving servers send back. Most organizations never look at these reports, which means forwarding problems go undetected until a user complains that their mail is not arriving.

DMARCFlow processes these aggregate reports and surfaces patterns that would otherwise require manual parsing of XML files. If forwarding is causing legitimate mail to fail DMARC, DMARCFlow shows which forwarding scenarios are involved, which domains are affected, and whether the failures are increasing or decreasing over time. This matters because forwarded email failures are not always obvious. A user whose mail is silently dropped after forwarding will not know why. The sender sees their mail accepted by the forwarding server but never arrives at the final destination. Aggregate reporting is the only place this failure mode shows up.

For organizations that operate forwarding rules or mailing lists, DMARCFlow also tracks whether your own outbound forwarding is generating DMARC failures for the people you send mail to. If your forwarding setup causes DMARC failures at destination servers, that is something you can detect and fix before it affects your email program.

FAQ

Does DMARC work with email forwarding?

DMARC authenticates the original sending domain, not the forwarding chain. Forwarding changes the SMTP path, which causes SPF and DKIM to fail at the receiving server. This is working correctly. DMARC is not broken; forwarding is simply incompatible with how DMARC validates the sending organization identity.

Why does SPF fail on forwarded email?

SPF authorizes specific IP addresses to send mail for a domain. A forwarding server IP address is not in the original sender SPF record, so SPF fails when the forwarding server relays the message. This is expected behavior.

What is SRS and does it fix DMARC failures on forwarded email?

SRS (Sender Rewriting Scheme) rewrites the envelope sender during forwarding so that SPF passes for the forwarder domain. It does not fix DMARC alignment for the original sender From header, but it prevents SPF failures from causing DMARC failures. The forwarded message will still fail DMARC alignment unless DKIM also survives the forwarding process.

Can you use DKIM to fix forwarding issues?

DKIM signatures survive forwarding as long as the forwarding process does not modify signed headers or the message body. If the forwarding server adds only Received headers and does not modify any signed content, DKIM can pass. In practice, many forwarding scenarios involve header or body modifications that invalidate DKIM signatures.

What is the difference between SRS and ARC?

SRS rewrites the envelope sender address so that SPF passes at the next hop. ARC preserves the original authentication results in a chain of sealed headers so that downstream servers can see that the message was authenticated at an earlier point in the chain. They address different parts of the forwarding problem. SRS fixes SPF; ARC preserves authentication context. They are complementary.