Email protocols series. This is the tactical email forwarding guide. For the conceptual overview of how SMTP, IMAP and POP3 fit together, read the email protocols hub →
Quick email forwarding reference
Email forwarding takes mail arriving at one address and delivers it to another. Simple in concept, but DMARC and SPF make it surprisingly easy to break. A forward that quietly drops messages is one of the first things to test when incoming mail stops arriving. The right setup uses server-side forwarding with either ARC support (modern receivers honor it) or SRS (Sender Rewriting Scheme) to keep authentication aligned at the final destination.
| Server-side forwarding | Alias or rule on the receiving server forwards before the user sees it. Modern default. |
| Client-side forwarding | Filter in Gmail, Outlook etc. forwards messages after they arrive. Works but less reliable. |
| The DMARC trap | Forwarding changes the envelope, breaking SPF alignment. Without ARC or SRS, the final receiver rejects. |
| ARC solution | Forwarder signs an attestation; trusted receivers honor it (Gmail, Microsoft, Yahoo all do) |
| SRS solution | Forwarder rewrites the envelope sender to itself, so SPF aligns at the next hop |
This guide covers the actual setup at major providers, the authentication pitfalls that cause forwarded mail to land in spam (or never arrive at all), and the security risks (forwarding loops, business email compromise, accidental data exfiltration) that any forwarding setup should account for. For context on how forwarding fits with the broader email protocol stack, see our email protocols overview.
What is email forwarding?
Email forwarding redirects mail from one address to another. Mail arrives at contact@example.com and is automatically delivered to alice@gmail.com. The original recipient address becomes a passthrough; the actual reader is somewhere else.
Three categories cover almost every setup:
- Server-side forwarding (alias). The mail server at example.com knows that
contact@is an alias foralice@gmail.com. When mail arrives, the server forwards before any user-facing inbox is touched. The mailbox doesn’t exist as an independent inbox; it’s just a pointer. - Server-side forwarding (rule). The mailbox does exist as a real inbox. After mail arrives, a server-side rule (often configured by the user via the provider’s web UI) forwards a copy or the original to another address.
- Client-side forwarding. A filter in the user’s email client (Gmail web, Outlook desktop, etc.) forwards messages after they’ve already been downloaded by the client. The forwarding happens from the client’s outbound, not the server.
From a technical standpoint, server-side aliases are the cleanest: the message is rerouted before any storage, no extra processing, no client involvement. Server-side rules and client-side rules each introduce additional steps that can break or get out of sync.
The DMARC problem with forwarding
This is where most forwarding setups go wrong. DMARC requires that either SPF or DKIM align with the From header for a message to pass. Forwarding modifies the envelope:
- Original sender Alice at
alice@acme.comsends tocontact@example.com. - Mail server at example.com receives. Envelope sender (Return-Path) is
alice@acme.com. SPF passes for acme.com. DKIM is signed by acme.com. - example.com’s forwarding rule kicks in: the message is resent to
bob@gmail.com. - Gmail receives. The envelope sender is now
example.com(the forwarder), notalice@acme.com. SPF check is for example.com’s IP, not acme.com’s. SPF fails to align with the From header (stillalice@acme.com). DKIM may still validate if the forwarder didn’t touch the message body, but a missing or modified List-Unsubscribe / footer breaks DKIM too. - Result: DMARC fails. If acme.com has
p=reject, Gmail rejects the forwarded mail entirely. Bob never sees it.
This is the same failure mode that mailing lists suffer. Without a fix, forwarding from your custom domain to a personal Gmail or Outlook routinely breaks authentication for any sender with strict DMARC.
Fix 1: ARC (Authenticated Received Chain)
ARC is the modern fix. The forwarder adds ARC headers attesting that the message passed DMARC before forwarding modified anything. The final receiver, if it trusts the forwarder, honors the ARC chain and delivers the message despite the SPF break.
Implementation: the forwarder (your mail server or your provider’s forwarding feature) must support ARC and sign each forwarded message with its own DKIM-style key. Major providers that sign ARC for forwarding:
- Gmail’s auto-forward (Settings → Forwarding and POP/IMAP)
- Outlook.com / Microsoft 365 forwarding
- iCloud forwarding
- FastMail and most modern mailbox providers
- Mailman 3 mailing lists (since 3.3)
If you operate your own mail server, ARC support is available in Postfix (via OpenARC), in Exim (via the ARC patch), and in many ESP relay setups.
ARC is the cleanest fix because the original message body, From header, and DKIM signature stay intact. The forwarder just adds attestation headers.
Fix 2: SRS (Sender Rewriting Scheme)
SRS rewrites the envelope sender to the forwarder’s own domain, with a cryptographic token that encodes the original sender. After SRS:
- Original envelope sender:
alice@acme.com - SRS-rewritten envelope sender:
SRS0=hash=ABC=acme.com=alice@example.com
The final receiver checks SPF against the SRS-rewritten address, which lives at example.com (the forwarder). SPF passes for example.com because the forwarder is sending. DMARC alignment check uses the From header (still alice@acme.com), which doesn’t match the envelope, so DMARC alignment fails unless DKIM also aligns (which it usually does, since DKIM is signed by acme.com and the body wasn’t modified).
SRS is less elegant than ARC because the envelope is mangled, but it has historical depth (it’s been the default for Postfix forwarders since the early 2010s). Most self-hosted mail servers can be configured for SRS via postsrsd or a similar daemon. cPanel’s “Email Forwarders” feature has used SRS by default for many years.
Setup walkthrough by provider
Gmail (Google Workspace + consumer)
Web UI → Settings → “See all settings” → Forwarding and POP/IMAP → “Add a forwarding address”. Confirm the address by clicking the link in the verification email Google sends. Then choose “Forward a copy of incoming mail” with options to keep or archive the original. Gmail signs ARC on forwarded messages, so most modern receivers will deliver them despite the SPF break.
Microsoft 365 (admin level)
For tenant-wide rules: Exchange admin center → Mail flow → Rules → “Forward the message to”. Per-user: Outlook web → Settings → Mail → Forwarding. Microsoft 365 signs ARC on forwarded mail since 2020. For tenants with strict outbound DMARC, recipients of forwarded mail from your domain should not face delivery problems.
Microsoft 365 (per-user with smart features)
Outlook Rules wizard supports “forward it to people or distribution list” as a condition action. Client-side rules run only when Outlook is open, so server-side rules (admin-configured or per-user web UI) are more reliable.
iCloud
iCloud web → Settings (gear icon) → Preferences → General → Forward my email to. Enter destination address. iCloud forwards with ARC support. Note: iCloud forwarders are simple “all mail” forwards; no per-message rule support.
cPanel / shared hosting
cPanel → Email → Forwarders → Add Forwarder. Specify the source (full address or all mail at a domain) and the destination. cPanel implements SRS by default for envelope rewriting, so SPF passes at the final receiver. DKIM survival depends on whether cPanel’s mail server modifies the message in transit (most don’t for plain forwards).
Google Workspace catch-all
Admin console → Apps → Google Workspace → Gmail → Routing → Catch-all address. Set the catch-all to a real user mailbox and Workspace delivers all unmatched addresses there. ARC-signed on forward, but consider whether catch-all is the right pattern: it removes the bounce signal for misspelled addresses, which can hide deliverability issues.
Custom domain via a forwarding service (ImprovMX, ForwardEmail, MXroute)
Configure MX records to point to the forwarding service. Service provides web UI for source-to-destination mapping. Most modern forwarding services implement SRS or ARC (or both); confirm with the provider before relying on it for high-volume mail.
Forwarding for catch-all and aliases
A common setup: forward contact@, sales@, support@ from a custom domain to a personal Gmail. Two paths:
- Individual aliases. Each address (contact@, sales@, support@) maps to a single destination (alice@gmail.com). Clean, scoped, easy to audit.
- Catch-all forwarding. Any address at the domain forwards. Catches typos, but also catches spam to random addresses (info-typo@, billing-test@) and merges them into one inbox. Heavy noise.
For most use cases, individual aliases are better. Set up the specific addresses you actually use, and let unknown addresses bounce so spammers can’t probe your domain blindly. See our catch-all detection guide for the trade-offs.
Security risks in forwarding
- Forwarding loops. A forwards to B; B forwards back to A. The message bounces forever until one server gives up. Modern servers detect loops via the Received header chain and break after a few iterations, but loops still cause delay and confusion.
- Business email compromise (BEC). An attacker who gains access to a mailbox often adds a forwarding rule to siphon mail to an external address before the breach is noticed. Audit forwarding rules periodically: any user-configured rule sending mail externally is a security red flag.
- Accidental data exfiltration. An employee sets up forwarding from their work address to a personal Gmail “for convenience”. Sensitive corporate mail flows to a personal account that isn’t covered by your DLP, encryption-at-rest, or access controls. Most enterprise IT policies block this; verify yours.
- Replay attacks. SRS-rewritten addresses are time-limited (the cryptographic token expires after a configured window). Without expiry, an attacker who captures a SRS bounce could replay it indefinitely.
- Spam amplification. A catch-all forwarder pointed at a personal mailbox merges all spam-to-random-addresses into one inbox. The spam load compounds; eventually the destination provider flags the forwarder’s IP, breaking legitimate forwarding too.
10 common email forwarding mistakes
- Setting up forwarding without ARC or SRS. Forwarded mail breaks DMARC for any sender with strict policy.
- Forwarding from a strict-DMARC domain to a personal Gmail. If the original sender’s domain publishes
p=reject, forwarded mail without ARC may be rejected outright. - Trusting client-side forwarding for critical mail. Outlook desktop rules only run when Outlook is open. Server-side rules run regardless.
- Forgetting to remove forwarding when an employee leaves. Mail keeps flowing to the ex-employee’s personal address. Data leakage continues silently.
- Treating forwarding as backup. Forwarding doesn’t keep a copy unless explicitly configured to. If the destination loses the message, it’s gone.
- Catch-all forwarders pointed at personal Gmail. Spam volume buries the legitimate mail. Use individual aliases instead.
- Not auditing user-created forwarding rules. A common BEC pattern. Add forwarding rule audits to security reviews.
- Forwarding to free email providers that limit incoming volume. Some free providers cap inbound at a few hundred messages per day; high-volume forwarding hits the limit and bounces.
- Configuring forwarding before SPF, DKIM, and DMARC are set up. The first thing forwarding tests is authentication. Get those right first.
- Not testing forwarding from multiple source domains. Mail from acme.com (strict DMARC) and mail from yahoo.com (relaxed) behave differently when forwarded. Test both before declaring victory.
Email forwarding FAQ
Why do forwarded emails end up in spam?
Almost always because of DMARC failure. Forwarding rewrites the envelope sender, which breaks SPF alignment. If the original sender’s domain publishes a DMARC policy and your forwarder doesn’t support ARC or SRS, the final receiver sees a failed DMARC check and routes to spam (or rejects entirely on p=reject). Fix by using a forwarder that signs ARC (Gmail, Microsoft 365, modern providers do this) or implements SRS (most self-hosted mail servers).
Should I use server-side or client-side forwarding?
Server-side. It runs regardless of whether the client is open, applies authentication fixes at the server (ARC, SRS), and doesn’t depend on the user’s device being online. Client-side rules (Outlook desktop, Thunderbird filters) only run when the client is running; messages received while the client is offline don’t get forwarded until the next time it connects. For anything important, configure forwarding on the provider’s web UI or via an admin rule, not via client filters.
Can I forward email from a custom domain to a personal Gmail?
Yes, and it works well when the forwarder supports ARC or SRS. Standard cPanel forwarders use SRS; modern hosting providers and dedicated forwarding services (ImprovMX, ForwardEmail) support ARC. Confirm with your specific provider before relying on it. The common alternative is to set up the destination Gmail to “Send mail as” the custom-domain address, which lets you reply from the original address while the mail itself flows through Gmail.
Does forwarding break DKIM?
Often no. DKIM signs the message body and certain headers; as long as the forwarder doesn’t modify those, the DKIM signature stays valid through the forward. The most common DKIM breakers are footer injection (the forwarder adds a “this email was forwarded by…” note at the bottom) and aggressive antispam rewriting that modifies subject lines. Plain forwarding without modification keeps DKIM intact, which is what makes ARC and SRS workable.
How do I detect and break a forwarding loop?
Modern mail servers count Received: headers and abort after a configurable limit (usually 25 to 100). If you suspect a loop, look at the raw headers of a stuck message; a long chain of Received hops between the same two servers is the giveaway. Fix by removing or correcting one side of the loop. Servers also accept loop-detection headers like X-Loop: if you set them, but this is rare in practice.
Is email forwarding a security risk for my organization?
It can be. Attackers who compromise a mailbox often add forwarding rules to silently exfiltrate mail to an external address. Enterprise security teams should audit user-created forwarding rules regularly; alert on any new external-destination rule. Additionally, mail forwarded to personal addresses bypasses DLP, encryption-at-rest, and corporate access controls. Many enterprise email policies disable user-created forwarding to external addresses entirely.
Final words
Email forwarding is one of those features that’s so simple in concept that people skip the authentication implications, then spend weeks debugging why mail “from my old job address” lands in spam at my Gmail. The single most useful thing to remember: any forwarder you set up must support ARC or SRS, or the forwarded mail will fail DMARC at strict-policy destinations.
For modern setups (Gmail, Microsoft 365, iCloud, cPanel), the support is built in. For self-hosted mail servers, ARC and SRS are opt-in features that need to be configured. For DIY forwarding scripts or quick hacks, neither is in place and the resulting mail tends to be rejected at major receivers.
For broader context, see the email protocols overview, the SMTP setup guide, our ARC explainer, and the DMARC guide.
Clean your list before forwarding multiplies the damage.
SMTPing catches what regex misses: disposable addresses, role-based emails, catch-all domains, syntax errors, dead mailboxes and known traps. 13 validation types, 25 free checks daily, no card required.
About the Author
Alaa · LinkedIn
Email infrastructure specialist with 8+ years of hands-on experience in SMTP, deliverability, and email verification. I’ve configured and troubleshot mail systems across Postfix, Exchange, and cloud relays, managed IP reputation and warmup campaigns, and built verification pipelines processing millions of addresses. My work spans DNS authentication (SPF, DKIM, DMARC, BIMI), bounce handling, blocklist monitoring, and compliance frameworks including CAN-SPAM and GDPR. I write every article on SMTPedia to give email professionals, developers, and marketers the accurate, RFC-grounded reference they need.
About SMTPedia
SMTPedia is an independent email industry reference covering SMTP, IMAP, POP3, email deliverability, marketing platforms, DNS authentication, and email verification. Every article is researched from official provider documentation, IETF RFCs, and industry best practices. Settings and configurations are verified quarterly.
We are cited as a source by ChatGPT, Microsoft Copilot, and thousands of email professionals worldwide. Learn more about our editorial process.
