Email Alias vs Forwarding (2026): Fix the Routing Mess

I once spent three hours on a call with a client who swore their email was "broken." Customers were replying to invoices, and the replies just... vanished. Not bouncing. Not in spam. Gone.

Turns out they'd set up billing@theirdomain.com as a forward to their personal Gmail. The forward worked fine for incoming mail. But when customers replied to those forwarded invoices? Gmail's SPF checks failed because the original sender's domain didn't authorize my client's forwarding server. Some replies went to spam. Others got silently dropped by overly aggressive filters.

It took us an hour just to figure out that forwarding was the culprit. An hour. For something that shouldn't exist in the first place.

I've made this exact mistake, by the way. Set up a nice clean forward for a side project, wondered why nobody ever responded to my outreach for two months. Two months of radio silence before I thought to check. Embarrassing.

The confusion between email alias vs forwarding causes more support tickets than almost any other email topic. And the deliverability consequences — broken SPF, failed DKIM, replies landing in spam — are real. If you're still weighing Google Workspace alternatives, understanding routing is essential before you migrate.

Here's how each one actually works, when to use which, and the gotcha that trips up even experienced sysadmins.

What We're Building

By the end of this, you'll understand exactly when to use an alias, when forwarding is appropriate (hint: rarely), and how distribution lists differ from both. You'll also know why forwarding breaks email authentication and what to do instead.

If you're on JustEmails, you can set up unlimited aliases in about 30 seconds per address. No deliverability drama.

Prerequisites

• A custom domain with email hosting
• Access to your email provider's admin panel
• Basic understanding of email addresses (seriously, that's it)
• Optional: familiarity with SPF/DKIM/DMARC (helpful for the deliverability section)

Step 1: Understand Email Alias vs Forwarding

Let's define terms. I know, I know — you probably think you know these already. But the number of people who use "alias" and "forwarding" interchangeably is staggering. And they're not the same thing. At all. This conflation is honestly my biggest pet peeve in email support tickets.

Alias

An alias is a secondary address that delivers to an existing mailbox. The mail never leaves your email provider's servers.

Example: You have mike@yourdomain.com as your real mailbox. You create an alias: info@yourdomain.com → mike@yourdomain.com. Emails to info@ land directly in Mike's inbox. No forwarding. No separate hop. The alias is essentially another name for the same mailbox.

Key point: the email stays on the same mail server. SPF, DKIM, and DMARC are unaffected because there's no retransmission.

Forwarding

Forwarding takes an email received at one address and sends it to a completely different address — often on a different server entirely.

Example: You set up hello@yourdomain.com to forward to yourpersonal@gmail.com. An email arrives at hello@, your server receives it, then re-sends it to Gmail. Gmail receives an email that originated from your forwarding server, not the original sender.

Key point: the email is retransmitted. This is where authentication breaks down. And this is why I wish forwarding had never been invented as a consumer-facing feature. It's a footgun.

Distribution List (or Group)

A distribution list is a single address that, when someone sends TO it, delivers copies to multiple recipients.

Example: team@yourdomain.com is a distribution list containing alice@, bob@, and carol@. When someone emails team@, all three people get a copy.

Key point: distribution lists are about sending to groups, not routing inbound mail. They're often confused with aliases because both involve "one address → multiple people," but the mechanism and use case differ.

Step 2: Set Up an Alias (The Right Way for Most Cases)

Aliases are what you want 90% of the time. If you need sales@, support@, info@, billing@, contact@ — these should be aliases pointing to actual mailboxes.

In JustEmails:

1. Go to your dashboard → Domains → select your domain
2. Click "Add Alias"
3. Enter the alias address (e.g., info@)
4. Select the destination mailbox
5. Save

That's it. Done. The alias is active immediately. No DNS changes required because it's handled internally.

In Google Workspace:

1. Admin console → Users → select the user
2. Add alternate email addresses (aliases)
3. Save

Google allows up to 30 aliases per user on most plans.

In Microsoft 365:

1. Admin center → Users → Active users → select user
2. Manage email aliases
3. Add the alias

Microsoft calls them "email aliases" too, so at least the terminology matches.

Why aliases don't break deliverability: When someone emails info@yourdomain.com and it's an alias for mike@yourdomain.com, the mail server simply delivers to Mike's mailbox. There's no "forwarding" in the SMTP sense. The original email headers remain intact. SPF passes because the mail was delivered to your domain. DKIM signatures remain valid. DMARC sees no issues.

Clean. Simple. No drama. Use aliases for virtually every secondary address. If you're setting up custom domain email for the first time, aliases are almost always what you want.

Step 3: Understand Why Forwarding Breaks SPF (The Deliverability Gotcha)

OK, here's the part that causes all the pain.

Let's say alice@external.com sends an email to hello@yourdomain.com. You've set up hello@ to forward to yourpersonal@gmail.com. Here's what happens:

1. Alice's mail server sends the email. SPF record for external.com authorizes Alice's server.
2. Your mail server receives the email at hello@yourdomain.com. SPF passes — the sending IP matches external.com's SPF record.
3. Your server forwards the email to Gmail. Here's the problem: the email's envelope sender (Return-Path) still says alice@external.com, but now the sending IP is your forwarding server's IP.
4. Gmail checks SPF for external.com. Your forwarding server's IP is NOT in external.com's SPF record. SPF fails.
5. Gmail now has an email claiming to be from alice@external.com that failed SPF. Depending on DMARC policy and Gmail's spam scoring, this email might go to spam or be rejected entirely.

This isn't a bug. It's how SMTP forwarding has always worked. The email is technically being re-sent from a server that isn't authorized to send on behalf of the original sender's domain.

Partial fixes exist:

• SRS (Sender Rewriting Scheme): Some providers rewrite the envelope sender to their own domain when forwarding. This fixes SPF but can break reply handling.
• ARC (Authenticated Received Chain): A newer standard that lets intermediary servers vouch for forwarded messages. Gmail and Microsoft support ARC, but adoption isn't universal.

Neither fix is complete. Neither is implemented by every provider. So if you're forwarding mail to an external address, you're gambling on deliverability. I hate this about email infrastructure, honestly. We've had decades to solve this properly and we're still patching around it.

Step 4: When Forwarding Actually Makes Sense

There are exactly two scenarios where forwarding is defensible:

1. Temporary migration bridge

You're migrating from one email provider to another. During the transition, you forward mail from the old provider to the new one so nothing gets lost. This is temporary — days or weeks, not months.

2. Backup paranoia

You want a copy of all mail sent somewhere as a backup. You forward to an archive address. Even here, aliases plus server-side rules are usually better, but I get the appeal of a "just forward everything" approach. I've done this myself. Not proud of it, but it worked for a specific project where I needed belt-and-suspenders redundancy and didn't care about authentication on the backup copy.

That's it. For ongoing mail routing on your custom domain, use aliases.

Step 5: Set Up a Distribution List (For Outbound Group Communication)

Distribution lists serve a different purpose: sending to multiple people simultaneously.

Use cases:

• team@ sends to all five team members
• all-hands@ reaches the entire company
• investors@ goes to your investor list

In JustEmails:

Distribution lists work like aliases that point to multiple destinations. Create an alias (e.g., team@) and add multiple destination mailboxes.

In Google Workspace:

1. Admin console → Groups
2. Create group (e.g., team@yourdomain.com)
3. Add members
4. Configure who can send to the group

Google Groups offers more control — you can set whether external senders can email the group, whether replies go to the group or the sender, etc.

Important distinction: Distribution lists are for SENDING to groups. When someone external emails team@, everyone in the group gets it. This is inbound mail splitting, not outbound mail routing. The authentication considerations are similar to aliases (handled within your provider), so deliverability is fine.

Common Errors and Fixes

"Forwarded emails going to spam"

Cause: SPF failure due to forwarding (see Step 3). Fix: Stop forwarding. Use aliases instead. If you absolutely must forward, check if your provider supports SRS or ARC. But really, just stop forwarding.

"Replies to forwarded emails bounce"

Cause: The Reply-To header points to the original sender, but the recipient's reply goes to a broken path. Or the forwarding changed headers in weird ways. Fix: Again, stop forwarding. Aliases preserve reply paths correctly.

"Distribution list sending to wrong people"

Cause: Outdated member list or misconfigured group settings. Fix: Review group membership in your admin panel. Check if departed team members are still included.

"Alias not receiving mail"

Cause: Typo in alias configuration, or DNS pointing to wrong mail server. Fix: Verify the alias spelling in your provider's admin panel. Confirm your domain's MX records point to the right mail server.

"Can't tell if mail came to alias or main address"

Cause: Most email clients don't prominently show the "Delivered-To" header. Annoying, I know. Fix: In JustEmails and most providers, you can see the original recipient in email headers. Look for the "Delivered-To" or "X-Original-To" header. Some providers also let you filter or label by alias.

Next Steps

Now that you understand the routing options:

• Audit your current setup. If you have forwards going to external addresses, consider replacing them with aliases and using your provider's unified inbox instead.
• For multi-domain setups, check that each domain uses aliases rather than cross-domain forwarding. Consolidating email providers onto one host is easier than juggling forwards.
• If you're running ClickzProtect for ad fraud protection or JustAnalytics for privacy-focused analytics alongside your main business domain, use aliases to route support@ and abuse@ addresses to your central mailbox without forwarding headaches.
• For proper email authentication, make sure SPF, DKIM, and DMARC are configured correctly on all your domains. Our DMARC guide covers moving from p=none to p=reject safely — and aliased mail won't break any of that.

If you're managing email for clients or running an agency, the difference between "properly configured aliases" and "forwarding mess" is the difference between emails landing in inbox vs. spam. We've covered why flat-fee email beats per-mailbox pricing for agencies — and at $49/year for unlimited domains and unlimited email accounts on JustEmails, there's no reason to cut corners with forwarding. Just... don't forward. Please.

Frequently Asked Questions

Does email forwarding break SPF authentication?

Yes — almost always. When you forward an email, the sending server changes but the envelope sender (Return-Path) often stays the same. The receiving server checks SPF against the original sender's domain, but the IP is now your forwarding server's IP, which fails the SPF check. Some providers use SRS (Sender Rewriting Scheme) to fix this, but many don't. This is the single biggest reason forwarding causes deliverability problems.

Can I use aliases and forwarding together?

You can, but be careful. Aliases are handled within your email provider (no deliverability risk). Forwarding routes mail to a completely different server (deliverability risk). If you create an alias that points to a mailbox on the same provider, that's safe. If you forward mail to a Gmail address or another external service, you inherit all the SPF/DKIM forwarding problems.

What's the difference between a distribution list and forwarding?

A distribution list sends a single email to multiple recipients (one-to-many). Forwarding takes incoming mail to one address and redirects it to another address (one-to-one redirect). Distribution lists are for outbound communication to groups. Forwarding is for routing inbound mail somewhere else. They're often confused because both involve multiple people receiving emails, but the direction of mail flow is different.

Should I use forwarding or aliases for a custom domain?

Aliases, almost always. Aliases keep mail within your email provider, which means SPF, DKIM, and DMARC all pass cleanly. Forwarding to an external address (like your personal Gmail) breaks authentication and can cause your messages to land in spam. The only time forwarding makes sense is when you're consolidating mail from multiple providers during a migration — and even then, it's temporary.

---

Try JustEmails

Unlimited custom domain email hosting for $49/year flat — unlimited domains, unlimited email accounts, 10 GB storage, full IMAP/SMTP/POP3. Built for agencies, freelancers, and anyone managing email across more than one domain.

Start your 7-day free trial → · How it compares