Why DMARC Fails When Emails Are Forwarded (And What to Do About It)

When you forward an email from one mailbox to another, the forwarded message may suddenly fail DMARC checks even though the original sender's SPF and DKIM records are correctly configured. The bounce or rejection arrives without warning. The sender has done nothing wrong. The forwarder has done nothing obviously wrong either. This is one of the most common DMARC headaches in practice, and it has a specific technical cause.

This article explains why DMARC fails when mail is forwarded, what happens to SPF and DKIM in the forwarding chain, and what practical options exist for both domain owners and forwarder operators.

How email forwarding works at the SMTP level

When mail flows through SMTP, two different sender identities matter. The envelope sender (RFC5321.MailFrom) tells mail servers where to send bounces. The From header (RFC5322.From) is what the recipient sees in their email client. SPF checks the envelope sender. DMARC checks alignment between the envelope sender and the From header.

When you forward mail, your mail server receives the message and then resends it to the final destination. From the perspective of the next mail server in the chain, your forwarder is now the new sender. Your forwarder becomes the envelope sender. This is normal and expected behavior.

The problem is that the original sender's authentication results (SPF pass, DKIM pass) were computed at the first mail server. The forwarder now needs to either preserve those results or re-authenticate on behalf of the original sender. Most forwarders do neither, which breaks DMARC.

What happens to SPF when mail is forwarded

SPF checks whether the IP address sending mail is authorized for the domain in the envelope sender (MailFrom). When a forwarder receives mail and then resends it to the final destination, the forwarder's IP address becomes the sending IP. The original sender's SPF record has no knowledge of the forwarder's IP. SPF therefore fails at the final destination mail server.

This is not a bug. SPF was designed to track the direct sender, not a chain of forwarders. For most forwarding setups, SPF will fail at the final delivery point unless special measures are taken.

There is one exception: if the forwarder uses SRS (Sender Rewriting Scheme), it rewrites the envelope sender to an address controlled by the forwarder. This lets SPF pass at the forwarder's MTA, and the rewritten address routes bounces back to the original sender. SRS is common among large mailing list operators and some corporate forwarders. It is not universally deployed.

What happens to DKIM when mail is forwarded

DKIM attaches a cryptographic signature to email headers. A DKIM signature survives forwarding as long as the forwarder does not modify any of the signed headers and does not add headers that conflict with the signature.

In practice, most forwarders modify headers in ways that break DKIM. Adding a Received header, modifying the Subject header, or adding any content-based header will invalidate the signature on most configurations. When the final receiving mail server checks the DKIM signature, it finds a mismatch and DKIM fails.

DKIM has a better chance of surviving forwarding than SPF, but only if the forwarder is careful. A forwarder that adds minimal headers and does not modify existing ones may preserve DKIM. In most real-world forwarding scenarios involving mailing lists, auto-forwarders, or organizational relays, DKIM does not survive.

Why DMARC alignment fails in the forwarding chain

DMARC requires at least one of SPF or DKIM to pass and for the domain in the envelope sender (or the d= domain in the DKIM signature) to align with the RFC5322.From domain.

When mail is forwarded: - SPF may fail because the forwarder IP is not in the original sender's SPF record - DKIM may fail because headers were modified during forwarding - Even if SPF or DKIM passes individually, alignment is likely broken because the envelope sender domain (MailFrom) has changed to the forwarder's domain

The result is a DMARC failure at the final destination, even though the original sender did everything correctly.

ARC (Authenticated Received Chain): how forwarders can preserve authentication

ARC was designed specifically to solve the forwarding authentication problem. It adds a chain of headers that records the authentication results at each step in the forwarding chain.

When a forwarder receives mail with valid SPF or DKIM, it can add an ARC-Seal header that records those authentication results. The final receiving mail server can then see not just the current authentication state, but the chain of results from the original sender through each forwarder.

Gmail, Microsoft 365, and several other major mailbox providers check ARC when evaluating DMARC for forwarded messages. If the original SPF and DKIM passed and the forwarder properly added ARC headers, the final receiver can treat the forwarded message as authenticated even though the immediate sending MTA is the forwarder.

Implementing ARC requires the forwarder to: 1. Check SPF and DKIM when receiving mail 2. Add an ARC-Seal header with the authentication results 3. Avoid modifying headers that would break DKIM before sealing

Not all forwarders support ARC. Most consumer-grade forwarding services do not implement it. Some corporate mail relays, mailing list services, and specialized forwarding providers do.

SRS (Sender Rewriting Scheme): an alternative approach

SRS takes a different approach. Instead of preserving the original authentication results, it rewrites the envelope sender address to one controlled by the forwarder, then rewrites it back when bounces occur.

When a forwarder using SRS receives mail from user@example.com, it rewrites the envelope sender to something like srs0=abc=def=example.com@forwarder.com. The forwarder's SPF record covers its own domain, so SPF passes at the next MTA. When a bounce is generated, the forwarder receives it and rewrites the envelope back to the original sender to route the bounce correctly.

SRS is primarily used by high-volume mailing list operators. It requires careful configuration and is not typically deployed by standard email forwarders or consumer mail services.

What to do as a domain owner who wants to receive forwarded mail

If you operate a domain and want to receive forwarded mail without DKIM and SPF breaking at the destination, you have several options.

Use a subdomain specifically for forwarding. Set up a subdomain like fwd.example.com and configure your SPF, DKIM, and DMARC records for that subdomain separately. Use p=none on the forwarding subdomain so forwarded mail is less likely to fail DMARC at the destination. Keep your primary domain's DMARC policy strict.

Relax your DMARC policy temporarily. Setting p=quarantine instead of p=reject lets forwarded mail pass DMARC even when alignment fails. You still receive aggregate reports, which show you how many legitimate messages are affected and help you decide when it is safe to tighten your policy.

Work with your forwarding provider. Ask whether they implement ARC or SRS. If they do not, ask whether they would consider it. Some forwarding services are adding ARC support specifically because their customers run into this problem.

Use DMARC aggregate reports to diagnose the problem. DMARC reports show which sending IPs are failing alignment for your domain. If you see failures from IPs that belong to known forwarders, you can quantify the impact and decide whether to adjust your policy or work with the forwarder. DMARCFlow processes these reports automatically and flags forwarding-related failures by source IP and frequency, so you can see at a glance whether a specific forwarder is causing ongoing issues for your domain.

What to do as a forwarder operator who wants to avoid breaking DMARC

If you operate a mail forwarding service or corporate mail relay, the responsibility falls on you to handle the authentication chain correctly.

Implement ARC. This is the cleanest solution for preserving authentication through the forwarding chain. Add ARC headers when you receive mail with valid SPF or DKIM results. Do not modify signed headers between receipt and delivery.

Consider SRS for high-volume mailing lists. If you run a mailing list, SRS is a well-understood approach that lets you preserve SPF compliance while ensuring bounces route correctly.

Use a dedicated sending domain. If you forward mail, send it from a domain you control rather than attempting to preserve the original sender's identity. Make sure your SPF record covers your sending infrastructure.

Add an Authentication-Results header. While not as robust as ARC, adding an Authentication-Results header that reflects the original SPF and DKIM results gives downstream receivers more context.

How to diagnose forwarding-related DMARC failures

DMARC aggregate reports (ruf) sent to your configured address are the primary diagnostic tool. Look for: - Source IPs that belong to forwarders or mailing lists in your Authentication-Results - Disposition: fail alongside reason: alignment - Patterns: high volume from a single source IP that does not appear in your normal sending infrastructure

You can use a DMARC monitoring tool to aggregate these reports and surface patterns. DMARCFlow parses aggregate reports and highlights forwarding-related failures specifically, showing you which forwarders are causing DMARC failures for your domain and how often.

Quick-reference checklist

For domain owners: - Check your DMARC aggregate reports for forwarding-related failures - Use a dedicated subdomain for forwarding services - Set p=quarantine before p=reject if you need to accommodate forwarding - Ask your forwarding provider whether they support ARC

For forwarder operators: - Implement ARC to preserve authentication results through the forwarding chain - Avoid modifying headers that are covered by DKIM signatures - Use SRS if you run a high-volume mailing list - Send forwarded mail from a domain you control with proper SPF coverage

FAQ

Why does my forwarded email get rejected even though SPF and DKIM passed?

SPF and DKIM may have passed at the original MTA, but DMARC alignment requires the envelope sender domain (or the DKIM d= domain) to match the visible From header domain. When a forwarder resends mail, the envelope sender becomes the forwarder's domain, breaking alignment. DMARC then fails even though the original sender's records are correct.

Does DKIM survive forwarding?

It depends on the forwarder. If the forwarder does not modify any signed headers and does not add problematic headers, DKIM may survive. In practice, most forwarders add or modify headers in ways that break DKIM signatures.

What is ARC?

ARC (Authenticated Received Chain) is an email header standard that lets forwarders preserve and communicate the original SPF, DKIM, and DMARC authentication results through the forwarding chain. It was introduced specifically to solve the DMARC forwarding problem. Major mailbox providers including Gmail and Microsoft 365 check ARC when evaluating forwarded mail.

What is SRS?

SRS (Sender Rewriting Scheme) is a technique where the forwarder rewrites the envelope sender address so that SPF passes at the forwarder's MTA. The address is rewritten back when bounces occur. SRS is primarily used by high-volume mailing list operators rather than simple forwarders.

Should I set my DMARC policy to p=none if I forward mail?

p=none disables enforcement but still generates aggregate reports. If you need to receive forwarded mail and cannot get the forwarder to implement ARC or SRS, p=none is a pragmatic fallback. You still get reports, which help you measure the impact and decide when it is safe to tighten your policy back up.