How Email Forwarding Breaks DMARC (And How to Fix It)

Introduction: The Forwarding Problem

You set up DMARC, get p=none working for direct mail, then switch to p=quarantine or p=reject. The first rejections arrive within hours: forwarded messages. Your SPF record is correct. Your DKIM is signing. Your users forwarded work email to a personal Gmail account and it got rejected or quarantined.

This is not a DMARC misconfiguration. It is how SMTP forwarding works. The solution is not to weaken your DMARC policy. It is to understand the mechanism and apply the right fix for your setup.

Why Forwarding Breaks DMARC: The Technical Mechanism

SMTP Forwarding and the MAIL FROM Domain

SMTP uses two different "from" addresses. The From: header is what users see in their email client. The MAIL FROM envelope is what servers use to determine who sent the message at the protocol level. These are not the same thing.

When a forwarder receives a message and resends it, it becomes the new sending server. The MAIL FROM envelope still shows your domain, but the sending IP is now the forwarder's. The original envelope information is effectively replaced at each hop.

SPF: Why Forwarding Always Breaks SPF for the Original Domain

SPF checks whether the sending server's IP address is authorized for the domain in the MAIL FROM envelope. When a forwarder resends your message, the sending IP is the forwarder's, not yours.

The receiving server looks up SPF for your domain, sees that your SPF record does not include the forwarder's IP address, and fails the check. There is no SPF configuration you can apply to make your record include every forwarder that might ever touch your messages.

Forwarders would need to implement SRS (covered below) to rewrite the MAIL FROM when they resend, making SPF pass for their own infrastructure.

DKIM: What Survives Forwarding and What Does Not

DKIM signs selected headers and the message body. A valid signature survives forwarding only if the forwarder does not modify anything that was signed.

Forwarders typically break DKIM in one of three ways:

Adding a "forwarded by" banner or disclaimer to the message body, which changes the body hash
Stripping headers that are part of the DKIM signature (such as Subject: or Date:)
Re-encoding the message in a way that alters the content (common with HTML email and inline image handling)

A simple text-only forward with no modifications may preserve DKIM. Most real-world forwarding scenarios do not meet that bar.

Even when DKIM survives, DMARC alignment still requires the signing domain to match the From: header domain. A message signed by your ESP, forwarded by a third-party tool, still needs DKIM alignment to your domain to pass DMARC.

DMARC Alignment: Why Both p=reject and p=quarantine Catch Forwarded Mail

DMARC requires either SPF alignment (envelope MAIL FROM matches From: header domain) or DKIM alignment (signing domain matches From: header domain).

Forwarded mail fails SPF alignment because the MAIL FROM domain is your domain but the sending IP is the forwarder's. It often fails DKIM alignment for the reasons described above. With p=quarantine, the message lands in spam. With p=reject, it is dropped.

What Forwarding Failures Look Like in DMARC Aggregate Reports

In your DMARC aggregate reports (sent to the address in your rua: DNS record), forwarded messages that fail DMARC appear with a source IP belonging to the forwarder, not your mail servers. You typically see high volumes of failures from a small number of external IP addresses. The failure reason says "SPF alignment fail" or "DKIM alignment fail" or both.

This pattern is distinct from spoofing: spoofed messages come from random IPs across the internet, while forwarding failures concentrate at specific forwarder infrastructure.

If you see forwarding failures in your reports but direct mail is working fine, those failures are likely legitimate forwarded messages caught by your policy.

How to Fix Forwarding-Related DMARC Failures

SRS: Sender Rewriting Scheme

SRS is the proper forwarder-side fix. When a forwarder resends a message, SRS rewrites the MAIL FROM envelope to a domain the forwarder controls, making SPF pass for the forwarder's sending IP. The forwarder stores a mapping so replies route correctly.

If you run your own forwarders (a mail gateway, an internal relay), implementing SRS is the right solution. SRS implementations exist for Exim, Postfix, Sendmail, and other common MTAs. The Sender Rewriting Scheme is documented in RFC 6377.

If your forwarder is a third party (an ISP auto-forward, a mailing list service, a CRM email feature), you cannot implement SRS on their infrastructure. You need either ARC or a different mitigation.

ARC: Authenticated Received Chain

ARC (RFC 7001) adds a chain of authentication results at each forwarding step. When a server receives a forwarded message, it adds an ARC header recording the SPF, DKIM, and DMARC results at that hop. The final receiving server can inspect the ARC chain and make a more informed deliverability decision.

Major mailbox providers including Google and Microsoft factor ARC into their filtering decisions. If your forwarder preserves ARC headers, your p=reject policy is less likely to cause forwarding failures at those providers.

To benefit from ARC, your forwarder must be configured to add ARC headers. Check your MTA documentation. If you control the forwarder, enable ARC handling.

List-ID and Feedback-ID Headers

For mailing list forwarding specifically, the List-ID header (RFC 4021) provides a machine-readable identifier for the mailing list. Feedback-ID (used by Google, Microsoft, and others for abuse reporting) gives providers additional context about where a message originated.

These headers do not fix SPF or DKIM alignment directly. They give mailbox providers information to treat forwarded list mail differently from direct spoofed mail. Many providers give mailing lists more latitude than unprompted forwarded messages.

Adjusting Your DMARC Policy as a Last Resort

If you cannot implement SRS or ARC, lowering your policy from p=reject to p=quarantine reduces the impact. Forwarded mail goes to spam instead of being rejected.

This is a workaround. Weakening DMARC to accommodate forwarding leaves your domain exposed to spoofing. Only consider this when proper mitigations are genuinely unavailable, and monitor your aggregate reports closely if you do.

How to Monitor Forwarding Failures with DMARC Aggregate Reports

You need aggregate reports delivered somewhere you actually check. If your rua: address goes unmonitored, you will not see forwarding failures until users report missing mail.

When reviewing reports, look for:

High failure counts from a single external IP that is not your mail server
Consistent "SPF alignment fail" or "DKIM alignment fail" reasons
Failures that correlate with your users' forwarding activity

Forwarding failures are easy to miss if you are not looking for them specifically. DMARCFlow parses aggregate reports and identifies forwarding-related alignment failures automatically, so you can distinguish forwarding patterns from actual spoofing without manually reviewing XML data.

When Forwarding Failures Are Acceptable

Some forwarding failures are expected:

Auto-forwarding to personal accounts: If your users forward work email to Gmail or similar, you will see failures from Google's forwarding infrastructure. Whether that is acceptable depends on your security policy.
Mailing lists with non-compliant forwarders: Some list services do not implement SRS or ARC. Mail from those lists may fail DMARC at strict policies.
Third-party forwarding tools: CRM email features, marketing automation platforms, and similar tools often forward mail on your behalf. Those forwarding paths may need explicit SPF includes or aligned DKIM signatures.

Some forwarding failures indicate a real problem:

A misconfigured mail server forwarding without proper handling
A compromised account being used as an unauthorized relay (usually shows unusual volume or timing patterns)
An auto-forwarding rule set up by a departed employee

Key Takeaways

Forwarding breaks DMARC because the forwarder becomes the sending server, invalidating SPF and DKIM alignment
SPF cannot survive forwarding without SRS on the forwarder
DKIM survives forwarding only when the forwarder does not modify signed content
SRS fixes forwarding at the forwarder; ARC preserves authentication context through the forwarding chain
Weakening your DMARC policy is a last resort, not a proper fix
Review your aggregate reports regularly to distinguish forwarding failures from spoofing

FAQ

Does forwarding break DMARC?
Yes. When a forwarder resends a message, the sending server changes, causing SPF and DKIM alignment failures that DMARC catches. The forwarder's IP is not in your SPF record, and modifications to the message body break DKIM signatures.

How do I stop DMARC from rejecting forwarded emails?
Implement SRS on your forwarder so the MAIL FROM is rewritten to match the forwarder's domain. Alternatively, ensure your forwarder supports ARC, which preserves authentication context through the forwarding chain and helps receiving servers make better filtering decisions.

What is SRS for email?
Sender Rewriting Scheme (SRS) rewrites the MAIL FROM envelope address when a message is forwarded, so SPF checks pass against the forwarder's IP rather than the original domain. RFC 6377 documents the scheme.

Does DKIM survive email forwarding?
DKIM can survive forwarding only if the forwarder does not modify any signed content. In practice, most forwarders add disclaimers, re-encode HTML, or strip headers, which all break the DKIM signature.

Can I just set p=none to avoid forwarding problems?
Setting p=none disables DMARC enforcement. Your domain becomes easier to spoof. Use p=none only during DMARC monitoring and deployment, not as a permanent workaround for forwarding issues.