Email forwarding is probably one of the first things you configure when you own a domain. And it's frequently the first thing that quietly stops working.
On the surface it looks trivial: take mail sent to info@yourdomain.com and redirect it to your @gmail.com account. In practice, forwarding is a man-in-the-middle operation that collides directly with the core trust models of the modern internet — SPF, DKIM, and DMARC. Get it wrong and your email doesn't bounce with a dramatic error. It just disappears.
For a founder, a broken forward means missed investor emails. For an MSP managing 50 client domains, it means a support ticket storm on a Monday morning.
This guide covers how email forwarding actually works at the protocol level, why it fails in predictable ways, and how to build a setup that survives contact with strict DMARC policies in 2026.
The Mental Model: Why Email Forwarding Is Messier Than It Looks
Before you can fix a broken forward, you need to understand what's happening at the SMTP layer. It's not passing a note. It's re-mailing a letter — and that distinction matters enormously.
When Server A sends an email to your server (Server B, the forwarder), and Server B relays it to the final destination (Server C), a critical identity shift happens. The destination server sees Server B's IP address, not Server A's. That's the root of almost every forwarding failure.
Envelope vs. Header: The Two Identities of an Email
Every email has two separate layers of identity, and forwarding throws them out of sync:
- The Envelope (P1) — What mail servers use to physically route the message. Contains the
Return-Path. SPF validates this. - The Header (P2) — What your email client displays as the "From" address. DKIM and DMARC alignment checks use this.
Here's what breaks. When your server forwards a message, it opens a fresh SMTP connection to the destination. SPF checks the sending IP against the original sender's SPF record — but your forwarder's IP isn't authorized there. SPF fails. If the original sender runs a strict DMARC policy (p=reject) and you haven't implemented SRS, the destination server rejects the message outright.
A concrete analogy: Alice sends a letter to Bob. Bob puts Alice's letter in a new envelope with his return address and mails it to Carol. Carol checks with Alice to confirm she sent it from Bob's address. Alice says no. That's a DMARC failure — and Carol's mail server acts accordingly.
Understanding this envelope/header split is the foundation. Every fix in this guide flows from it.
Email Forwarding vs. Aliases vs. Catch-All: Know the Difference
Operators confuse these three routing methods constantly. Picking the wrong one is the fastest path to a "missing email" ticket that takes three hours to diagnose.
Email Forwarding
Takes an email sent to one address and delivers it to a completely different server — for example, contact@startup.com → founder@gmail.com. A network hop occurs. Authentication chains break unless you handle them explicitly. Best for consolidating multiple domains into one inbox. Risk: high without proper SRS/ARC handling — see our deep-dive on email alias forwarding combo tradeoffs.
Email Aliases
Another name for an existing mailbox on the same server. support@company.com delivers into the same mailbox as admin@company.com — no network hop, no authentication change. Best for one person wearing multiple hats. Risk: low. For a deeper comparison of when aliases break down and when you need a full mailbox, see our alias vs mailbox decision guide.
Catch-All (Wildcard Routing)
Accepts any email sent to an address at your domain that doesn't exist — *@domain.com. Useful for catching typos or one-time campaign addresses. Risk: critical if pointed directly at Gmail. Every spam message hitting your domain lands in your inbox, and Gmail will eventually treat your forwarding server as a spam source. If you're using catch-all, isolate it. We cover the full tradeoffs in our guide to business email setup.
| Method | Network Hop? | Auth Risk | Best For |
|---|---|---|---|
| Forwarding | Yes | High (SPF/DMARC breaks) | Routing across domains/providers |
| Alias | No | None | Multiple roles, same mailbox |
| Catch-All | Depends on config | Critical (spam magnet) | Typo catching, burn addresses |
Setup Patterns: The Good, the Bad, and the Broken
There are three ways to configure email forwarding. Two of them will cause you problems. One works reliably in production.
1. Provider-Side Routing (The Right Way)
This happens at the MTA level before the message ever touches a mailbox. The server receives the email, rewrites the envelope using SRS, and relays it immediately. No paid mailbox license required. No storage consumed. SPF and ARC are handled at the infrastructure layer.
This is the approach worth building on. TrekMail's forwarding routes work this way — you define the destination, and the infrastructure handles the authentication headers. See the mailbox forwarding setup guide for the exact steps.
2. Mailbox Rules (The Old Way)
You provision a full user account — paying $6–$30/month for a license you don't actually need — log in, and create an inbox rule: "If message arrives, forward to X."
There are edge cases where this makes sense: conditional forwarding ("only forward invoices"), auditing requirements, or situations where you need the message stored locally before it's relayed. But in most setups, you're paying for a seat just to route mail. It also breaks DMARC in the same way as any other forward, and Microsoft 365 blocks automatic forwarding by default (more on that in the failure modes section).
3. Client-Side Forwarding (Avoid Entirely)
This is a rule set in Outlook Desktop or Apple Mail on your local machine. Your laptop must be on, awake, and connected to the internet for the forward to happen. It doesn't work while you're traveling. It doesn't work during a restart. It doesn't work at 2am when the important email arrives.
There's no production scenario where this is the right choice. If you're currently relying on it, fix that now.
The Safe Setup Checklist
Before you call a forwarding route live, run these four checks. Skipping any one of them will come back to bite you.
1. The Loop Test
Confirm the destination address doesn't forward back to the source. A→B→A is an infinite loop. Modern servers catch this with hop count limits and return a 5.4.14 hop count exceeded NDR — but by then you've already burned sending reputation. Map your routes before you go live.
2. The Header Inspection Test
Send a test from an external account (personal Gmail, Yahoo, anything outside your domain) to the forwarded address. At the destination, open the full message headers and find the Authentication-Results header. You want to see spf=pass (from SRS rewriting) or dkim=pass. If you see dmarc=fail, your forwarding setup is not production-ready.
3. The Reply-To Test
Reply to a forwarded message. Does the reply go to the original sender or to your forwarder's address? It must go to the original sender. If it's going to the forwarder, your envelope configuration is wrong and you're going to create a confusing paper trail for everyone involved.
4. The Outbound Policy Check
If you're using Microsoft 365 or Google Workspace as the relay destination, check that automatic forwarding is permitted in the outbound spam filter settings. M365 blocks it by default. If this isn't configured correctly, your forwards will be silently dropped with no notification to the original sender.
Common Failure Modes
When email forwarding breaks, it almost always fails in one of these specific ways. Knowing the pattern saves you an hour of aimless header-reading.
1. The DMARC Silent Drop
This is the most common cause of vanishing email in 2026, and it's invisible — no NDR, no error, nothing. The message just doesn't arrive.
The scenario: a bank, payment processor, or SaaS vendor sends email with a strict p=reject DMARC policy to your domain. You forward it to Gmail. Your forwarder's IP breaks SPF. If your server also modifies the message body (appending a disclaimer) or subject line (adding [External]), it breaks DKIM too. SPF fail + DKIM fail = DMARC fail. Gmail rejects it.
The fix is implementing SRS on the forwarding server so SPF passes, and ensuring no content modification occurs so DKIM stays intact. If you can't control the infrastructure, you need a forwarding provider that handles this for you. For a deeper look at how DMARC failures play out specifically in forwarding chains, see our breakdown of DMARC and secure email.
2. The Microsoft 550 5.7.520 Block
Symptom: the original sender gets an NDR with the code 550 5.7.520 Access denied, your organization does not allow external forwarding.
This is M365's outbound spam filter doing exactly what it's designed to do — block automatic forwarding to external addresses. The fix requires navigating to the Microsoft Defender portal → Email & Collaboration → Policies & Rules → Threat policies → Anti-spam policies → Edit the outbound policy → Set "Automatic forwarding rules" to "On — forwarding is enabled."
It's not intuitive, and Microsoft buries it. But that error code is a precise diagnostic — when you see it, you know exactly where to go.
3. The Out-of-Office Loop
User A forwards to User B. User B sets up an automatic reply. User A emails User B. User B's auto-reply fires back to User A. User A's server forwards that reply to User B. User B's server fires again.
Modern mail servers use headers like X-Loop and X-Auto-Response-Suppress to detect and stop this. Older or misconfigured setups can still spiral into thousands of messages within minutes. Check your auto-reply configurations when setting up cross-account forwarding.
4. The DKIM Modification Break
DKIM signs a cryptographic hash of the message content. The moment anything in the signed portion changes — even adding a one-line footer — the signature breaks. Many corporate mail systems append legal disclaimers to every outbound message. If that disclaimer is being added after the DKIM signature was created, the signature is invalid at the destination.
If you see dkim=fail (body hash did not verify) in the headers of a forwarded message, this is almost always the cause.
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 on a blocklist. Verify SPF authentication in headers. |
Sender gets NDR 5.4.14 |
Routing loop | Audit all forwarding rules for circular paths (A → B → A). |
| No email, no NDR (silent drop) | DMARC reject / spam filter | Check destination spam/junk folder. Inspect headers for dmarc=fail. |
550 5.7.520 Access denied |
M365 outbound policy block | Edit M365 Defender outbound spam policy — enable automatic forwarding. |
| Email arrives but looks broken | DKIM body hash failure | Check headers for dkim=fail (body hash did not verify). Disable footer/disclaimer injection. |
| Reply goes to forwarder, not original sender | Reply-To / envelope misconfiguration | Verify forwarding setup preserves the original sender's Reply-To header. |
Why Production Forwarding Breaks (SRS and ARC Explained)
Simple forwarding rules are not enough for a production environment. You need infrastructure that understands SRS and ARC. Here's exactly what each one does and why both matter.
SRS: Sender Rewriting Scheme
SRS fixes the SPF failure caused by the network hop. Your forwarding server rewrites the envelope sender address so the destination can validate SPF against your domain instead of the original sender's.
Before SRS:
MAIL FROM: alice@bank.comAfter SRS rewriting:
MAIL FROM: SRS0=hash=timestamp=bank.com=alice@forwarder.comThe destination server runs SPF against forwarder.com, which passes because your server is authorized. Bounce messages still route back to alice@bank.com via the encoded address. SPF is satisfied without breaking the bounce path.
SRS is essential. Without it, every forwarded message from a sender with strict SPF will fail authentication at the destination. For a complete breakdown of how SRS works in forwarding chains, see our detailed guide on setting up email with your domain. If you are specifically routing to a Gmail inbox, see our step-by-step guide on how to forward domain email to Gmail safely with SRS and Send Mail As configured.
ARC: Authenticated Received Chain
SRS fixes SPF, but it doesn't fully resolve DMARC alignment. This is where ARC comes in. ARC lets your forwarding server cryptographically sign the message with a stamp that says: "I verified this message's authentication when I received it, and it was valid."
Google and Microsoft both honor ARC seals from trusted intermediate servers. When an ARC seal is present and trusted, those providers will accept the message even if the original SPF/DMARC checks would have failed due to the forwarding hop. It's essentially a chain of custody record for email authentication.
ARC is defined in RFC 8617 and is the current standard for preserving authentication across legitimate email forwarding scenarios. Without ARC, a strict p=reject DMARC policy at the original sender will kill your forwarded messages at major providers, even if SRS is in place.
The Catch-All Danger Zone
Forwarding is often paired with a catch-all configuration, and that combination deserves a specific warning. If you point a catch-all wildcard at Gmail, every spam message targeting random addresses at your domain lands in Gmail's lap — and Gmail sees your forwarding server as the source. You'll accumulate spam complaints against your IP quickly, which tanks your domain's sending reputation for legitimate email too.
If you need catch-all, isolate it to a dedicated mailbox with spam filtering at the server level, not a forward to a personal inbox. The full setup pattern is covered in our guide to setting up email on your domain.
Where TrekMail Fits In
The old way of handling email forwarding meant either building your own MTA with SRS and ARC support, or paying per-user licensing fees just to route mail. Neither option made sense for operators managing more than a handful of domains.
Pay Google or Microsoft $6/user/month, need 10 forwarding addresses, potentially pay for 10 seats you don't use — or hit alias limits and start juggling workarounds. It's a tax on routing.
TrekMail's approach is flat-rate hosting. You pay for a plan, not seats. Forwarding routes, aliases, and catch-all configuration are included — managed at the server level with SRS-compliant forwarding built into the infrastructure. You set the route; the platform handles the authentication headers, TLS enforcement, and delivery. No per-address fees, no wrestling with outbound spam policies to access basic functionality.
For a solo founder, that means hello@yourdomain.com routing reliably to your Gmail in under five minutes, without setting up a full mail server. For a team, it means every routing change happens in the dashboard — no DNS archaeology required. For an agency managing 100+ client domains, it means forwarding rules are managed centrally, applied consistently, and don't create authentication failures that turn into support escalations at 6pm on a Friday.
The Pro plan ($10/month, or $8/month on yearly) includes external catch-all and mailbox forwarding. The Agency plan ($29/month) scales to 1,000+ domains with API access for bulk route management. All paid plans come with a 14-day free trial (card required).
See how TrekMail handles forwarding at every scale at trekmail.net.
Conclusion
Email forwarding isn't a fire-and-forget feature. It's an active routing operation that touches the core authentication models of the internet. The failures are predictable — SPF breaks on the IP change, DKIM breaks on content modification, DMARC rejects on alignment failure — and they're all fixable once you understand what's happening at the protocol layer.
The practical takeaways: use server-side forwarding with SRS and ARC, never client-side rules. Test your headers before going live. Watch for M365's outbound policy block. Keep catch-all isolated. And if you're managing email forwarding across multiple domains, don't pay per-seat just to route mail.
Get the underlying infrastructure right and email forwarding works reliably. Get it wrong and your most important messages disappear without a trace. The choice isn't complicated.
