Forward Domain Email to Gmail: The Safe Setup

You set up contact@yourdomain.com to forward domain email to Gmail. A client sends a contract. A bank sends a security alert. Neither message shows up.

You check spam. Nothing. The messages are gone — no trace, no error, no notification to you or the original sender.

That's not Gmail being difficult. It's a protocol failure. When you forward domain email to Gmail, your server retransmits a message signed by someone else's domain from your IP address. Gmail checks SPF against the original sender's domain — your IP isn't on their list. SPF fails. If the sender uses a strict DMARC policy (p=reject), Gmail returns a hard bounce with error 550-5.7.26 and discards the message permanently. No notification to you. No notification to the original sender.

To forward domain email to Gmail without silent losses, your forwarding server must rewrite the envelope sender using SRS (Sender Rewriting Scheme) and add ARC (Authenticated Received Chain) headers on every message. Without both, you're one strict DMARC policy away from losing critical mail.

This guide covers the exact setup: SRS envelope rewriting, loop prevention, and Gmail's Send Mail As configuration. For the protocol internals — how SPF, DKIM, and DMARC interact during forwarding, and how SRS works at the byte level — see our complete email forwarding setup and fix guide.

Why Gmail Rejects Forwarded Email

Gmail rejects forwarded email because the sending IP — your forwarding server — isn't listed in the original sender's SPF record. To forward domain email to Gmail without triggering SPF rejection, your server must rewrite the envelope sender so Gmail checks SPF against your domain, not the original sender's. Without this rewrite, strict DMARC policies produce hard bounces and the message is gone.

Here's the exact failure chain when client@bank.com is forwarded to you@gmail.com:

1. bank.com delivers to your forwarding server
2. Your server relays the message to Gmail
3. Gmail checks SPF on the envelope sender: client@bank.com
4. bank.com's SPF record doesn't list your server's IP → SPF FAIL
5. DMARC policy is p=reject → Gmail returns 550-5.7.26
6. Message deleted. No notification to you or bank.com.

DKIM can survive forwarding intact — provided your server doesn't touch the message body or subject. No antivirus footers. No subject rewrites. When DKIM is intact, Gmail can pass DMARC via DKIM alignment even when SPF fails. But if the sender uses aspf=s (strict SPF alignment) or your server modifies the body at all, DKIM alignment breaks too. To forward domain email to Gmail reliably, you can't rely on DKIM alignment alone — the only guaranteed fix is SRS.

Three Ways to Forward Domain Email to Gmail

Not all forwarding setups carry the same risk. Before you forward domain email to Gmail, choose the right architecture for your use case.

The catch-all is the one that kills deliverability. Spammers probe random addresses — abc123@yourdomain.com, junk@yourdomain.com. Your server accepts everything and forwards it to Gmail. Gmail sees your server delivering 90% spam and blacklists your sending IP. Your legitimate email starts landing in spam, and your domain reputation takes weeks to recover.

For a deeper breakdown of when aliases make sense versus full mailboxes, see our guide on email alias forwarding tradeoffs. If you're deciding between an alias or a dedicated mailbox for a new address, domain email alias vs mailbox walks through the decision criteria.

SRS: Why It's Mandatory When You Forward Domain Email to Gmail

SRS (Sender Rewriting Scheme) is mandatory when you forward domain email to Gmail because it fixes SPF failure at the envelope level. SRS rewrites the hidden Return-Path address — used for routing and bounces — from the original sender's domain to your domain. Gmail then checks SPF against your domain, your server's IP passes, and the message is delivered.

Without SRS (broken):
Envelope From: client@bank.com
Sending IP: 203.0.113.10 (your forwarding server)
SPF check: bank.com SPF record → FAIL (203.0.113.10 not listed)
DMARC: FAIL (p=reject) → Hard bounce, message destroyed

With SRS (fixed):
Envelope From: SRS0=HASH=TT=bank.com=client@yourdomain.com
Sending IP: 203.0.113.10 (your forwarding server)
SPF check: yourdomain.com SPF record → PASS (203.0.113.10 is listed)
Header From: client@bank.com (unchanged — you see the original sender)

Your SPF record must include your forwarding server's IP or sending hostname. Without that entry, SRS still fails — the rewritten address points to your domain, but your domain's SPF doesn't authorize the sending IP.

Beyond SRS, well-configured forwarding infrastructure also adds ARC (Authenticated Received Chain) headers. ARC is a chain of cryptographic signatures documenting the authentication results at each hop. Google uses ARC to trust messages from known-good forwarders even when SPF fails — but only if the forwarding server signs with its own DKIM key. You don't configure this manually. Your email provider either supports it or it doesn't.

The SPF specification is defined in RFC 7208. The ARC protocol — which documents the authentication chain across multiple hops — is defined in RFC 8617.

Loop Prevention: Four Checks Before You Go Live

Forwarding loops generate 5.4.14 Hop count exceeded errors and bounce real messages. Before you forward domain email to Gmail in production, run through these four checks.

1. No circular routing. Ensure you@gmail.com doesn't have a filter forwarding mail back to you@yourdomain.com. That creates an infinite bounce loop between Gmail and your server.
2. Out-of-office hygiene. If you use a role address (team@domain.com → multiple Gmail accounts), disable auto-replies or ensure your server respects Precedence: bulk headers to suppress loop-generating out-of-office responses.
3. Test from a third account. Gmail de-duplicates messages. If you send a test from the destination Gmail account to your alias, it shows up in Sent but not Inbox. Always test from a Yahoo or Outlook account to get an accurate result.
4. M365 outbound policy. If your relay is Microsoft 365, you must explicitly enable "Automatic Forwarding" in the Defender Outbound Spam Policy. Without that setting, every forwarded message hits 550 5.7.520 and is rejected.

These are the most common failure modes when you forward domain email to Gmail for the first time. None of them are obvious from the error messages alone.

How to Forward Domain Email to Gmail Using TrekMail

TrekMail applies SRS rewriting and ARC signing at the MTA level on every forwarded message. When you forward domain email to Gmail through TrekMail, you configure the destination address once — the server handles the authentication handshake on every delivery automatically.

Mailbox forwarding is available on Pro and Agency plans. Free and Starter plan users need to upgrade to access the forwarding feature. Setup steps are in the TrekMail mailbox forwarding docs:

1. Go to Mailboxes in your dashboard
2. Click Manage on the mailbox you want to configure
3. Toggle Enable forwarding to ON
4. Enter your Gmail address in the Forward to field
5. Enable the Keep a copy toggle — leave this on during initial setup
6. Click Save Forwarding Settings

The "Keep a copy" option matters more than it looks. With it enabled, TrekMail stores a copy in the mailbox AND delivers to Gmail. With it off, messages go to Gmail only — if Gmail rejects them, they're gone. Keep it on until you've verified that headers are clean.

Agencies managing many domains can forward domain email to Gmail in bulk: select multiple mailboxes via checkboxes and apply the same forwarding destination from the bulk actions menu. One click across a hundred domains.

Closing the Loop: Send Mail As in Gmail

Forwarding solves incoming mail. But after you forward domain email to Gmail without configuring Send Mail As, replies go from your personal @gmail.com address — not your domain. Your client sees a personal Gmail instead of ceo@yourdomain.com.

Fix this with Gmail's "Send mail as" feature using external SMTP credentials. Don't use Gmail's default "Treat as an alias" checkbox without external SMTP — it routes outbound through Google's servers, which causes "via gmail.com" warnings or DMARC failures for your domain.

In Gmail: Settings → Accounts and Import → Send mail as → Add another email address. Uncheck "Treat as an alias."

TrekMail SMTP settings (Starter, Pro, Agency plans):

SMTP Server:  smtp.trekmail.net
Port:         587
Security:     TLS (STARTTLS)
Username:     your-mailbox@yourdomain.com
Password:     Your mailbox password

Nano plan — BYO SMTP (SES, SendGrid, Mailgun, etc.):

SMTP Server:  email-smtp.us-east-1.amazonaws.com  (Amazon SES example)
Port:         587
Security:     TLS
Username:     Your SMTP credentials from your provider

After adding the address, Gmail sends a verification code to your mailbox. Enter it to confirm, then set the domain address as your default sender so replies to forwarded messages go from your professional address automatically.

Verify It Worked: Reading Gmail Authentication Headers

After you forward domain email to Gmail and receive a test message from an external account, inspect the raw headers before trusting the setup in production.

In Gmail: open the message → three-dot menu → Show original. Search for Authentication-Results.

A clean passing result looks like this:

Authentication-Results: mx.google.com;
  spf=pass (google.com: domain of SRS0=hash=tt=bank.com=client@yourdomain.com
    designates 203.0.113.10 as permitted sender)
    smtp.mailfrom=SRS0=hash=tt=bank.com=client@yourdomain.com;
  dkim=pass header.i=@yourdomain.com;
  arc=pass (i=1 spf=pass dkim=pass)

If you see spf=softfail or spf=fail, your SRS rewriting is broken or your SPF record doesn't include the forwarding server's IP. If you see arc=fail, a relay modified the message after it was signed — usually a security gateway adding a footer. Google's official guidance on forwarding email to Gmail confirms the envelope sender must reference the forwarding domain. That's exactly what SRS provides.

DIY vs Managed: The Real Trade-Off

To forward domain email to Gmail from a self-managed Postfix server, you need to install and configure postsrsd, manage the srs_secret file, rotate it on schedule, set up OpenARC with a DKIM signing key, and monitor your IP reputation with Google Postmaster Tools. It works — until a kernel update breaks a dependency, or the SRS secret rotates incorrectly, or a new sender's DMARC policy starts rejecting your forwarded messages. Then you're debugging authentication headers at 11pm.

When you forward domain email to Gmail through TrekMail, SRS and ARC are handled at the MTA level on every message — no configuration required after the initial destination setup.

Getting Started

If you need to forward domain email to Gmail for a single domain, start on the Nano plan — no card, connect your domain immediately and test the setup. When you need managed SRS forwarding and the forwarding feature itself, the Pro plan starts at $10/mo flat with no per-user fees regardless of how many addresses you configure.

Paid plans come with a 14-day free trial — credit card required to start. Or go straight to trekmail.net/pricing and start on the Nano plan now with no card at all.

To forward domain email to Gmail correctly, four things must be in place: SRS rewrites the envelope, ARC documents the authentication chain, your SPF record authorizes the forwarding server's IP, and Send Mail As closes the outbound loop. Get those four right, and forwarding is invisible for years. Get any one wrong, and messages vanish silently at the protocol layer with no notification on either end.

Set it up once. Verify the headers. Move on.