Why Your Forwarded Emails Go to Spam

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. That check can pass, because the forwarder's own domain authorizes the forwarder's servers.

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 carries the authentication results that hop saw. The final recipient can check the ARC chain to see how the email looked before it was forwarded, and decide for itself how much weight to give each sealer.

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

3. Dedicated Forwarding Relay (ARC-Relay)

ARC-Relay combines both: SRS rewriting so SPF is checked against ARC-Relay's own domain, and an ARC seal recording the SPF, DKIM and DMARC results checked when the message arrived. The destination still makes its own decision; ARC-Relay never sees it.

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.

Setting Up Reliable Email Forwarding

• Check your current authentication: Use our Email Health Score tool
• Set up DMARC with at least p=quarantine
• Enable DKIM signing through your email provider
• Forward through an ARC-capable relay like ARC-Relay
• Verify with our Header Analyzer that ARC seals are present