One AliasFleet account can run your real-name email aliases and your anonymous ones side by side, and that account still holds the single record linking both sets to you. Each website gets its own forwarding address and never learns the destination inbox behind it. No website can join them up. Inside the account, they were joined on day one.
None of this makes the setup reckless. It also does not make it private from the provider. A poster on Privacy Guides laid it out in January 2024: a custom domain carrying a real identity in the same private email account as anonymous aliases, banking and shopping on one side, forums, Reddit and newsletters on the other, and one question underneath: should a single provider be trusted to keep those worlds apart? It surfaced again in October 2026, and that user reached the opposite comfort level with the same layout. The difference was never the software. It was who each poster needed to keep the link away from.
Each site sees one address and nothing past it
Start with what a mixed account does well. A forum holding your alias has no idea a banking address exists in the same account. A shop holding your real name has never seen your forum names. When the forum leaks its user table, and forums do, the spill contains an alias and a posting history. Nothing points at your bank. When the shop leaks instead, your forum life stays out of it. One address per site keeps a leak trapped at the site that caused it, which is the whole logic of using a different email for every website.
Working backwards does not help a site either. Forwarding happens on the provider's machines, so the address a site holds is all it ever touches. That route stays on the provider's side of the wall, as what websites can see about your real email covers. One weaker link sits outside the account. Addresses on your own domain visibly share that domain, so a stranger can guess one person owns them. Guess is the right word: no name attached, no inbox shown.
Underneath, a single record holds every address you own
Forwarding is a lookup, nothing fancier. A message turns up addressed to an alias. The provider finds the destination paired with that alias and sends it on. That pairing has to live somewhere, in readable form when a message arrives, or delivery stops. SimpleLogin spells the receiving end out in its docs: a mailbox is the real address your aliases forward to, your signup address becomes your default mailbox, and one alias can feed several mailboxes at once. Addy.io says the same thing from the policy side: it holds recipient addresses so it can forward emails to the recipient addresses you have added.
Four things sit in the record behind an alias account:
| What the record holds | Why it cannot be left out |
|---|---|
| The pairing of each alias with its destination | Routing has nowhere to go without it |
| Who the account belongs to | A signup email, a name if you gave one, a login somebody has to sign in with |
| A link to payment, on paid plans | The subscription has to attach to the account it pays for |
| Logs and delivery metadata | Delivery, abuse control and troubleshooting all leave these behind |
Run a mixed account and the real-name rows and the anonymous rows sit in that one record, under one login. There is nothing to piece together, because nothing was ever in pieces. The mechanics of how email aliases actually work leave no room to opt out. Holding a readable map is the job. Providers differ only in what they pile around that core: how much else they keep, how long logs survive, who can force the door open.
Locked content does not lock the routing record
People reach for encryption first. It answers a different question. Proton says it cannot read the content of encrypted mail, full stop, and then its Proton Mail privacy policy lists what SMTP hands it anyway: sender and recipient addresses, the IP a message arrived from, attachment names, subject lines, sending and receiving times. SimpleLogin's privacy policy publishes a near identical list. Bodies can stay locked for ever. The facts needed to route mail sit in plain view inside the provider's systems, because routing mail is what the provider is for.
Promises about deleting mail have the same edge. SimpleLogin does not keep your messages: delivery triggers deletion, and anything undeliverable is held for 7 days. Addy.io's FAQ says mail is kept only after a failed delivery, and only where you switched that setting on. Good properties. They describe the mail, not the map, which survives as long as the alias has to keep working, and a managed, persistent alias is meant to work for years.
The 2024 poster put their finger on the records and then guessed wrong about their weak point. The poster assumed they sat unencrypted, tying alias to mailbox to the identity that paid for the mailbox. As a blanket claim, the first part fails. Addy.io encrypts recipient addresses and alias descriptions inside its database. SimpleLogin says its databases and backups are encrypted at rest. Strip the wrong word out of that sentence and the rest stands untouched. The records exist at every provider checked for this piece. Encryption at rest covers a stolen disk or a lifted backup file. It does nothing about the provider itself, which resolves that pairing every time a message lands. A provider cannot be blind to its own routing table, and no policy checked here describes a design that would let it be.
What our own record looks like
Test the argument where it costs us something. Our page setting out what AliasFleet stores lists your aliases with their names, descriptions and categories, and states which destination each one forwards to, alongside your destinations and custom domains. The AliasFleet privacy policy fills in the account layer: your account email, login timestamps and IP addresses, plus delivery logs carrying status, timestamps and sender and recipient metadata. Forwarding logs live for 7 days on Free, 30 days on Pro and 90 days on Business. Bodies, attachments and subject lines are not kept once forwarding is done. Card numbers never reach us either: a merchant of record handles billing, and what stays here is subscription references, a customer identifier, the plan type, an invoice status. The map is the service working as designed.
Those are two separate trust decisions, and they break in two different ways. AliasFleet is the alias layer. Its record decides where alias mail goes, which makes it the join between your aliases and your destination. Your inbox provider is a separate company holding a separate record: the delivered mail itself. A failure at one layer does not automatically hand over the other layer's contents. Your setup is only as separate as whichever of the two is easier to get into, a point the earlier piece on whether email aliases are safe pulls at from the provider's end.
The link gets used two ways, and only one needs an attacker
The breach version takes two leaks to hurt you. Leak one happens at a forum: your posts, tied to the alias you registered there. It still names an address, not a person. Leak two happens at the alias provider, where account data ties that same alias to a destination inbox and an account. Now the posts have a name on them. Each leak looks survivable alone. Together they are the exposure. A breach that reached the account database or its backups would put the mapping at risk, even at a provider that never stored a single message body.
No source read for this article documents SimpleLogin, addy.io, Proton or AliasFleet losing an alias map in a breach. Treat that breach route as a scenario to weigh, not an incident to point at.
Two brakes belong on that story. The staff replying in the original thread pushed back hard, with reason: build a second setup purely to survive a provider breach and you may end up trusting more parties, some of them weaker, while downloading mail and deleting it server side cuts what any breach can take. Breach risk argues for choosing a provider with care. Alone, it makes a flimsy argument for splitting, since every split adds another provider that can be breached.
The legal route skips the attacker entirely. A user in the thread said it plainly: if a government request reaches an account, which aliases belong to that account is data the provider holds by necessity. SimpleLogin hands information over when applicable law requires it, under a warrant or court order, and notifies the user unless the law stops it. Addy.io passes its logs to nobody, other than when compelled by law. Proton's policy narrows disclosure to binding requests from the competent Swiss authorities, says doubtful requests get challenged, and adds that end to end encrypted content cannot be decrypted under any circumstances. AliasFleet's policy allows disclosure where the law or a court order requires it. Thresholds differ by jurisdiction, and encrypted content stays out of reach in the cases described. The mapping sits on the reachable side of every one of those sentences.
Then there is payment, the quiet route, which needs no breach and no court. Pay by card or PayPal and a billing identity gets tied to the account at the payment processor, while the provider ties the account to a subscription. Proton keeps the payer's name and the last four digits of the card. SimpleLogin never touches the card at all: it goes straight to its processor. Somewhere in that chain, a paid account and a named person can be paired. Escaping it takes a deliberate move at signup: SimpleLogin and Proton both say anonymous cash payments are accepted, and Proton takes Bitcoin as well. Nobody drifts into paying cash by accident.
A split that stops halfway is decoration
Two accounts at one provider buy you a separate login. Nothing else. The same company keeps both records, fields legal requests that cover both, and runs both on the same systems. It covers exactly one failure: a single account getting compromised or exposed on its own. Point it at the provider itself and it changes close to nothing.
Two providers is where records actually part company. One side knows your real-name addresses and where they deliver. The other side knows your anonymous aliases and where they deliver. Then watch the gain evaporate the moment both sides deliver into one inbox. Banking mail and forum mail in a single mailbox is both your worlds at once, each message labelled by the alias it arrived on, open to whoever holds that inbox: the inbox provider, anyone who breaks into the account, anyone with the legal power to compel it.
The full version, as a checklist:
- Anonymous aliases live at one provider, real-name addresses at another. At minimum, a separate account run as a genuinely separate identity.
- The anonymous aliases deliver to their own inbox, never the inbox your bank writes to.
- The anonymous account gets paid for without your name on it: a free tier, or cash or crypto where the provider offers either.
- Logins stay apart as a habit, not an afterthought. Log lifetimes are short: SimpleLogin deletes server logs after 7 days, addy.io keeps logs for 3 days, Proton keeps no permanent IP logs by default. While logs exist, though, two accounts opened from the same home connection can sit side by side in them. The thread landed on the same condition from the user's chair: the split only pays if the anonymous account never gets a login from your real IP.
- Your own domain gets handled on purpose. Aliases on a domain registered in your name stitch the worlds back together wherever the domain or its registration details point back to you. Keep the anonymous side on shared provider domains, among other users on the same shared domains, or on a domain with no public route back to you. The trade-offs sit in the guide to email aliases on a custom domain.
Self-hosting an open source alias service is the limiting case. The map leaves every third party's hands. Your server keeps it instead. Your patching, your backups, your bad day. Most people trade up in risk on that swap. The aim is fewer parties able to make the join, not more moving parts.
Decide by asking who must never make the link
If your worries stop at spam, marketing profiling and the routine breaches that hit sites you use, one account does the job comfortably. Sites cannot see across it. A leaked alias dies alone. And the provider holding the map holds nothing your bank, your shops and your forums do not already hold about you on their own systems. Honestly, most people can stop there. The poster in the October 2026 thread put their real-name address, a random-name address and their Hide My Email aliases into one Proton account, wrote that linking them posed no risk for their purposes, and reasoned their way there soundly: anything genuinely risky lived in a separate identity somewhere else. If that is your shape too, consolidate.
Where the content itself would cost you if your name landed on it, legal or not, awkward at work or at home, the provider moves inside the threat model and one account is the wrong shape. Split the provider. Split the destination inbox. Keep the anonymous side's payments and logins away from your name. The second account costs an afternoon to set up. Retrofitting separation onto two years of mixed history costs far more, and some of it cannot be bought back.
Where the threat model includes a state, stop shopping for email layouts. Aliases will not carry that weight, and the staff member in the original thread said it in a single line: if lawful interception by the provider is part of your threat model, no email account is suitable. Aliases govern what websites can learn about you. They were never built to hide one half of an account from the company running the account. Work out which job you are hiring them for, keep your real address out of general circulation by following how to hide your email address online, and settle the simpler question with whether you need a second email address. Then act on what it tells you, while the alias that leaked is still the only thing you have to kill.
Top comments (0)