An email alias is not a second inbox. Nothing about your email life changes except the address each site gets to see. I build AliasFleet, an email alias service, so I watch this machinery from the inside every day: a site sends mail to your alias, the alias hands it to your real inbox, and when you reply, the answer goes out wearing the alias. Three pieces. That is the whole trick, and once you see the three pieces you understand aliases completely.
If you want the short version first, this is what an email alias is. This piece is the mechanical version: what actually happens to a message, step by step.
Piece one: the forwarding rule
When you create an alias like shop@yourdomain or a random string at a shared domain, you are registering a real, working email address. Its mail servers belong to the alias service. When a shop sends an order confirmation to it, the message travels the ordinary internet mail path and lands on the service's servers, which look the alias up in a routing table: this alias belongs to this account, forward to this inbox.
Then the service forwards it. Your real inbox receives a normal-looking email. Most services tag it somehow, a small banner or label noting which alias it arrived on, because that label is half the value: it tells you who sent it without you having to think.
| What the website sees | What you see | |
|---|---|---|
| The address | The alias, and nothing else | Your normal inbox, mail labelled by alias |
| Your real address | Never. It is not in any header they receive | Only in your own account settings |
| On breach day | The alias, in the stolen file | A notification naming exactly which alias leaked |
How does the alias know where to send the mail?
The routing table is the unglamorous heart of the whole system. Your account holds the mapping: alias A goes to inbox X. When mail arrives for alias A, the server does a lookup and re-sends the message to inbox X. There is no magic and no second mailbox. It is a lookup and a forward. On the infrastructure I run, that round trip completes in well under a second.
Email has two layers: the envelope (the addressing the servers use, invisible to you) and the headers (the From, To, and Subject lines your mail app shows). Forwarding rewrites the envelope so the message reaches your inbox, while the visible headers still show the original sender. That is why a forwarded order confirmation still looks like it came from the shop, even though your address was never involved.
Piece two: the reply trick
Receiving is easy. Replying is where the engineering lives, because a naive reply would expose your real address the moment you hit send. Every serious alias service solves this, and the solutions rhyme.
SimpleLogin's public docs describe the mechanism precisely: when a sender emails your alias, the forwarded message arrives from a special per-sender address called a reverse-alias. You just hit reply. You are technically replying to the reverse-alias, and SimpleLogin re-sends your answer from your alias. Your real mailbox address stays hidden, and the reverse-alias is unique per sender and alias, so nothing leaks sideways.
AliasFleet handles it two ways. Replying to a forwarded message works the same way, through the alias. There is also a dashboard composer, Quick Send, for starting a new thread from an alias: you pick the alias, write the message, and it is dispatched from AliasFleet's servers. The docs are explicit about what the recipient cannot see: your real inbox address, your mail client identifiers, and the routing headers. Staged attachments are deleted immediately after delivery under a zero-retention policy.
The honest footnote: no forwarding service can hide everything. If you click the shop's links, the shop sees the click. The alias hides your address, not your behaviour. Tracker blocking is a separate feature, and any provider that implies otherwise is overselling.
Piece three: the kill switch
This is the piece that justifies the other two. An alias you can not turn off is just a second address. An alias you can kill is control.
On AliasFleet, flipping an alias off takes effect immediately: mail sent to a deactivated alias bounces back to the sender with a standard delivery failure, and the sender sees an address that does not exist. Nothing in the bounce reveals your identity or the service behind it. Your alias, its settings, and its history stay in your account, so flipping it back on restores everything. Deactivation is reversible. Deletion is permanent.
Other services make the same promise with different mechanics. addy.io's guide to per-site addresses, which I keep coming back to in this series, documents theirs: a deactivated alias silently discards incoming mail (the spammer never knows), while a deleted alias bounces with a hard error:
"550 5.1.1 Recipient address rejected: Address does not exist" (addy.io's bounce message for a deleted alias) Mozilla's Relay lets you block senders or delete masks from the dashboard. The shape is universal: the link between the site and your inbox exists only while you allow it.
That is what leak attribution runs on. When spam arrives on one alias, the alias names the source, and the toggle ends it. No filters to tune, no unsubscribe links to trust.
Why a plus address is not the same thing
you+shop@gmail.com does something that looks similar and is not. Plus addressing is a real standard, RFC 5233 subaddressing, but the base address is right there in the open: anyone can strip the tag and reach you@gmail.com. Gmail ignores dots in addresses entirely, which tells you these variants were never meant to be identities. A real alias reveals nothing to strip. I wrote the full breakdown of where the plus trick fails; the short version is that a label is not an identity.
The honest limits
Three, and I would rather you hear them from me than discover them mid-signup.
First, some sites refuse alias addresses. Researchers who tested 28 email providers and 18 platforms found only five platforms even attempt alias detection, and in my experience the ones that block tend to target well-known shared alias domains rather than aliases as such. A custom domain of your own sidesteps most of it. It is friction, not a wall.
Second, the alias service itself is a party to your mail. It must receive each message to forward it. That is true of every provider in this category, including us, and the right question is not "do they touch my mail" but "what do they keep." Read the retention policy. Ours for outbound staging is zero-retention, stated in the docs, not the marketing copy.
Third, aliases do not make you anonymous to anyone determined. They separate your identity per site so that one breach cannot stitch your accounts together, which is exactly what 17.8 billion exposed addresses on Have I Been Pwned make necessary. Anonymity against a motivated investigator is a different product and a much harder claim. I will not make it here.
Three pieces, one habit
Forwarding rule, reply trick, kill switch. That is an email alias, mechanically, with nothing mystical left. The habit it enables is one alias per site, which turns every future breach into a contained, attributable event instead of an identity-wide emergency. If you want the practice rather than the theory, the setup guide takes about two minutes, and the use-cases guide covers where the habit pays off fastest.
One thing I am still unsure about, after years of building this: whether most people will ever bother. The mechanism is simple and the payoff is real, but it asks for one new habit at signup, and habits are the hardest part of any security product to ship. The technology is done. The rest is persuasion, which is why this blog exists.
Top comments (0)