How Email Forwarding Breaks DMARC (And What to Do)

When email forwarding breaks DMARC, it catches people off guard. You have set up SPF, DKIM, and DMARC correctly. Your reports show everything passing. Then a forwarded message bounces or lands in spam, and you do not understand why.

The problem is not your configuration. The problem is that forwarding changes the sending infrastructure without changing the From header, and DMARC alignment is sensitive to that mismatch.

If you use DMARCFlow, forwarding failures show up in your aggregate reports as alignment mismatches between your From header domain and the forwarding domain. The report tells you which sending domain failed and why. Most people do not notice the signal until a forwarded message gets blocked.

What DMARC alignment actually checks

DMARC does two separate things. First, it checks whether SPF or DKIM passes. Second, it checks whether the domain that passed SPF or DKIM aligns with the domain in the message's From header.

The From header is what users see as the sender. It is what matters for reply-to decisions and what most MUAs display. SPF and DKIM validate the sending server or the signing domain, not the From header domain.

Alignment passes when the domain validated by SPF or DKIM matches the From header domain. When they do not match, DMARC fails - even if both SPF and DKIM individually pass.

What forwarding does to alignment

When a message is forwarded, the forwarder receives it and resends it to the final destination. The original From header stays the same. But the new sending server is the forwarder, not the original sender.

If the forwarder adds its own SPF record and sends on its own domain, SPF validates against the forwarder's domain, not the original sender's domain. The From header still shows the original sender. DMARC alignment fails because the SPF-validated domain and the From header domain do not match.

DKIM survives forwarding more gracefully, but only if the forwarder does not modify headers or content. If the forwarder changes either, DKIM breaks. And even when DKIM survives, if the forwarder also relays on its own domain for SPF, alignment fails on the SPF side.

RFC 7489 Section 6.3 describes the forwarding model: the forwarder becomes the last-hop sender, and the original authentication results do not automatically transfer to the new sending context.

A real forwarding chain

1. Alice sends from alice@example.com. SPF passes on example.com. DKIM signs with example.com. DMARC alignment passes.
2. The message goes through a cloud email gateway that resends from gateway-relay.com. SPF now validates gateway-relay.com, not example.com.
3. The From header still shows alice@example.com.
4. SPF alignment fails: gateway-relay.com does not match example.com.
5. If DKIM was stripped or the selector changed, DKIM alignment may also fail.
6. DMARC fails even though the original sender is legitimate.

This is not a configuration error. It is a structural consequence of how forwarding works.

SRS: Sender Rewriting Scheme

SRS is the standard fix for forwarding-related alignment failures. The forwarder rewrites the Return-Path header (the envelope-from) to its own domain, then stores the original envelope-from as a proxy. When the message is resent, SPF validates against the forwarder's rewritten domain instead of the original sender's domain.

The catch is that SRS requires the forwarder to support it. Many forwarding services and mailing lists do not implement SRS. Those that do still do not fix DKIM alignment unless they also re-sign the message on the original sender's behalf.

If you operate a forwarder, implementing SRS is the correct approach. If you rely on third-party forwarders, you need to check whether they support SRS or re-sign messages - otherwise accepting forwarding failures is part of the tradeoff.

Subdomain strategy as a workaround

Some organizations use a dedicated subdomain for addresses that are forwarded. The main domain uses strict DMARC. The forwarding subdomain uses a permissive policy.

For example, dmarc.example.com might use p=none while example.com uses p=quarantine or p=reject. Addresses likely to be forwarded use the subdomain. When those messages are forwarded, the From header shows the subdomain, alignment passes, and DMARC failures are avoided.

This trades DMARC protection for deliverability. Use it only when forwarding is unavoidable and the security tradeoff is acceptable.

Diagnosing forwarding failures in DMARC reports

Forwarding failures show up as alignment failures on the SPF or DKIM axis. You see the forwarding domain as the sending infrastructure while your From header domain appears in the failure record.

DMARCFlow aggregate reports show which authentication domain failed alignment and whether the failure is SPF-related or DKIM-related. A pattern of failures from forwarding domains that do not match your own infrastructure is a forwarding signal, not a spoofing signal. DMARCFlow helps you distinguish between the two.

When you see failures from known forwarding services - mailing lists, cloud gateways, email relays - check with those providers on SRS support or whether they re-sign messages on behalf of senders.

When relaxed alignment makes sense

DMARC has two alignment modes: relaxed and strict. Relaxed alignment accepts subdomains of the organizational domain. Strict alignment requires exact domain match.

For environments where forwarding is unavoidable and SRS is not available, relaxed alignment reduces false positives. It is weaker because subdomain takeovers can abuse it. But it is a practical choice when the alternative is chronic DMARC failures that break legitimate mail flow.

You can also use p=none while you investigate. It disables enforcement but keeps reporting active, so you can monitor the scope of forwarding failures before committing to a policy change.

What you can actually do

If forwarding is breaking your DMARC:

1. Identify which forwarders are causing failures. Check your DMARC reports for the sending domains that are failing alignment.
2. Ask those forwarders whether they support SRS or re-sign messages on behalf of senders.
3. If you operate the forwarder, implement SRS.
4. Use a subdomain strategy for forwarding-sensitive addresses while keeping strict DMARC on your main domain.
5. Run p=none with reporting while you investigate, then upgrade to quarantine or reject once forwarding issues are resolved.

Forwarding-related DMARC failures are common and legitimate. They do not mean your domain is being spoofed. They mean the forwarding chain broke the alignment assumption that DMARC relies on. Understanding the chain helps you decide whether to fix the forwarder, change your policy, or accept the gap.

---

Frequently asked questions

Can SPF pass and DKIM fail during forwarding?
Yes. If the forwarder modifies content or headers, DKIM validation breaks. SPF may still pass because the forwarder's server is authorized to send. But if the From header domain does not match the forwarder domain, DMARC alignment fails regardless.

Does DMARC p=none stop forwarding failures?
p=none disables enforcement but not reporting. You still see the failures in your aggregate reports. Enforcement is what causes forwarded messages to bounce or land in spam. p=none lets them through but keeps you informed.

Can mailing lists forward without breaking DMARC?
Yes, if they implement SRS or re-sign messages on behalf of the original sender. Many major mailing list providers do one or both. Some do neither. Check with your provider.

Does forwarded email show up in DMARC reports?
Yes. The forwarded message is resent by the forwarder's infrastructure. Your DMARC reports show the forwarder's domain as the sending IP, and the alignment failure appears in your aggregate data.