People use forwarding and aliases as if they were two names for one setting. They are not. Forwarding moves mail from A to B and stops there. An alias gives each site its own address, with its own switch and its own reply path. That control is the whole point. AliasFleet is an email-alias service built on the second idea, and this piece works through the difference mechanism by mechanism.
Say you hand your real address to an online shop. Months later the shop gets breached, or sells its list, and the spam starts. With forwarding there is nothing to switch off except everything. With an alias you switch off that one address and the rest of your mail keeps flowing. That is the difference this piece is about.
Forwarding is one rule for everything
Open a forwarded order confirmation. It looks like it came from the shop, because the visible headers still name the shop. The part that changed is invisible: the envelope recipient, the addressing servers use to route the message. RFC 5321 defines that envelope: the SMTP MAIL FROM and RCPT TO commands. RFC 5322 defines the message format, the headers your mail app shows: From, To, Reply-To, Subject. Forwarding rewrites the envelope so the message lands in your second inbox. It leaves the headers alone.
The rule itself is just as blunt. Gmail forwards every new message except spam to one verified address, unless you build a filter for a subset. Outlook offers forwarding or redirecting from your mailbox to another account. Either way one rule covers the lot. It cannot tell a sender that matters from one that does not.
So the sender holds an address that leads straight to you, with nothing in between. If that sender gets breached or sells the list, the same address keeps working for whoever holds it. Switch the rule off and you stop everything at once. Build filters and you get sorting. Sorting is not control.
Three ways the pipe lets you down
Start with the failure people feel first. One forwarding rule treats every sender the same. There is no switch per sender, no way to cut one sender off while the rest keep coming, and no way to read the address and tell which sender leaked it. You handed every site the same key. You cannot take that key back from one of them alone.
Then there is the reply direction, which has nothing to do with protocols. Outlook.com says forwarded messages arrive looking forwarded from your account, and replies go back to your account, not the original sender, unless you set up a redirect rule. Forwarding and redirecting sound like the same thing. They point replies in opposite directions. One keeps the reply pointed at you. The other keeps it pointed at the original sender.
The third failure lives in authentication. SPF checks the envelope sender domain against the IP of the server handing the message over. RFC 7208 defines SPF. A forwarder that relays with the original envelope sender untouched presents its own IP, which the original domain never authorised. The check fails. DMARC Report says it plainly: forwarding breaks SPF for exactly this reason, and DKIM exists partly to cover the gap.
SRS is the standard repair. Sender Rewriting Scheme rewrites the envelope sender into the forwarder domain, encoding the original sender inside it, so SPF passes and bounces can find their way back. Microsoft documents SRS this way for Exchange Online, and notes that the visible From stays untouched. That last detail is the catch. SRS repairs SPF. It does nothing for DMARC on its own.
DMARC wants alignment. RFC 7489 requires the SPF or DKIM domain to match the domain in the visible From header. A rewritten envelope sender in the forwarder domain does not match the original From domain. A forwarded message can pass SPF through SRS and still fail DMARC if nothing else lines up. DKIM is often what rescues it. RFC 6376 defines DKIM as a signature over headers and body, and that signature survives forwarding while the signed content stays unchanged. Let an intermediary alter a signed header or the body and DKIM breaks too.
ARC exists for that chain problem. RFC 8617 defines the Authenticated Received Chain, in which each handler seals its authentication assessment for later receivers to weigh. It is experimental, and it only works where receivers trust the sealer. DMARC Report describes the usual shape in practice: plain forwarding commonly breaks SPF yet preserves DKIM, so DMARC often still passes through DKIM, while content changes break DKIM and leave ARC or a rewrite as the remaining options.
The alias layer adds control, not just delivery
Now give the same shop an alias instead of your real address. Spam starts arriving on that alias. You already know where it came from, because no one else ever had that address. The address is the evidence. The switch is the fix. That is the leak attribution mechanism working in practice.
An alias is not a smarter forward. It is a different object. RFC 5598 describes an alias as a mediator that resubmits a message, changing only the envelope recipient and leaving the return address untouched. A managed alias service builds control on top of that resubmission: one address per site, one switch per address, one reply path per address. What an email alias is covers the definition in full. This section covers what the definition buys you.
| Plain forwarding | Managed alias | |
|---|---|---|
| Address the site holds | Your real address, or a single address shared by every site | One address per site |
| Destination | One inbox under one rule | Your inbox, one rule per alias |
| Reply identity | Usually your real address, unless you set up send-as | The alias, via reply routing |
| Per-sender control | Filters only, no per-sender off switch | Pause or kill one alias, the rest carry on |
| If the address leaks | The leak leads to your real address | The leak leads to one alias, which names the source |
| Authentication handling | Down to the forwarder, SRS or ARC where present | SRS in the AliasFleet catalog, plus the same DKIM and ARC mechanics |
Deactivation shows what control means in practice. AliasFleet docs say a deactivated alias bounces with a standard delivery failure, that the bounce reveals nothing about your identity or the service, and that switching it back on takes effect at once, with no queueing.
This is what that control looks like in practice: every alias with its own destination, its own switch, and its own controls.
Forwarding never had per-sender control. Pause one alias and the rest keep working. Block one sender on one alias and the rest of that alias keeps working. The finer controls sit on paid plans: sender-specific blocklists, conditional routing rules, and vendor leak detection with one-click remediation. Control sits with the address, not with a global filter.
A breach reads differently through aliases too. A leaked real address means a long cleanup. A leaked alias means a quick fix plus a clear record of which site was involved. Run the alias past Have I Been Pwned to see whether it has turned up in a known breach, then pause, replace, or kill it. The blast radius is one address, not your whole identity.
Replies are where forwarding gives you away
Here is a test worth running before you trust any alias setup. Open a message that arrived through an alias, hit reply, and look at the From line before you send. Your real address in that line means the alias is not guarding the reply path. The alias in that line means the routing is doing its job.
Receiving is the easy half. Answer from your real inbox and the game is over: the reply carries your real address as the sender, and the site now holds it, however clever the forwarding setup was. No pipe failed. One click handed it over.
Alias reply routing closes that gap. Answer the forwarded message and the service sends your reply out from the alias. The recipient sees the alias, never the address underneath. AliasFleet Quick Send covers the other direction: opening a new thread from an alias, sent from AliasFleet servers, with the docs stating that the recipient cannot see the real inbox address, mail client identifiers, or routing headers. The earlier piece on how email aliases actually work walks through the forwarding rule, the reply trick, and the kill switch as one journey. The reply point bears repeating because it is the leak people miss.
Before you send any reply through an alias, glance at the From line. Alias showing means the reply path is guarded. Real address showing means it is not, whatever the setup promised.
Pick the tool that matches the job
Use aliases when the job is identity. You sign up for a site you do not fully trust yet. You want to know which site leaked your address when the spam starts. You want one sender stopped without stopping the rest. You want replies to stay on the alias. No filter setup makes forwarding do that job.
Use plain forwarding when the job is delivery and nothing else. You changed jobs and want old mail to reach your new inbox. You run two inboxes and want one place to read. You need a short-lived redirect while you migrate. Forwarding handles those jobs, because control is not the point.
Starting from scratch, pick one signup you barely care about and give it an alias. Watch mail arrive addressed to the alias. Reply once and check the From line. Pause the alias once and watch the switch work. The setup guide covers the steps. The habit builds one signup at a time.
One thing an alias cannot do: hide your behaviour. Click a link in a message and the site sees the click. Reuse one alias across many sites and you throw away the attribution that one alias per site gives you. The control depends on the habit.
The pipe shifts mail. The alias decides who reaches you. Match the tool to the job.
Top comments (0)