Why do my forwarded emails land in spam or bounce?

Because forwarding changes the sending IP, and SPF authenticates the IP. When your server forwards a message, the receiving side checks SPF against your forwarder's IP — but that IP isn't in the original sender's SPF record, so SPF fails. Plain forwarding breaks SPF for essentially every message, every time. The message is fine; the authentication path is what broke. The fix is not to change the original sender's SPF (you usually can't), but to make DKIM survive the hop and, where possible, rewrite the envelope sender (SRS) so SPF passes at the next hop.

What is SRS and do I need it?

SRS (Sender Rewriting Scheme) rewrites the envelope sender — the MAIL FROM address SPF actually checks — to your forwarder's own domain, so the next server's SPF check passes against your IP instead of the original sender's. Most mature forwarding services (mailbox providers, cPanel, professional forwarders) do SRS for you automatically; a hand-rolled procmail or sieve forward often does not. SRS fixes the SPF bounce, but it does not fix DMARC alignment on its own, because the visible From: header still shows the original domain. For DMARC to pass on forwarded mail you need surviving, aligned DKIM — SRS alone is not enough.

Does DKIM survive email forwarding?

It survives only if the forwarder doesn't touch the signed content. DKIM signs the body and a set of headers, so the signature stays valid through a clean relay. It breaks the moment a forwarder modifies anything covered by the signature: adding an [EXTERNAL] tag to the subject, appending a disclaimer or footer, rewriting links for security scanning, or transcoding the character set. If your forwarding path does any of those, DKIM breaks too — and with both SPF and DKIM gone, DMARC has nothing left to pass on. Turn off subject tagging and footers on forwarding-only flows.

Email Forwarding Setup: Why It Breaks SPF and How to Check

Problem

You set up forwarding — a @yourdomain.com alias pointing at your Gmail, a departing employee’s mail redirected to their manager, a catch-all pointed at a support inbox — and it worked for exactly as long as nobody looked. Then the forwarded messages started landing in spam, or bouncing outright with something about SPF or DMARC, while the same messages sent directly arrive fine. Nothing about the mail changed. What changed is that forwarding quietly broke the one thing modern mail runs on: authentication.

Here’s the part nobody warns you about when they say “just forward it.” Forwarding is not a neutral pass-through. The moment your server relays a message onward, your server becomes the sender as far as the next hop is concerned — and the sender is exactly what SPF, DKIM, and DMARC are built to scrutinize. Forwarding done naively fails all three checks, and it fails them by design, not by accident.

What forwarding actually does to a message

To see why it breaks, you have to separate two “from” addresses that look the same but aren’t:

The envelope sender (MAIL FROM, also called the return-path) — the address at the SMTP layer that bounces go to. This is what SPF checks.
The header From: — the address the recipient sees in their mail client. This is what DMARC alignment cares about.

When you forward, the receiving server runs SPF against the connecting IP — your forwarder’s IP — using the envelope sender’s domain. If the envelope sender is still the original domain, its SPF record has never heard of your forwarder, and SPF returns fail. That’s the whole problem in one sentence: SPF authenticates the last hop, and forwarding adds a hop the original SPF record doesn’t know about.

The three things that break, in order

1. SPF fails because the IP changed. This is the guaranteed one. The fix is the Sender Rewriting Scheme (SRS): the forwarder rewrites the envelope sender to its own domain before relaying, so the next server’s SPF check runs against your forwarder’s SPF record — which does list your IP — and passes. Mature forwarding (mailbox providers, cPanel, professional forwarding services) applies SRS automatically. A hand-built .forward, procmail, or sieve rule usually does not, which is why “I just added a forward rule” is the classic way to start bouncing mail.

2. DKIM fails if the forwarder edits the message. DKIM is the one authentication method that can cross a forwarding hop intact, because it signs the message content rather than the connection. A clean relay leaves the signature valid. But DKIM breaks the instant anything it signed is altered — an [EXTERNAL] subject prefix, a footer or legal disclaimer bolted onto the body, links rewritten by a security gateway, a charset transcode, even aggressive line re-wrapping. This matters enormously, because surviving DKIM is what lets DMARC pass on forwarded mail even after SPF is gone. If you break DKIM too, you’ve removed the last leg DMARC could stand on. On forwarding-only flows, turn off subject tagging and appended footers.

3. Loops and bounce storms. Forwarding chains cause routing failures that have nothing to do with authentication. Forward A to B while B forwards back to A and you get a loop; servers cap the number of hops and reject it (Exchange Online returns 554 5.4.14 Hop count exceeded). Worse is a catch-all forward: point *@yourdomain.com at an inbox and you forward every piece of spam aimed at addresses that don’t exist, generating bounces from your IP and torching your sending reputation. Forward specific aliases, not a catch-all.

How to set it up and check it

The order matters — check authentication before you trust the forward:

Confirm the forwarder does SRS. If you control the forwarding server, verify SRS (or “sender rewriting” / “envelope from rewriting”) is enabled. If you’re using a provider’s forwarding, it almost certainly is. If you’re forwarding with a raw .forward or sieve redirect, assume it is not.
Check whether DKIM survives. Send a test message through the forward and inspect the delivered copy’s Authentication-Results header. You want to see dkim=pass with a d= domain that matches the visible From: domain. If DKIM is fail or missing, something in the path is modifying the message.
Look for message rewriting. If DKIM breaks, hunt for the culprit: subject tagging, disclaimers, link protection, antivirus/security-gateway rewriting. Disable them on forwarding flows.
Check for ARC. If a trusted forwarder adds ARC (Authenticated Received Chain) headers, receivers that honor ARC (Gmail does) can accept the message on the original authentication result even though SPF broke. ARC is a mitigation, not a guarantee — not every receiver honors it.
Kill loops and catch-alls. Map your forwards and make sure none point back at each other. Replace catch-all forwards with explicit aliases.

Check it with DechoNet

Email / SPF & DMARC Check reads your domain’s SPF, DKIM, and DMARC posture the way a receiving server does — so before you rely on a forward, you can confirm your domain publishes an aligned DKIM key and a DMARC policy, which is what keeps forwarded mail deliverable once SPF is gone.
DNS Lookup shows the raw TXT records, so you can verify the DKIM selector and DMARC record actually exist and resolve, rather than assuming they do.

Resolution Checklist

Confirm the forwarding server applies SRS (envelope-sender rewriting). Raw .forward/procmail/sieve rules usually don’t.
Send a test through the forward and read Authentication-Results — you want dkim=pass aligned to the From: domain.
Disable subject tagging, footers, disclaimers, and link rewriting on forwarding-only flows so DKIM survives.
Replace any catch-all forward with explicit per-address aliases.
Trace the forwarding map for loops (A→B→A) that trigger hop-count rejections.

When to Escalate

If forwarded mail still fails DMARC after SRS is on and DKIM survives, the problem is alignment: SRS makes SPF pass on the forwarder’s domain, which no longer matches the From: domain, so DMARC can only pass via DKIM. Confirm the original sender signs with DKIM at all — some don’t.
If you run the forwarder and can’t get downstream receivers to accept your relayed mail, look at whether they honor ARC and whether your forwarder emits an ARC chain. Without either surviving DKIM or honored ARC, forwarded mail from a spoof-protected (p=reject) domain will keep failing, and that’s the sending domain’s policy working as designed — not something you can fix on the forwarding side.

Check your own domain now

Free, no sign-up. Runs the exact check this guide describes and shows what to fix.