Blog / Why Your Forwarded Emails Go to Spam

Why Your Forwarded Emails Go to Spam

March 8, 2026 • 8 min read

The Problem: Email Authentication Breaks on Forward

When you forward an email, two things happen that break authentication:

The forwarding server's IP isn't in the original sender's SPF record, so SPF fails.
Some forwarding servers modify headers or add footers, breaking DKIM signatures.

Without either SPF or DKIM passing, DMARC fails. And with DMARC enforcement (p=quarantine or p=reject), the forwarded email lands in spam or gets rejected entirely.

How Email Authentication Works (Briefly)

SPF checks whether the sending server's IP is authorized by the domain's DNS. Works great for direct sends, breaks on forward.
DKIM adds a cryptographic signature to the email. Survives forwarding unless headers or body are modified.
DMARC ties SPF and DKIM together. Requires at least one to pass AND align with the From domain.

You can check any domain's current authentication setup with our free DMARC Checker and SPF Validator.

Why SPF Fails on Forward

Here's a step-by-step example. When [email protected] sends to [email protected], and Bob forwards to [email protected]:

Gmail checks SPF for example.com
But the email came from hiscompany.com's server, not example.com's
SPF fails because hiscompany.com isn't in example.com's SPF record

This is the fundamental problem. SPF was designed for direct sender-to-recipient delivery, not for forwarding chains. You can verify SPF records with our SPF Validator.

Why DKIM Sometimes Breaks Too

Some forwarding servers:

Add "Forwarded by" footers, breaking the body hash
Modify the Subject line (adding [FWD])
Rewrite headers for mailing list management

Any modification invalidates the DKIM signature. When both SPF and DKIM fail, DMARC has nothing to work with and the email fails authentication entirely.

Three Solutions That Actually Work

1. SRS (Sender Rewriting Scheme)

SRS rewrites the envelope sender (Return-Path) to the forwarding domain. Now SPF checks the forwarder's domain instead of the original sender's. The forwarded email passes SPF because the forwarder is authorized to send from its own domain.

Problem: SRS doesn't preserve the original authentication results. The receiving server can't see that the email originally passed SPF and DKIM at the first hop.

2. ARC (Authenticated Received Chain)

ARC adds cryptographic seals at each forwarding hop. Each seal records the authentication results at that point. The final recipient can check the ARC chain to see that the email was legitimate before forwarding. Gmail, Microsoft, and Yahoo trust ARC from reputable sealers.

You can verify ARC seals on any email with our ARC Validator.

3. Dedicated Forwarding Relay (ARC-Relay)

ARC-Relay combines both: SRS for SPF compliance and ARC sealing for authentication chain preservation. Every email forwarded through ARC-Relay passes SPF, DKIM, and DMARC at the destination.

How ARC Sealing Works

Three headers are added at each hop:

ARC-Authentication-Results (i=1): Records SPF, DKIM, DMARC results at this hop
ARC-Message-Signature (i=1): Signs the message content
ARC-Seal (i=1): Cryptographically seals the entire chain

Each subsequent hop validates the previous chain (cv=pass) and adds its own set with the next instance number. The final recipient walks the chain backwards, verifying each seal to confirm the email was legitimate at every step.

Use our Header Analyzer to inspect ARC chains in your email headers.