← Articles|Xenos Fit

May 2026

Email Aliases for Privacy and Security

Most people have one email address. They've had it for years. It's on their resume, their bank account, their family group thread. And it's also on the mailing list of every online store, app, and service they've ever signed up for, including ones they've long since forgotten about. It often includes their first and last name and it may include something about their date of birth.

This presents a privacy and security problem. Your email address is one of the most stable identifiers you have. Unlike a password, which you can change, or a credit card number, which expires, a real email address tends to follow a person for decades. When a company you've trusted is breached (and eventually many of them are), that address gets traded and sold, becoming part of a profile about you that accumulates detail over time. More fundamentally, anyone who has your email address can reach you unsolicited and can tie your activity across services.

Using multiple email addresses or aliases makes it harder to chain together information about you.

What an alias actually is

To borrow a term from the world of espionage, an email alias is like a “cut-out”: an intermediary that connects two parties. Using a cut-out is a pro-active, operational hygiene measure. You put one in place just in case. Once a compromise has occurred, it's too late.

You give out an email alias, and messages sent to it arrive in your real inbox. If a service starts spamming you, or if you suspect your address has been sold, you disable that alias. The messages stop. Your real address is never exposed.

The more disciplined version of this practice is one alias per service: a unique address for every account you create. This approach has two significant benefits beyond spam control. First, if you receive a message claiming to be from a company but sent to the wrong alias, you know immediately it's a phishing attempt. Second, when a breach occurs, you know exactly which service was the source, because only one alias maps to that company.

None of this requires technical sophistication. Several services make it straightforward.

The options

If you're an Apple user with an iCloud+ subscription, which includes any paid iCloud storage tier, you already have access to Hide My Email. It generates random aliases on demand, directly within Safari, iOS, and macOS, and manages them from your iCloud settings. For people already in the Apple ecosystem, this is often the lowest-friction starting point.

Proton Mail, the Swiss-based encrypted email provider, includes robust alias functionality as part of its paid plans. If you're using Proton Mail as your primary email provider for its privacy properties, the aliasing capability is a natural extension of the same posture. Proton also owns SimpleLogin, which operates as a standalone service for users who want dedicated alias management regardless of which email provider they use. SimpleLogin has a free tier, is open-source, and works with any existing email address.

DuckDuckGo Email Protection takes a different approach: it gives you a permanent @duck.com forwarding address and lets you generate unique aliases on demand, forwarding everything to whatever email provider you already use. It strips tracking pixels from forwarded messages as part of the service. It's free, requires no switching costs, and works without changing anything about how you currently receive email.

Firefox Relay, from Mozilla, operates on similar principles, forwarding aliases that land in your existing inbox. It has a free tier limited to a small number of aliases and a paid tier with more. Like DuckDuckGo's offering, it's designed to layer onto whatever email setup you already have.

For users who want the most control, addy.io (formerly AnonAddy) is an open-source service with a generous free tier and support for custom domains, meaning your aliases can come from a domain you own rather than one belonging to the alias provider.

Can you send from an alias, or only receive?

This is where the services diverge, and it's worth understanding before you choose one.

Receiving works universally across all of the above. Sending is a different matter.

Apple Hide My Email supports both. Within Apple Mail, you can compose a new message and select a Hide My Email address as the sender, and replies go back out from the same alias. A constraint: initiating a new message from a Hide My Email address is limited to a single recipient. And initiating an email thread from a Hide My Email address seemed so awkward to me when I tried it as to be impractical, if not impossible. But replying is easy.

Proton Mail and SimpleLogin also support both directions fully. Replies to forwarded messages go out from the alias, and you can initiate new messages from one as well. It's much more straightforward to initiate emails from a Proton/SimpleLogin email alias than an Apple Hide My Email alias, although certainly not as simple as sending an email with a non-alias account.

addy.io supports sending and replying as well, on paid plans.

DuckDuckGo Email Protection is receive-and-forward only. For signing up to services and receiving communications, this is sufficient. For any correspondence where you'd want the alias to appear as the sender, it falls short.

Firefox Relay is receive-and-forward only, at the free level.

Choosing the right tool for the situation

Not every alias needs to support two-way correspondence. Thinking through how you may want to use an email alias can save trouble later.

Some relationships are one-directional by design. A retail site offering a discount code for your email address, a newsletter, a sweepstakes entry, an app that just needs to verify you're a person: the site sends you things and you never need to send back. DuckDuckGo or Firefox Relay handle these cases well and require the least setup. If you're browsing with Safari, it's easy to create a new Hide My Email alias on demand for a case like this, in just a few seconds.

Other relationships look transactional at first but have a reasonable chance of requiring correspondence later. A landlord or property manager. A freelance client. A healthcare portal. An insurance company. A subscription service with a billing department. Any organization you might eventually need to write a formal complaint to. For these, a receive-only alias creates a problem precisely when you most need things to work smoothly: you're either replying from your real address or explaining an awkward situation to a support agent.

The subtler cases are services that feel low-stakes at signup and then evolve. You register for a software product with what feels like a throwaway address, and eighteen months later their only support channel is email. The decision you made at signup now has consequences you didn't anticipate.

A practical approach: use receive-only aliases for anything clearly transactional and low-stakes, and use a send-capable alias as your default for anything that resembles a real account or ongoing relationship. Nobody gets this perfectly right every time. The goal is a sensible default, not a perfect system.

The case for doing this now

Using email aliases might seem extreme, something only privacy enthusiasts and conspiracy theory-minded folks would do. But I'd argue that everyone should use them.

The sensitivity of personal data isn't fixed. Information that seemed innocuous to collect a few years ago — an email address, a fitness goal, a general location — is increasingly valuable as the tools available to analyze and correlate it become more capable. The companies that hold your data today will face more sophisticated threats tomorrow than the ones they face now. Data minimization is more defensible than data security: it's difficult to breach what doesn't exist.

Using a separate email address for every service you sign up for costs nothing but a few seconds at signup. It reduces your exposure, gives a way to know when something has gone wrong, and means your real address stays yours, less exposed to spam and cyber threats.

At Xenos Fit, we don't need to know our users' identity, and we prefer not holding information that can be used to identify them. Actively encouraging the use of alias email addresses makes us less attractive as a target for “bad actors.”