If you're running a domain, email forwarding is probably one of the first things you set up. And it's often the first thing to break.
On the surface, it looks simple:
take an email sent to info@yourdomain.com and send it over to you@gmail.com.
But the reality is messy. Forwarding is a complex "man-in-the-middle"
operation that messes with the core trust models of the internet: SPF, DKIM,
and DMARC.
For a Founder, a broken forward
means missed investor updates. For an MSP managing 50 domains, it means a
support ticket storm.
The old way meant fragile
client-side rules in Outlook or paying for expensive per-user licenses just to
redirect mail. The new way—the standard for 2026—is server-side routing that
preserves authentication chains and cuts out per-seat costs.
This guide breaks down how
forwarding actually works, why it fails, and how to build a setup that reliably
delivers.
The
Mental Model: That "New Hop" Problem
To fix forwarding, you need to
understand what's happening to the data packets. It's not just passing a note;
it's re-mailing a letter.
When Server A sends an email to your
server (Server B, the forwarder), and Server B then sends it to the final
destination (Server C), a critical identity shift happens.
Envelope
vs. Header: The Two Identities
Email has two layers of identity,
and forwarding throws them out of sync:
- The Envelope (P1):
This is what servers use to route mail. It includes the Return-Path. SPF
checks this.
- The Header (P2):
This is the "From" address your email client shows you. DKIM and
DMARC alignment checks this.
Here's Why It Breaks:
When your server forwards an email, it opens a new SMTP connection to the final
destination. The destination server sees your server's IP address as the
sender, not the original sender's.
- SPF Failure:
The original sender's SPF record authorizes their IP, not yours.
Since the IP has changed, SPF fails.
- DMARC Failure:
If the original sender has a strict DMARC policy (p=reject), and you
haven't implemented SRS (Sender Rewriting Scheme), the email gets blocked.
Think of it like this:
Imagine Alice (Server A) sends a letter to Bob (Server B). Bob puts Alice's
letter inside a new envelope with his return address and sends it to
Carol (Server C). Carol opens Bob's envelope, sees Bob's return address, but
reads Alice's name on the letter inside. If Carol calls Alice to confirm she
sent it from Bob's house, Alice will say "No." That's a DMARC
failure.
Forwarding
vs. Aliases vs. Catch-All: Know the Difference
Operators often confuse these three
routing methods. Picking the wrong one is the fastest way to get "missing
email" tickets.
Email
Forwarding
What it is: Taking an email sent to one address and sending it to a
completely different server (e.g., contact@startup.com -> founder@gmail.com).
- Best for:
Consolidating multiple domains into one inbox.
- Risk:
High. Breaks SPF/DMARC unless you use SRS/ARC.
Email
Aliases
What it is: Another name for an existing mailbox on the same
server (e.g., support@ delivers to the admin@ mailbox).
- Best for:
One person handling multiple roles (CEO, Sales, Support) in the same
company.
- Risk:
Low. No network hop occurs; authentication stays intact.
Catch-All
(Wildcard)
What it is: A policy that accepts email sent to any address at
your domain that doesn't exist (*@domain.com).
- Best for:
Catching typos or "burn" addresses.
- Risk:
Critical. It's a spam magnet that can destroy your domain reputation if not
isolated.
Setup
Patterns: The Good, The Bad, and The Broken
There are three ways to set up email
forwarding. Only one is recommended for anything resembling production.
1.
Provider-Side Routing (Recommended)
This happens at the server level
(MTA) before the email even hits a mailbox.
- How it works:
The server gets the message, rewrites the envelope using SRS, and relays
it immediately.
- Pros:
Doesn't need a paid mailbox license; handles SPF/ARC correctly; no extra
storage costs.
- TrekMail Context:
This is how TrekMail handles forwarding. You set the route, and our
infrastructure manages the delivery headers.
2.
Mailbox Rules (The Old Way)
This means setting up a full user
account (paying 6–30/month), logging in, and creating a rule: "If message
arrives, forward to X."
- Pros:
You get granular control ("only forward if subject contains
'Invoice'").
- Cons:
Expensive (you pay for a license you don't need); often breaks DMARC;
frequently blocked by default by Microsoft 365's "Outbound Spam"
policies.
3.
Client-Side Forwarding (Avoid Like the Plague)
This is setting a rule in Outlook
Desktop or Apple Mail.
- Pros:
None. Seriously.
- Cons:
Your computer must be on and connected to the internet for the
forward to happen. If your laptop goes to sleep, your email stops.
The
"Safe Setup" Checklist
Before you declare a forwarding
route "live," run this quick, four-point check.
- The Loop Test:
Make absolutely sure the destination address doesn't auto-forward back to
the source. This creates an infinite loop, burns your reputation, and
triggers provider blocks (like 5.4.14 hop count exceeded).
- The Header Check:
Send a test email from an external account (like a personal Gmail or
Yahoo) to the forwarded address. Then, inspect the headers at the
destination.
- Look for the Authentication-Results header.
- Verify that spf=pass (thanks to SRS) or dkim=pass.
- The "Reply-To" Test: When you reply to the forwarded email, does it go to
the original sender or the forwarder? It must go to the original
sender.
- Outbound Policy Check: If you're using M365 or Google Workspace as the relay,
confirm that "Automatic Forwarding" is enabled in the outbound
spam filter policies. If it's not, your forwards will likely get blocked.
When email forwarding breaks, it usually fails in one of
these specific ways.
1. The DMARC "Double Whammy"
This is the most common reason emails silently disappear in
2026.
- Scenario:
A bank sends an email with a strict DMARC policy (p=reject) to your
domain. You forward it to Gmail.
- The
Break: Your forwarding server changes the IP address,
breaking SPF. If your server also modifies the subject line (e.g., adding [External])
or body (adding a disclaimer), it breaks DKIM.
- Result:
SPF fails + DKIM fails = DMARC Fail. Gmail rejects the message.
2. The Microsoft 5.7.520 Block
Microsoft 365 has aggressive default security policies that
often block forwarding.
- Symptom:
You get an NDR (Non-Delivery Report) with the code 550 5.7.520 Access
denied, your organization does not allow external forwarding.
- Fix:
You need to go into the Microsoft Defender portal and edit the Outbound
Spam Filter Policy to explicitly allow automatic forwarding for that
user or domain.
3. The OOF Storm (Out-of-Office Loop)
- Scenario:
User A forwards emails to User B. User B has "Automatic Reply"
turned on.
- The
Break: User A emails User B. User B's server auto-replies to
User A. User A's server forwards that auto-reply back to User B. User B's
server auto-replies again.
- Result:
Thousands of emails flood the system in minutes. Modern servers use
headers like X-Loop or X-Auto-Response-Suppress to stop this, but older
setups can still melt down.
Debug
Workflow: Symptom → Fix
|
Symptom |
Likely Cause |
Diagnostic Step |
|
Sender gets NDR "5.7.1" |
SPF/Relay Denied |
Check if your forwarder's IP is blacklisted or if
authentication failed. |
|
Sender gets NDR "5.4.14" |
Routing Loop |
Look for circular forwarding rules (A forwards to B, B
forwards back to A). |
|
No email, no NDR (Silent Drop) |
DMARC/Spam Filter |
Check the destination's Spam/Junk folder. Inspect headers
for dkim=fail. |
|
"Access Denied" (M365) |
Outbound Policy Block |
Check M365 Defender Outbound Spam settings for automatic
forwarding restrictions. |
|
Email arrives, but looks weird/broken |
DKIM Modification |
Check headers for dkim=fail. Forwarding often modifies
content, invalidating the signature. |
|
Reply goes to forwarder, not original |
Incorrect Reply-To/Envelope Configuration |
Verify your forwarding setup correctly preserves the
original sender's Reply-To header. |
Why
Forwarding Breaks in Production
In a real-world setup, simple
forwarding rules are rarely enough. You need infrastructure that understands SRS
and ARC.
SRS
(Sender Rewriting Scheme)
This is essential for fixing the SPF
failure caused by the "New Hop." Your forwarder rewrites the envelope
sender address.
- Original:
MAIL FROM: alice@bank.com
- Rewritten:
MAIL FROM: SRS0=hash=timestamp=bank.com=alice@forwarder.com
This allows the destination server to validate SPF against your forwarder's domain (which passes) and still know how to bounce errors back to Alice.
ARC
(Authenticated Received Chain)
SRS fixes SPF, but it doesn't fix
DMARC alignment. ARC lets your forwarder cryptographically "sign" the
message, essentially saying: "I verified this message was valid when I
received it."
Major providers like Google and Microsoft trust ARC seals to override DMARC
failures, preserving deliverability.
The
Catch-All Danger Zone
Forwarding is often paired with a
Catch-All setup. This is a recipe for disaster. If you forward all spam hitting
*@yourdomain.com to Gmail, Gmail will see you as the spammer and block
your IP.
Where
TrekMail Fits In
Manually managing email forwarding
means wrestling with DNS records, reputation scores, and cryptic error codes.
It's a headache.
Whether you're a startup founder
with one domain or an agency managing hundreds, paying per-user fees just to
route email is a pointless tax.
- The Old Way:
Pay Google/Microsoft $6/user/mo. Need 10 forwarding addresses? You might
pay for 10 seats or hit alias limits.
- The TrekMail Way:
Flat-rate hosting. Get unlimited aliases and forwarding routes. Our
infrastructure handles the complex stuff like SRS, ARC, and TLS
enforcement automatically.
We built TrekMail for Operators who
need control. You define the route; we ensure the email gets there with its
reputation intact.
TrekMail: https://trekmail.net/
Conclusion
Email forwarding isn't a "set
it and forget it" feature. It's an active routing protocol that demands
modern standards. By understanding the difference between the envelope and the
header, and by using tools like SRS and ARC, you can stop your critical emails
from vanishing into the ether.
Stop relying on fragile client-side
rules. Build a routing setup that actually works.
Comments
Post a Comment