Email Aliases Are Not A Security Measure

People often manufacture a false sense of security by believing they have complete control and understanding of the many facets of their own security posture. I’m talking about statements like, “My password is strong because nobody knows my cat’s name,” or “I’m comfortable storing unencrypted medical records in the cloud because my data isn’t that interesting.” It’s easy to convince yourself that you’re secure because the precautions you’ve taken have worked so far, and hey - if nobody hacked you so far it must be because the guardrails you put in place are that good. This way of thinking can lead to mistakes and applying security measures that are not security measures at all.

One such idea, that I would also classify as a fallacy, is that using email aliases in lieu of your primary email address somehow magically protects your accounts. Before you start slamming the desk with your fist yelling at me that “IT PROTECTS YOUR PRIVACY!”, I want to draw a very important distinction - I am not talking about protecting your personal privacy but rather the belief that having a secret email alias somehow protects your accounts from malicious access.

I have nothing against the concept of aliases at its core, but I have a lot to say about it being treated as some kind of security barrier against the bad guys and gals busting into your private forum accounts. Email aliases are a privacy and not a security measure.

Before we do a short analysis of different alias variants and misconceptions about them, let’s do a refresher on what one needs to be thinking when assessing their security and privacy posture, and what better way to do that than referring to the five steps of Operations Security (OPSEC) as a good starting point:

1. Identification of critical information.
2. Analysis of threats.
3. Analysis of vulnerabilities.
4. Assessment of risks.
5. Application of appropriate countermeasures.

It all boils down to the fact that all security measures are only as good as your understanding of what’s going to be playing against them. I would wager that the vast majority of the population doesn’t think about these at all. And a large segment of population doesn’t really need to - they set a password for their account, use two-factor authentication, and are on their merry way. And that’s fine. But there is a subset that wants to take their privacy and security to the next level, and for that they start looking at ways in which they can enhance their posture.

That’s where the danger of “security cosplay” comes in. I call it that because these are often practices that will make you feel like you’re doing something for security when you really don’t. Someone reads a Reddit post about how to be secure without really thinking through what they’re trying to protect and why. The first advice, almost universally, will be something like “Duh! Switch to Linux!” And they switch to Linux, because the “experts” said so, ignoring the fact that Linux itself has so many security issues that sometimes relying on it for a truly secure OS and properly hardening it might feel like putting bandaids on a broken dam. And I am saying this as someone that actively uses Linux and wants it to be successful on the desktop.

Popularized simple ideas spread without fully fleshing out the actual threats that users will be guarded against and become folklore without understanding the “why”.

This entire blog post started from a conversation I had where I had to debate whether using email aliases for a bank account is a more secure approach than using the same email address everywhere. Spoiler alert - it’s not the aliases you need to worry about.

“But Den - privacy is security” - to a large extent, yes. If you have more privacy, you also gain greater security, but you should not conflate the two. Secure doesn’t mean private, and private doesn’t mean secure. The meta-point is - do not get to thinking that just because you have an email alias or an address that nobody (allegedly) knows about for some online account you’re now “secure.”

There are a few other things you need to keep in mind:

• First, my stance on this is that all email addresses should be treated as if they are public information. All efforts to have “secret” emails are ultimately not as effective as you applying proper protection measures to your email inbox.
• Second, everybody’s privacy and security needs are different. What works for me might not be applicable for you, and what practices I use might not be at all relevant to your situation. My threat model is not your threat model.
• Third, and last - privacy and security are a spectrum. The most secure way to deal with any online accounts is to not have online accounts, but that’s not really a viable option. Again - consider your threat model.

Threat model, threat model, threat model. Did I mention that you should think about your threat model?

And by the way, speaking of the threat model, when it comes to online accounts and emails, mine, in an overly-simplified format, includes mitigations for risk of:

• Personal information exposure through compromise of the email inbox. If someone can get into my email account, it’s effectively game over - they can reset passwords, initiate correspondence on my behalf, see past transactions and purchases, and so on. This provides enough information to do other malicious things. This is ultimately a very, very bad thing that should not happen.
• Malware. I want to minimize the likelihood that I end up with an infected machine because of my email receiving content sent by unscrupulous individuals.
• Online activity tracking. I don’t want random people online to be able to build a comprehensive profile on me and my family based on my email address. That means that I want to not have breadcrumbs on every online asset pointing to my identity.
• “Naive” personal data exposure. Someone looking at [email protected] can easily tell that this is me because I have a den.dev domain. They can open this blog and see clearly that all emails under this domain are somehow associated with a guy named “Den Delimarsky”, even if I registered as “Jack L. Woods”. Similarly, if I have an email like [email protected], one can infer that it also belongs to me (or “Dende Limarsky”, but I think Google will correct that). I don’t want that to be the case for your run-of-the-mill email scraper.
• Spam and phishing emails. I don’t want more spam landing in my inbox than what is already there.

What I am not trying to protect against is someone knowing my email, because ultimately that information should not grant a malicious actor any access on its own.

With that out of the way, let’s talk about email aliases.

The many ways to use aliases #

Aliases are a not-so-new feature implemented by some email providers to “mask” the primary email address or give people the option to create segmentation in their inbox - use some aliases for shopping, others for your bank, and so on. Apple offers that (and even goes a step further with Hide My Email). Outlook.com offers that. Google Workspace offers that. Aliasing is a good privacy mechanism that I think more people should be aware of and use.

There are several ways to configure aliases, with increasing degrees of privacy that they afford.

Plus addressing #

This is the most basic mechanism of creating email aliases. Let’s say I sign up for a [email protected] email address with an email provider of choice. This is my primary email. Then, because I don’t want to give my personal email to every single vendor that I use, I can create [email protected], or [email protected]. This is called plus addressing because I, quite literally, use a plus (+) in my email address to extend my primary email for different tasks. The email provider, when receiving emails to this address, will strip everything after the plus and know where to deliver the message.

This is a good start because I can easily set up mailbox filters, such as moving all [email protected] emails to the online-shopping folder. This has another positive side-effect in that I can easily identify who sells my email address without my consent. For example, if I get an email addressed to [email protected] from a mortgage lender, and I only used this email address with a web store that sold tropical fruit, I now know where the mortgage lender got their email from.

Plus addressing is a good mechanism for email sorting and some email misuse detection, but because it’s such a well-known technique at this point, it doesn’t take a genius to figure out that [email protected] is actually [email protected], and a lot of online marketers and other individuals that are interested in collecting email addresses caught on. You will see a few services even go as far as strip out everything after the plus because, hey, why bother with the details when they already know who you are.

If you use plus addressing with your main email account, it’s trivial to link all accounts to you, shall one of them leak. Not exactly the paragon of privacy-preserving techniques.

Custom email handles for the same mailbox #

The next level of aliasing is setting up custom email handles for an existing email address. Building on the [email protected] email, I may want to have [email protected] to use with all my utilities. I still only have one mailbox, but there are several names associated with it. This can be done either with the default email provider domain (example.com) or you can provide your own domain (e.g., like this website - den.dev). This gives you an opportunity to segment your inbound and outbound email, just like you could with plus addressing, and it’s still concentrated within the same “meta-account” - your mailbox.

This technique affords a higher level of privacy because it’s not immediately obvious that [email protected] is owned by the same person as [email protected], and it will require that the malicious actor or marketer to have access to other metadata to link the account to you, such as your name, phone number, and physical address from wherever you used that email. This is, surprisingly, not that hard to accomplish. Given how many data breaches there are that leak everything about you, someone that’s really out to get a graph of your online identities can quickly map [email protected] used with my real name inside my cellphone provider’s leaked database with [email protected] inside the leaked healthcare provider’s data.

Using a custom domain that has nothing to do with you and is generic enough can also help ensure that the email address is not instantly linkable to you personally.

Distribution lists #

This is effectively the previous version with extra steps. Instead of creating an alias, you are creating a distribution group that has one or more emails. It’s a convenient way to have a shared email with your spouse, for example, but in terms of privacy it’s as good as having a standard alias.

The security posture with all these options #

In all of the outlined scenarios, I talked about the privacy implications on each but not necessarily the security. That is because aliases don’t really afford security. Let’s get back to my threat model that I outlined earlier and see what I am protecting against:

So, clearly aliases do a few good things for privacy but they’re not exactly the security safeguard one would think they would be. That’s because they are not. On that last point, though, one might argue that aliases help you better filter out mail (remember my tropical fruit example from earlier) and therefore afford you better security. That’s all good, until you learn that a lot of modern email providers started helpfully resolving aliases on the same mailbox to something like “You”:

Was this sent to an alias or your main account? Clicking on “You” will show my main account, even if the email was actually sent to the alias address. Not exactly helpful to fight phishing or spam by To line alone. A lot of the popular email clients will also resolve the aliased email to your name and primary email account.

This is a bit better with distribution groups because you get to see the name of the group on the email, but not every email provider has this feature and you still have to manually look at the To line and spend some cycles thinking whether this email was intended for you or not. There are better heuristics to see if something is spam or phishing - not the To line.

What about separate mailboxes? #

Now we’re getting to an interesting twist to the alias debacle. What if instead of aliasing the same email, you create multiple mailboxes, ideally across different providers? One for your bank, another for social media, a third one for friends and families, and so on.

What this achieves is segregation of identities. That’s actually a great approach to protect against “winner take all” mailbox compromise. If someone breaks into your mailbox that you use for social media, they can’t use it to reset your bank account. Similarly, if someone access your bank account mailbox, they can’t use that to reset your password to a social media site and start posting as you or peek into your DMs.

Maintaining separate mailboxes is inconvenient, though. Can I just forward my mails from all of them to some central, shared mailbox?

Ah, that’s something that I’ve seen someone actually do. That action negates the benefits of segregated identities. If your threat model includes protection against mailbox compromise, if someone breaks into the “central” mailbox they can peek into, say, archived mail to see that you are receiving bank statements. Those statement emails often will have a header at the bottom, telling the real email this was sent to (even if you thought you kept it secret):

Peeking into the message headers is also very likely to reveal the email this was forwarded from. At that point, the malicious actor can reset your bank password (assuming they also have some other personal information about you, which is, let’s be real - likely), and get the password reset in the central mailbox because you were forwarding your emails to it. Well that’s inconvenient.

Where do we go from here #

Alright, so where I am going with this is that my biggest risk and very likely your biggest risk when operating with email is mailbox compromise.

Instead of trying to keep the email address secret, the better approach is ensuring that my mailbox cannot be compromised, even if the email address is public. What that means in practice is that:

1. I have a strong password. Don’t make it easy for script kiddies using dictionary attacks.
2. Even better, I have gone passwordless. Outlook supports that, for example. They can’t guess my password if I don’t have a password and can only sign in via the an authenticator app, passkeys, or physical security keys (like YubiKey).
3. I always use two-factor authentication (2FA). This builds on the passwordless point, but no account should grant access on password alone if passwords are required. Authenticator apps, passkeys, and physical security keys are reliable and robust methods for 2FA. For the love of everything, never use SMS 2FA (wow, I wrote about that more than six years ago) unless there are absolutely no other options.
4. I never log in on untrusted devices or devices I do not have full control of. Ever. In practice, that means that I never browse my email on work computers, library computers, friends’ computers, or any other device that I do not own.
5. I archive the mailbox regularly. Assuming there is ever a compromise, my goal is to minimize damage. That means that any communications that are historically archived in the mailbox need to make their way out to my own cold storage. Doing it once a quarter or even once in six months is sufficient.
6. I don’t open untrusted attachments. Sending me a binary, script, executable, or an unknown archive? The email automatically goes to trash. No exceptions.
7. I don’t render images or scripts. Less tracking, but also less likelihood of anything loading on its own.

See, way better security through actual security measures rather than theater. Security through obscurity is a viable strategy when applied as one of the layers to your overall posture, but when it comes to emails - you have bigger fish to fry.

Assess your threat model, figure out what you’re trying to protect from, and then apply proper countermeasures. Don’t blindly follow recommended practices because someone shared them in a Reddit post (or on a blog like this).