Why DMARC Breaks on Forwarding (and How Google & Microsoft Cope)

An invoice from a critical vendor never arrives. The user swears it was sent, but your mail gateway logs show nothing. After a back-and-forth, you discover the vendor sent it to the user's personal Gmail, who has an auto-forwarding rule to their corporate inbox. Your gateway quarantined it for a DMARC failure. The email was legitimate, the sender was valid, but the authentication chain was broken in transit. Welcome to the messy reality of DMARC and email forwarding.

This isn't a rare edge case. It’s a fundamental conflict between how email authentication was designed and how people actually use email. Simple forwarding, a feature used by millions, is a primary source of legitimate mail failing DMARC checks. Understanding why this happens, and the workarounds deployed by major providers like Google and Microsoft, is a non-negotiable skill for any security analyst.

The core of the problem lies in a protocol that never anticipated its own success: SPF. When a simple forwarder enters the picture, the entire system of checks and balances can collapse.

The Domino Effect: How Forwarding Topples SPF Alignment

To see the break, you have to see the two different 'from' addresses in an email. There's the `RFC5322.From` header, which is what the user sees in their client. Then there's the `RFC5321.MailFrom` address, used in the SMTP envelope conversation, which specifies the return path for bounces. DMARC, as defined in RFC 7489, cares about both.

SPF (Sender Policy Framework, RFC 7208) works by checking if the connecting mail server's IP address is listed in the SPF record for the domain found in the `MailFrom` envelope address. If `invoices@acme.com` sends an email, their mail server's IP is in the SPF record for `acme.com`. The receiver checks, it matches, and SPF passes.

Enter the Forwarder

Now, imagine that email arrives at `user@gmail.com` and is automatically forwarded to `user@corp.com`. The 'forwarder' is now Google's mail server. It connects to `corp.com`'s mail server to deliver the message. The `corp.com` server sees an incoming connection from a Google IP. It looks at the `MailFrom` address, which is still `invoices@acme.com` in a simple forward. It then queries the SPF record for `acme.com`.

Of course, ACME Corp's SPF record doesn't list Google's mail servers. It only lists its own. The check fails. SPF breaks.

DMARC requires that either SPF or DKIM passes *and* aligns with the `From` header domain. With SPF's alignment now broken, the entire burden of passing the DMARC check falls to DKIM. If there's no DKIM signature, or if the forwarder modified the message body and broke the signature, the DMARC check results in a `fail` verdict. This is the mechanism that sends legitimate forwarded mail straight to quarantine.

Google's Fix: The 'Authentication-Results' Wrapper

Google, handling an immense volume of forwarded mail, recognized this problem early on. Their approach isn't to fix SPF, but to preserve the results of the *original* authentication checks and present them to the next hop.

When Gmail forwards a message, it can become the new sender, in a sense. It may rewrite the `MailFrom` to a `gmail.com` address, which solves the immediate SPF problem since Google's IP is obviously authorized to send for `gmail.com`. This is called Sender Rewriting Scheme (SRS). But that just fixes the forwarder's reputation, it doesn't help the final recipient validate the original sender.

Preserving the Original Verdict

The critical piece of evidence Google adds is the `Authentication-Results` header. This header is a standardized way for a mail server to stamp a message with the results of its own SPF, DKIM, and DMARC checks. When Gmail forwards the email, it includes this header, which documents the *original* successful authentication of the email from `acme.com`.

Authentication-Results: mx.google.com;
dkim=pass header.i=@acme.com header.s=s1 header.b=xyz;
spf=pass (google.com: domain of invoices@acme.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=invoices@acme.com;
dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=acme.com

A savvy downstream mail filter, like the one at `corp.com`, can parse this header. It sees that even though the immediate connection from Google's IP failed the SPF check for `acme.com`, Google itself is attesting that it received the email legitimately. This provides a strong signal to trust the message, even with a technically failed DMARC alignment check at the final hop.

Microsoft's Approach: Trusting the DKIM Signature

Microsoft's Exchange Online Protection (EOP) also has mechanisms to deal with these forwarding scenarios, but it often places a heavier emphasis on a surviving DKIM signature.

Like Google, Microsoft systems can use SRS and will stamp their own `Authentication-Results` header. But operationally, we see that the integrity of an aligned DKIM signature (RFC 6376) is paramount in EOP's evaluation of forwarded mail. If an email arrives with a broken SPF alignment but carries a valid DKIM signature where the signing domain (`d=`) aligns with the `From` header domain, EOP is more likely to honor that signal and pass the message.

DKIM's Fragility in Forwarding

This reliance creates its own failure mode. DKIM works by creating a cryptographic hash of the message body and selected headers. If a forwarder, particularly an older system or a mailing list server, modifies the message in any way, the hash will change and the DKIM signature will fail to verify.

Common modifications include adding a footer like "This message was forwarded by..." or changing the Subject line by adding a prefix like `[EXTERNAL]`. Even tiny changes to whitespace can be enough to break the signature. When this happens, and SPF has already been broken by the forward itself, the message has no remaining authentication signals. DMARC fails, and the message is rejected or quarantined, just as Microsoft's security posture intends.

This makes it absolutely critical for domain owners to not only implement DKIM but also monitor for signature breakages. If your valid emails are failing DKIM, it's often due to an intermediary rewriting the content.

The Real Fix: The Authenticated Received Chain (ARC) Standard

The provider-specific headers were a good stopgap, but the internet needs standards. The IETF's answer to the DMARC forwarding problem is the Authenticated Received Chain, or ARC, formalized in RFC 8617.

Think of ARC as a chain of custody for email authentication. When a mail server like Gmail forwards a message, it first performs its own validation. It then summarizes those results into an `ARC-Authentication-Results` header. Then, it creates a cryptographic signature (the `ARC-Seal`) over the previous ARC entries and the new results header. This process is repeated at every hop that supports ARC.

When the final recipient mail server gets the message, it sees the broken SPF. But it also sees a chain of ARC headers. It can validate the `ARC-Seal` at each step of the chain, from the last hop all the way back to the first forwarder. If the chain is intact, it can trust the `ARC-Authentication-Results` from the first hop (e.g., Google), which states that the original sender was authentic.

The ARC protocol provides a verifiable 'chain of custody' for a message, allowing each entity that handles the message to see what authentication assessments were performed by upstream handlers. — RFC 8617, Abstract

Both Google and Microsoft are major participants in the ARC standard. When you see `ARC-Seal` and `ARC-Message-Signature` headers in an email, you're looking at the modern, standardized solution to the forwarding problem. It allows a receiving system to make a trust decision based on a cryptographically-verified history of authentication, rather than just the state of the final delivery attempt.

A Triage Playbook for Forwarding Failures

When a user reports a missing email that was likely quarantined for a DMARC failure, don't just release it. You need to verify its path. This is what separates a junior admin from a senior analyst.

Reading the Headers

First, pull the full headers of the quarantined message. Look for multiple `Received:` headers. Do they show a path from the original sender, to a provider like `mail-sor-f41.google.com`, and then to your own gateway? That's your forwarding indicator.

Next, find the `Authentication-Results` header stamped by your own mail server. This will show you the `fail` that caused the quarantine. Now, look for other `Authentication-Results` or, even better, a set of `ARC-Seal` headers from upstream. These headers contain the story. You're looking for proof that a trusted intermediary (like Google or Microsoft) validated the original sender *before* forwarding it to you.

Reviewing Your DMARC Reports

This isn't just about inbound mail. You need to know how forwarding affects your own domain's reputation. Dive into your DMARC aggregate (RUA) reports. Are you seeing high volumes of SPF failures for your domain coming from IPs owned by Google, Microsoft, or other major mailbox providers? That's not a spoofing attack; it's evidence that your legitimate emails are being forwarded and are failing SPF at their final destination.

If those same reports show a corresponding DKIM `pass`, you're in a good state. It means your DKIM signatures are surviving the journey and providing the alignment DMARC needs. If both are failing, you may have downstream services (like mailing lists) that are altering your email content and breaking your signatures. The data points you to the problem.

Conclusion

Email forwarding isn't an attack, it's a feature. The friction comes from authentication protocols that were designed for a simpler A-to-B world. The result is a constant stream of false positives that can swallow legitimate mail.

As a sender, your single most effective defense is a perfectly configured, aligned DKIM signature on all outbound mail. It's the one authentication signal with the best chance of surviving the unpredictable path of a forwarded message. As a receiver, your defense is educating your team. Analysts must look past the simple `dmarc=fail` verdict and learn to reconstruct the message's journey from the headers. Tools that visualize these chains, like the header analysis available in MailSleuth.AI, can turn a half-hour of header-staring into a 30-second decision, but the fundamental skill remains essential.

The takeaway

The DMARC forwarding problem is a microcosm of email security itself: a constant tension between strict validation and the messy, human ways people use technology. You can't stop users from forwarding email, and you can't weaken your security posture.

The only path forward is deeper understanding. Your best strategy is to ensure your own domain's outbound mail is resilient with strong DKIM signing and to equip your security team to read the full story written in the headers of inbound mail. Don't just trust the final verdict; trust the validated chain of evidence.