Why DMARC Fails When Emails Are Forwarded or Sent Between Gmail and Exchange

The Scenario That Breaks DMARC Without Breaking Mail

A user sets up an email forward from their corporate Exchange server to a Gmail address. The forwarded messages start failing DMARC at the receiving end, even though the original Exchange server had valid SPF and DKIM configured. Or: an organization sends mail from an internal Gmail Workspace account to an external Exchange on-premises recipient, and the receiving server reports DMARC failure despite everything looking correct at the sending side.

This is one of the most common DMARC failure patterns in hybrid and multi-platform email environments. The root cause is not a configuration error. It is how DMARC alignment works when intermediate mail servers modify message routing during transit.

How Email Forwarding Changes the RFC 5321 Sender

Every email has two sender identities that matter for authentication:

• RFC 5321 MAIL FROM (envelope sender or return path): the address that bounce messages go to. Set by the transmitting mail server, not the email client.
• RFC 5322 From header: the From address shown in email clients. What users see.

When an email passes through a forwarding server, that server often rewrites the RFC 5321 MAIL FROM address to its own domain. The forwarding server becomes the new RFC 5321 sender. The original envelope sender from the original sending domain is lost from the authentication chain.

Gmail-to-Exchange scenarios trigger the same effect when transport rules, antivirus scanning gates, or email security gateways (Proofpoint, Mimecast, Avanan) modify the envelope sender during processing. The From header still carries the original domain, but the authenticated identity now belongs to a different domain entirely.

What DMARC Alignment Actually Checks

DMARC runs two checks in sequence:

1. Authentication check: SPF, DKIM, or both are evaluated. This tells you whether the sending server is authorized and whether the message was signed.
2. Alignment check: The authenticated identity is compared against the RFC 5322 From header domain.

Both must pass for DMARC to pass. You can have perfect SPF and DKIM results but still get a DMARC fail if the alignment check fails.

Alignment means: the domain in the RFC 5321 MAIL FROM (for SPF) or the domain in the DKIM signature (for DKIM) must match or be a subdomain of the RFC 5322 From header domain under relaxed alignment, or match exactly under strict alignment.

When a forwarder rewrites the RFC 5321 sender to its own domain, SPF may still pass on the forwarder's IP, but the alignment check fails because the forwarder's domain does not match the original From header domain.

The Two Alignment Modes: Relaxed vs Strict

DMARC has two alignment modes:

Relaxed alignment: the authenticated domain only needs to be a parent domain of the RFC 5322 From header domain. If your From header is sender@example.com and your DKIM signature is signed by example.com, that counts as aligned under relaxed mode.

Strict alignment: the authenticated domain must match the RFC 5322 From header exactly. sender@example.com as From must have an aligned DKIM signature from sender@example.com, not just from example.com.

Most organizations use relaxed alignment because it accommodates legitimate subdomain sends and third-party email processors. Strict alignment breaks many normal email flows and is rarely used in production.

When forwarded mail fails DMARC under relaxed alignment, it means the forwarder's domain is so far removed from the original From header domain that even relaxed alignment cannot bridge the gap.

Why Gmail-to-Exchange Forwarding Fails DMARC

When a message originates from Gmail and is delivered to an Exchange on-premises server, several things can happen:

• Transport rules on the receiving Exchange server may rewrite headers or reroute messages in ways that break DKIM signatures.
• Antivirus, anti-spam, or DLP scanning gates may modify message content, which also invalidates DKIM signatures.
• If the message is then forwarded onward, the RFC 5321 sender becomes the Exchange server's domain, not the original Gmail domain.

The receiving server, applying DMARC policy, sees a From header from gmail.com but an authenticated identity from an Exchange or relay domain. No aligned result exists, so DMARC fails.

This is not a Gmail problem or an Exchange problem. It is a fundamental artifact of how DMARC enforces alignment across mail flows that cross organizational boundaries.

What ARC Does (Authentication Results Certification)

ARC (Authentication Results Certification) is an extension to email authentication designed to help with forwarded and multi-hop mail flows.

The mechanism: each server in the forwarding chain adds an ARC header that preserves the original SPF, DKIM, and DMARC results from the previous hop. The final receiving server can then see the original authentication results alongside the current results and make a more informed delivery decision.

The practical problem: ARC adoption is uneven. Some major receivers honor ARC when making delivery decisions; others ignore it entirely. Early data suggests roughly half of large mailbox providers consider ARC results in their filtering logic, but this varies and changes over time. As of 2026, ARC helps in some scenarios but is not a universal workaround for forwarding-related DMARC failures.

What SRS Does (Sender Rewriting Scheme)

SRS (Sender Rewriting Scheme) is a technique where the original RFC 5321 sender domain is preserved in a rewritten address when mail is forwarded, so that bounce messages return to the original sender rather than disappearing into the void.

SRS effectively hides the original sending domain behind a rewritten address the forwarder controls, while maintaining enough information to route bounces back correctly. Some forwarders and email service providers implement SRS specifically to handle bounce handling for forwarded mail.

The tradeoff for DMARC: SRS can interfere with alignment because the rewritten sender domain does not match the original From header domain. Whether SRS helps or hurts DMARC compliance depends on the specific forwarder implementation and whether the receiving server evaluates the SRS rewritten address for alignment.

How to Diagnose Forwarding-Related DMARC Failures From Aggregate Reports

The DMARC aggregate report (RUA) is the primary diagnostic tool. Look for these patterns:

Forwarder signature in source data: The source_type field or source_name in the failure record reveals the organization of the failing server. Gmail forwarding, Office 365 relay servers, and known forwarders appear with their own domain identifiers.

Envelope sender mismatch: If the RFC 5321 MAIL FROM domain in the report does not match your sending domain, but the RFC 5322 From header still shows your domain, you are likely looking at a forwarding-related failure rather than spoofing.

Aligned DKIM vs unaligned SPF: A pattern where DKIM passes but alignment fails often indicates forwarding or a third-party processor that modifies the RFC 5321 sender. If only SPF is being evaluated and the forwarder is not in your SPF record, that also points to forwarding.

High volume from a single external IP with your From header: A forwarding service processing legitimate mail for your users shows up as a high volume of failures from a small set of IPs you do not control. These are not attacks -- they are expected forwarding artifacts.

The fastest way to surface and label these patterns across all your domains is to use a DMARC monitoring tool that automatically distinguishes forwarding failures from spoofing failures. DMARCFlow does this by cross-referencing failure sources against known forwarding and relay infrastructure, so you spend time on real problems rather than parsing XML reports to identify whether each failure source is a forwarder you recognize.

When Forwarding Failures Signal a Real Problem vs Normal Behavior

Not every forwarding-related DMARC failure means something is wrong. Use these criteria:

Normal and expected:

• Failures from known forwarding services where the forwarding is intentional or controlled by your users


• Failures from email security gateways that modify envelope routing (Proofpoint, Mimecast, Avanan)


• Failures from internal mail relay or transport servers that legitimately forward on your behalf without ARC


• Failures from mailing list processors that redistribute messages on your behalf

Worth investigating:

• Failures from IP ranges you do not recognize and cannot attribute to any known forwarding or processing service


• Sudden new failure patterns that coincide with a change in your mail infrastructure


• Failures where the RFC 5321 sender domain is unrelated to any service you use

The key signal is whether the RFC 5321 sender in the failure record maps to infrastructure you recognize as part of your legitimate mail flow. If it does not, the failure may indicate spoofing rather than forwarding.

FAQ

Q: If my forwarded emails fail DMARC, does that mean my domain is not protected?

A: No. Forwarding-related DMARC failures are expected in many legitimate mail flows and do not indicate your domain is being spoofed. They indicate that a forwarding server or mail processor is transmitting mail where the From header carries your domain but the authenticated identity belongs to the processor. This is normal behavior for many internal forwarding setups and email security gates.

Q: Should I set p=quarantine or p=reject if I use forwarding?

A: Only if you control the forwarding setup and can ensure the forwarder maintains ARC headers or uses SRS. For forwarding that is outside your control, you should expect and tolerate forwarding-related failures in your aggregate reports. Setting a strict policy in those cases will not block legitimate forwarded mail -- it will just generate failures you cannot act on.

Q: Does ARC solve the forwarding problem?

A: Partially. ARC preserves original authentication results through a forwarding chain, but adoption is inconsistent across receivers. Some major mailbox providers consider ARC results in their filtering decisions; others do not. ARC is a useful signal where it is available but does not universally solve DMARC alignment failures for forwarded mail.

Q: How do I tell from aggregate reports if a DMARC failure is from forwarding versus actual spoofing?

A: Look at the RFC 5321 sender domain in the failure record. If it maps to a known forwarding service or your own mail infrastructure, the failure is likely forwarding-related. If the RFC 5321 sender is an unrelated IP with no connection to any service you use, it may indicate spoofing.

Q: Can I prevent forwarding-related DMARC failures?

A: For forwarding you control, implementing ARC or SRS can help preserve alignment through the forwarding chain. For forwarding outside your control, the failures are a known limitation of DMARC. The practical answer is to monitor these failures in aggregate reports, treat them as expected behavior, and use that data to build a complete sender inventory before moving to p=reject.