Hand every site its own alias and you have not spread your trust. You have concentrated it in the one provider that forwards your mail, so what it stores and logs matters more than the alias itself. I run AliasFleet, an email-alias service, and the payoff is simple: one leaked address dies alone while your real inbox stays untouched. That payoff only holds while the provider in the middle keeps almost nothing.
Most alias advice never gets to this part. It tells you to give every site a different address and stops there, as if the address itself were the protection. The address is only a routing rule. Protection lives in what the provider does with your mail after it arrives, and in what it throws away. Ask for retention numbers. When a provider has none to give, that silence tells you plenty.
Your mail passes through one pair of hands
Follow one message and the trust question gets concrete. A shop emails the alias you gave it. The message takes the ordinary mail path and lands on the provider's servers, where it gets matched against a routing table, re-addressed to your real inbox, and sent on. RFC 5321 describes alias expansion in section 3.9.1: the server replaces the envelope address while the rest of the envelope and the body stay unchanged.
Five things are unavoidable in that handoff, and no provider can forward mail without them. The sender address, so you know who the mail came from. The alias itself, so the right rule fires. Your destination address, so the message has somewhere to go. The message, because forwarding means handling content while it passes through. And the routing metadata, the Received trace fields every mail server stamps onto a message as it travels, defined in RFC 5322 section 3.6.7.
That is the floor, and it sets up the uncomfortable bit. While a message is in transit, the provider can read it, in the same way any mail server along the path can. An alias is not encryption. A message that arrives unencrypted stays unencrypted while it gets forwarded, and every server that touches it could read it. What an email alias is says this plainly: an alias has no mailbox and no storage of its own, yet it does not encrypt your mail, and the headers still record the path the message took.
So the test is never whether the provider can see your mail. The test is what remains after delivery.
A provider that deletes the message once it lands in your inbox is a pipe. A provider that archives it, mines it, or holds it "for quality purposes" with no expiry date has become a second inbox you never agreed to.
Two providers put numbers on it
Two published policies, quoted from their own pages, show how different "we take privacy seriously" looks once numbers appear.
| What the provider keeps | SimpleLogin | Firefox Relay |
|---|---|---|
| Message content after delivery | Deleted once it reaches your mailbox | Not read or stored at all |
| Undeliverable mail | Held 7 days for your review | Held until delivered, capped at 3 days |
| IP logs | Wiped after 7 days (except IPs retained for abuse investigation) | No IP-log retention figure given. |
| Metadata it can see | Sender and recipient addresses, originating IP, subject, sent and received times | The alias, the site where it was created, sites where it is later used, labels |
| Content scanning | Unencrypted mail scanned for spam and viruses | Headers checked only when promotional-mail blocking is switched on |
SimpleLogin's privacy policy states the model in the clearest terms I have seen: emails are not stored, a message is deleted once it reaches its destination, undeliverable mail is kept 7 days, and IP logs older than 7 days are deleted (except IPs retained for abuse investigation). It is equally clear about the limits. SimpleLogin states it has access to sender and recipient addresses, the originating IP, the subject line, and the sent and received times, and that it scans unencrypted messages for spam and viruses.
Mozilla's Firefox Relay privacy notice follows the same shape with different numbers. Relay processes messages to forward them, does not read or store the content, and keeps undeliverable mail until it is delivered and never more than three days. It also lists what it stores about your setup: the alias, the site where you created it, sites where you later use it, and any labels you attach. That kind of detail is what a policy should carry.
Neither policy counts as proof. Both are claims published under their own names, and both can be weighed against the next provider's claims. A provider that will not give you numbers has not earned the comparison.
What we claim at AliasFleet, and what we do not
Same treatment, applied to my own service.
AliasFleet's homepage states three things: no email scanning, no ads, ever; 7-day activity log retention; and zero-PII privacy logging, with full data export. The free tier covers 10 active aliases, one verified destination inbox, three managed subdomains, and 100 MB of monthly forwarding bandwidth, per the pricing page. The how forwarding works piece adds two more. A deactivated alias bounces mail with a standard delivery failure. Outbound staged attachments are deleted immediately after delivery under a zero-retention policy stated in the docs. The set-up guide adds the last piece: no verified destination, no forwarding, which is the check that stops the service being an open relay.
Then the limits, because this is the point where a pitch usually stops being useful and starts asking you to take things on trust. I could not verify a published inbound message-retention statement on aliasfleet.com this run, so I will not claim one. The zero-retention claim above covers outbound staged attachments, not inbound mail. An alias service is still a party to your mail, and that is true of every provider in this category, including us: it must receive each message to forward it. And the free tier's 100 MB monthly bandwidth is a real constraint for heavy inboxes. A provider that charges nothing and says nothing about retention is paying its bills some other way, and that is worth asking about.
This is not a disposable email service. Aliases are persistent addresses you manage, with pause and delete controls, and the kill switch only works because the address stays yours. The safety question is not whether the alias expires. It is whether the provider keeps your mail.
Six places the protection runs out
The trail in the headers
Every mail server adds Received trace fields, and forwarding adds hops rather than removing the path. A determined recipient can see the machinery. An alias keeps your address out of a sender's database. It is not a disguise.
The shop that refuses your alias
Sites can and do refuse alias addresses. A community-maintained domain blocklist exists, and PyPI uses it to block registration with short-lived domains. Research presented at NDSS 2026 found platforms handle alias addresses inconsistently, and some block known alias domains outright, per our guide to using aliases. A custom domain sidesteps most of it, because it looks like any other address. Apple learned this in public: it planned a clearly labelled alias domain, users objected that sites could spot and refuse the addresses, and Apple reversed course, as our plus addressing comparison records.
The address you already gave away
An alias only protects addresses you have not handed out yet. The real address you have used for a decade sits in hundreds of databases, and no alias setup retracts it. It only stops the list growing.
The phishing email on the right alias
Attackers who breach the actual shop can email you at that shop's alias, and the To-field test passes. The alias showed you which address the sender was supposed to hold. It cannot judge whether the sender is genuine. Phishing that arrives on the alias you gave the breached site still reaches your inbox.
The reply that gives you away
Answer from your normal inbox when a site emails your alias, and your reply carries your real address. You have undone the alias yourself. The reply has to come from the alias too, which is why two-way reply routing is part of the product, not a bonus.
The malware on your own machine
Malware on your own machine takes the address straight from you, and no alias survives that. Is it safe to give your email to websites records the infostealer wave: addresses stolen from infected devices, not from websites. That is a problem on your own machine, not a signup problem, and no alias setup fixes it, because the theft happens before mail ever enters the picture.
A plus tag is not a substitute: the real address sits inside the tag, and subaddressing means anyone can strip the detail part. An alias also cannot tell you how an address escaped, only which address it escaped through. The leak-tracing guide states that limit up front: do not accuse a company of selling your data on the alias evidence alone.
Five things to get in writing before you trust a provider
Take these to any alias service, including mine. The good ones answer in numbers.
- Message content after delivery: stored or deleted, for how many days, and where that number appears in writing, with the policy page named.
- Metadata logging: which of sender, recipient, subject, IP, and timestamps persist, and when each gets deleted.
- Content scanning: spam and virus checks only, or anything else, and stated in the privacy policy either way.
- Paused or deleted aliases: whether mail bounces, gets discarded silently, or sits in a queue, and who can reactivate the address.
- Export and deletion: full data export plus one-click deletion, as the test of whether your account is yours.
Five answers in numbers earn a trial. "We take your privacy seriously" with no retention figures does not. The alias is only ever as safe as the provider behind it, and the provider is only ever as trustworthy as the retention numbers it has written down.
For the address you already have, there is one move left. Check it on Have I Been Pwned and turn on its notifications. Aliases contain the future. They do nothing for the past, and the past is where most of the risk already sits. Can websites see your real email maps the rest of that route: trackers, ad-platform uploads, brokers, breaches.
Top comments (0)