Why Forwarded Emails Land in Gmail Spam Even When Your SPF, DKIM, and DMARC Are Correct

Your SPF record is correct. Your DKIM signature passes. Your DMARC policy is set to reject. Then a Gmail user reports that your email landed in their spam folder, and nobody can explain why.

The cause is often Gmail auto-forwarding, and it breaks email authentication in a way that most monitoring setups do not catch. Your sending infrastructure looks fine. The problem starts after delivery.

What Happens to Email Authentication When Gmail Forwards Your Message

When Gmail auto-forwards an incoming email, it does not resend it from your mail servers. Gmail receives the message, stores it, and then injects a fresh copy into its own outbound mail system to deliver it to the final destination. This is normal mailbox behavior, but it creates an authentication gap that is structural, not configured.

Here is what changes in the forwarding chain.

SPF does not break, but it stops meaning what you think

SPF validates whether the SMTP connection came from an IP address authorized for the domain in the RFC5321.MailFrom header. When Gmail forwards your message, the MailFrom header is usually preserved (gmail.com does not rewrite it for auto-forwarding), so the final destination server checks SPF against gmail.com's SPF record, not yours. Gmail's servers are authorized in gmail.com's SPF record, so SPF passes at the forwarding leg.

This is the subtle problem. SPF is technically passing, but it is no longer validating your domain. It is validating Gmail. Your sending infrastructure looks clean in SPF checks, but the protection SPF was supposed to provide for your domain has been replaced by Gmail's SPF policy.

DKIM often breaks because forwarded messages get modified

DKIM signs specific headers and optionally the body by computing a cryptographic hash over their contents. When Gmail forwards a message, it may add or modify headers (such as Received headers, X-Gm-Message-State, or Delivered-To), or it may re-encode the message body for the forwarding transport. Either change invalidates the original DKIM signature.

This is not a Gmail defect. It is a consequence of how intermediate mail systems handle forwarded content. If your DKIM signature covers the body and any modified header, it will fail after forwarding.

DMARC alignment fails because neither SPF nor DKIM can align

DMARC alignment is what makes SPF and DKIM meaningful for your specific domain. For a DMARC pass, either the SPF domain (RFC5321.MailFrom) or the DKIM domain (the d= value in the signature) must match the domain in the From address (RFC5322.From).

After forwarding through Gmail:

• SPF uses Gmail's IP, which cannot align with your domain.
• DKIM from the original sender may fail because the message was modified.

DMARC alignment fails because the forwarding server cannot authorize your domain. The MailFrom domain after forwarding is gmail.com, not your domain, so SPF-based alignment is impossible. DKIM alignment may also fail if the original signature was broken by header modifications. The message fails DMARC at the final destination, even though nothing about your sending infrastructure changed.

What This Looks Like in Practice: The Detection Gap

The practical consequence is a specific pattern that security teams often miss.

Users see spam. Nobody sees auth failures.

The receiving server at the final destination may accept the forwarded message but route it to spam, or it may reject it quietly. What does not happen is a DMARC rejection notification back to your systems, because the message was accepted. Your monitoring shows clean auth results. Your users report missing email.

This pattern is particularly easy to miss in organizations where IT does not monitor inbound spam complaints in real time. A single forwarded email to a personal Gmail account may not generate enough user noise to trigger investigation.

No bounce, no alert, just silence.

Unlike a hard DMARC reject where your system receives a delivery failure notification, forwarded-email spam typically produces no alert. The sender's mail logs show a successful delivery to the Gmail inbox. The forwarding step is invisible to the sender.

The person who notices the problem is the recipient, who may not know how to report it or assumes it is their own spam filter acting oddly.

How to Identify Forwarded-Email Spam in Your DMARC Reports

DMARC aggregate reports are the most reliable way to detect this pattern. You cannot see it from sender-side logs alone.

What to look for in aggregate reports

A forwarding-related delivery typically appears with a distinctive combination:

• The forwarding server IP (such as Gmail's mail servers) is the source in your aggregate report
• The RFC5321.MailFrom domain may be gmail.com or a forwarding service domain
• SPF passes (because the forwarding server is authorized for its own domain)
• DKIM may pass or fail depending on whether the signature survived modifications
• The RFC5322.From domain is your domain, which does not align with either

This is the signature of forwarding: your domain as the From address, someone else's domain as the MailFrom, and authentication results that are individually passing but misaligned with your brand domain.

Why the forwarding domain shows up as the source

Your DMARC report shows the last hop before the final destination. When a message is forwarded, that last hop is the forwarding server, not your original sending infrastructure. If you did not know a forwarding path existed, the Gmail IP in your DMARC report may be the first signal that email is being forwarded to a third-party address.

This is exactly the pattern that surfaces forwarding in DMARC reports: your From domain present in a record sourced from a Gmail or forwarding service IP, with SPF passing against gmail.com while your own SPF authorization is bypassed entirely. DMARCFlow is designed to detect exactly this kind of authentication pattern shift. Rather than requiring you to parse raw aggregate reports manually, DMARCFlow surfaces forwarding events as structured alerts, so you can identify when your legitimate email is being forwarded to unintended destinations without waiting for a user to report it as missing.

What Senders Can Do About Email Forwarding Blind Spots

The honest answer is that senders have limited control here, but that does not mean nothing can be done.

Recipient-side controls

Gmail and Google Workspace administrators can add your sending domain to recipient-level allowlists through Google Postmaster Tools or by working directly with recipients to add your domain to their approved sender lists. This is a per-recipient solution, not a universal fix, but it can eliminate forwarding-related spam for high-value contacts.

If your organization is sending to users who have personal Gmail accounts configured to auto-forward work email, the fix ultimately lives with those users. A policy conversation about auto-forwarding to personal accounts is more effective than any technical change on the sending side.

Monitoring authentication anomalies with DMARC reports

The actionable step for senders is to monitor DMARC reports for the forwarding pattern specifically. When you see your From domain appearing in records sourced from unexpected IPs, that is not necessarily an attack. It may be legitimate forwarding that is degrading your recipients' experience without your knowledge.

The actionable step for most senders is to use a DMARC monitoring tool that processes these reports automatically. DMARCFlow parses aggregate reports and flags the forwarding pattern without requiring manual XML inspection. You receive a structured alert when your domain appears in a record sourced from a forwarding server, SPF is passing for the relay domain instead of your domain, and your From domain is present but misaligned.

Why this gap is structural, not fixable by the sender alone

No change to your SPF, DKIM, or DMARC policy prevents forwarding. You own the sending infrastructure. You do not own what happens to a message after Gmail receives it. The forwarding server decides how to resend it, what headers to add or remove, and what authentication results to produce for the next hop.

This is why the receiving side of the forwarding problem matters. If recipients using auto-forwarding understand the consequences, they can choose to stop forwarding or configure their forwarding to preserve authentication headers. That decision is theirs, not yours.

FAQ

Does enabling DKIM on my domain prevent forwarding from breaking authentication?

It reduces the risk but does not eliminate it. DKIM signatures survive forwarding more often than SPF because DKIM validation can still pass if headers are not modified. However, many forwarding systems do modify headers or re-encode the message body, which breaks DKIM. DKIM is more forwarding-resistant than SPF, but not forwarding-proof.

My DMARC policy is set to reject. Why does forwarded email not trigger rejections?

A DMARC rejection requires a DMARC alignment failure at the receiving server. Some forwarders, particularly large mailbox providers, have their own DMARC preprocessing that may override a strict policy. Others simply accept the forwarded message and deliver it to spam without issuing a rejection. DMARC protection degrades at forwarding endpoints.

I see Gmail IPs in my DMARC reports but no SPF or DKIM failures. Is that forwarding?

Possibly. If your From domain is present with a Gmail source IP and both SPF and DKIM are passing, check the alignment. If the MailFrom domain is gmail.com, that is a forwarding signal. The auth results may all pass individually, but the misalignment between your From domain and Gmail's MailFrom domain is what DMARC is designed to catch.

Can I block auto-forwarding to external domains?

In Microsoft 365, you can use mail flow rules to block or quarantine messages that are being forwarded to external domains. Google Workspace does not offer a sender-side control to prevent recipients from auto-forwarding to personal accounts. If blocking external forwarding is a priority, start with Microsoft 365 mail flow rules as the most controllable environment.

In Summary

Gmail auto-forwarding creates an invisible authentication gap. SPF continues to pass, but it validates Gmail's domain instead of yours. DKIM breaks because forwarded messages often get modified, invalidating the original signature. DMARC fails because neither SPF nor DKIM can align with your domain after the forwarding chain.

The practical consequence is legitimate email in spam folders, no alerts sent to the sender, and a pattern in DMARC reports that is easy to misread as a different problem. Monitoring aggregate reports for forwarding signatures, rather than waiting for user complaints, is the proactive approach.

DMARCFlow surfaces this forwarding pattern in your DMARC data automatically, so you can investigate and address it before it becomes a persistent delivery problem.