Forwarding is the mechanism; an alias is forwarding plus per-address control. Both deliver mail sent to one address into a different inbox. The difference is that an alias is a distinct, manageable object โ you create them per service, see which one received what, and switch one off without disturbing any other. Plain forwarding is a single pipe: you can turn it off, but only all of it.
The comparison
| Plain forwarding | Email alias | |
|---|---|---|
| What it is | One address routed to another | Many addresses, each individually managed |
| Typical count | One or two | One per service โ dozens to hundreds |
| Turn off one sender | โ โ you'd stop everything | โ Disable that alias only |
| Tells you who leaked you | โ | โ If one address per service |
| Per-address statistics | โ | โ Usually |
| Hides your real address | โ | โ |
| Setup effort | One rule | One rule, then addresses are free |
Where the confusion comes from
Underneath, an alias is forwarding. Mail arrives for shop@example.com, the server rewrites the envelope recipient to your real inbox, and your provider delivers it. Nothing exotic.
So people reasonably ask why the distinction needs a separate word. The answer is that "forwarding" describes the transport, while "alias" describes a unit of control. It's the difference between having a redirect and having a system.
The practical difference
Say you forward contact@yourdomain.com to your Gmail. A company you gave that address to sells it, and spam starts.
With plain forwarding, your options are: filter it in Gmail, ask the sender to stop, or turn off the forward entirely โ which also kills the legitimate mail arriving at that same address. Three bad options.
With an alias per service, the mail arrived at hardware-store@yourdomain.com, which exactly one company was ever given. You disable that one address. Everything else is untouched, and you now know which company was responsible. What disabling does.
When plain forwarding is enough
It's a perfectly good tool for what it does:
- Consolidating inboxes. Forward an old work address into your current one so you stop checking two.
- A single public contact address you're willing to filter manually.
- A role address โ
support@going to whoever handles support โ where the point is delivery, not attribution.
If you only need one or two routes and you don't care which sender is which, forwarding is simpler and there's no reason to add machinery.
When you want aliases
- You want to know which company leaked your address.
- You want to cut off one sender without collateral damage.
- You're signing up to things regularly and want each relationship isolated.
- You want a breach at one company to expose an address nobody else holds.
The catch-all shortcut
Creating an alias per service sounds like admin, and with most setups it is โ you create each one first. A catch-all domain removes that step: every address at your domain works on first use, so the alias exists the moment you invent it at a signup form.
That's the configuration that makes per-service addresses practical rather than aspirational. It has a trade-off worth understanding. Catch-all explained.
More: email aliases explained ยท how to create aliases, every method