I've maintained very strict control over email for over a decade. When I purchased jonpurdy.com in 2006, I did so with the intent of having a lifelong domain and email address. But the longer one uses an email address, the more spam and unwanted email tends to collect.
A couple of years afterwards, I heard about plus-aliasing. This is when you take
[email protected] and add a plus and string after the username, such as
[email protected]. This email address is different than
[email protected], but providers such as GMail treat it the same. This allows for easier filtering of incoming emails. Instead of trying to filter by incoming address or domain and trying to catch all the possible combinations, you filter by that alias.
You can completely avoid email from hitting your inbox by creating a filter for
[email protected] that puts it into a Service folder. Here's a sample of mine:
But there's a disadvantage of plus-aliasing: it's possible to derive your actual email address by removing the plus symbol and everything after it. If someone really wanted to get your address from
[email protected], they could remove
+service from the address.
There is where owning your own domain comes in. Since I control my domain, instead of using
[email protected], I started creating email aliases, like
[email protected]. This has all the benefits of plus-aliasing, but there's no way for services to derive my main email address from that. If services want to reach me, they must use the specific unique address they are provided with.
If you unsubscribe from a service's mailing list, and they still email you months or years down the road (because you didn't unsubscribe from THAT PARTICULAR list), you can simply delete the alias! (With plus-aliasing, you can set up rules to delete any incoming mail to that address, which is a bit more complicated.)
You can also determine if a company has shared your email address with other companies or services. If you start receiving emails from Company2 at your
[email protected] alias, it's clear that Company1 shared your email with Company2. As an example, I made a donation via Aka Raisin, a non-profit fundraising platform, once back in 2017. For the next few months, my
[email protected] started getting emails from various hospitals and charities. It was clear that my unique address was shared with other organizations. Deleting the alias solved the problem (and there was no need to set up incoming rules like with plus-aliasing).
There's another benefit to creating aliases: you know when a company has leaked your email address or has been hacked. Back in 2013, I started getting a bunch of of random spam email to
[email protected]. Sure enough, a few days later Adobe announced that they'd been hacked and 2.8 million addresses were compromised (it ended up being
38 million 150 million in the end). If I didn't have an alias for them, I'd still be receiving spam to my primary email address to this day (see the Mailroute incoming log for my domain):
When a company gets hacked, it's easy to prevent spammers from getting into your inbox. Simply delete the alias! Then create a new alias for that service, change your email address on your account, and you're set! Until they get hacked again, like Adobe in 2019... then just delete the alias, create a new one, and move on. (That address still gets attempted spam as well...)
An interesting situation occurred in 2012. I started getting spam to my
[email protected] alias. A couple of weeks later, Dropbox announced a security incident that caused credentials to be leaked. I had already changed my account email after the first spam email just to be safe. It came to light in 2016 that they buried the extent of the attack and 68 million accounts had been compromised.
(With plus-aliasing, you know when the address has been hacked, but hackers can easily derive your primary email address and send spam or phishing emails to that.)
There's another benefit of domain-based email aliasing: ability to respond via that email address. If I needed to get in touch with Adobe but didn't trust them with my primary email (why would I after two hacks?), I could easily send an email from [email protected] to them.
Disposable email services
I love the control that email aliasing gives me but this setup isn't simple. Most non-technical people I've spoken to about this are very interested in what it is and how it's done, but lose interest once I explain how to set it up. Even for technical people, it's work to create the alias, ensure it works, and create folders and rules for filtering. In my case, it's worth it to use with those companies and services that I use on a regular basis.
But if I just want to try a product out or get access to a free service: I head over to Mailinator.com, generate a random email address, and use that.
But this has problems too: a lot of services don't like disposable email and don't let you register with them. Even though Mailinator has dozens or hundreds of alternate domains (so
[email protected] works the same as
[email protected] and
[email protected]), people make lists that contain those domains so site admins can block them from being used. It's unfortunate that forum spammers and WordPress comment spammers use these free services to generate accounts since legitimate users who don't want to provide their email address end up getting blocked as well.
Mailinator has a way around these block lists though: buy your own throwaway domain and point the MX records (mail server records) to Mailinator! You get the benefits of Mailinator but don't get blocked by sites that block the list of Mailinator domains. I have done this and it works really well, but it's non-zero work to buy a domain for this, and I certainly wouldn't expect non-technical users to do this. (There are also a small subset of sites that check in realtime to see if each domain points to Mailinator's servers. But those are rare from what I've seen.)
Of course, Mailinator isn't necessarily a great tool to use if you actually need to preserve emails. Since it's anonymous and anyone can use any account, emails are deleted after a certain time. So it's great for trials that you probably won't pay for, or to get access to an article that is sent out via email only, but not great for long-term paid subscriptions services.
It's also not private by design; anyone can see the emails sent to any account. I generate long random addresses (20 characters random strings) to avoid collisions to get around this.
Hide My Email for Sign in with Apple
I don't use this myself, but I thought I'd mention it because of how easy it is to use for the very limited use cases.
As described here, when you sign up for a new service, Apple generates a unique ID (
[email protected]) and forwards those emails to your actual Apple ID (
[email protected]). The service you use only knows about the unique alias, so if they get hacked or send unwanted email, you can just delete the alias and Apple will stop forwarding emails to your actual address.
However, this is extremely limited: this only works on websites that are associated with an iOS app, and it's for Apple devices only. Less than 5% of all of the products and services I use are an iOS app or associated website.
After drafting this post, I created a list of my requirements and whether each technique solves each of them. I didn't add Mailinator or the Sign in with Apple to the comparison because they can't be used as stand-alone solutions to my email handling problem.
|Filter incoming email based on the service that sent it
|Easily stop receiving emails from services if they don't respect my unsubscribe requests
|Detect when a service has shared my email with another company or service
|Detect when a service has been hacked
|Prevent hackers with stolen customer email lists from deriving my primary email
|Easy to implement and use
For those of you who control your email flow in a similiar manner, are there any tools or services that I am missing? Are there any requirements or features that I'm missing out on?
If this sort of content is interesting to you, feel free to follow me on Twitter: @jonpurdy.