Recently, I’ve come across a stream of users registering accounts on websites I own using temporary or “disposable” email addresses. These addresses exist for reasons like protecting user privacy, preventing spam emails from cluttering real inboxes, increasing account security, and allowing users to bypass one-account-per-email restrictions. I’d like to explain my thoughts and my response to this issue here.

Part 1: The Balance of Power

When deciding on a response to the issue of disposable email addresses, the perspective of the user should not be forgotten. A balanced and well-reasoned approach is the goal.

The User’s Side

User Concern #1: Privacy

There’s nothing wrong with protecting your privacy. Online tracking is hard to avoid, and even if you give fake information to a website, by reusing an email address your profiles can be connected. Using a disposable email address for privacy is a good idea, and I think it should be considered more frequently.

User Concern #2: Spam

How many times have you received an email from a company you’re pretty sure you told to stop emailing you? How many times have you regretted signing up for marketing letters from online stores? With a temporary email address, those regrets disappear because you’ll never be notified about mail going to that inbox in the future. And if you really need to access your fake inbox, many services will let you go back and receive new mail.

User Concern #3: Security

If you’ve used a service like have i been pwned before, you may remember that the way to check if your password has been leaked is not by entering your at-risk password, but by entering your email address. One of the main reasons that reusing passwords is risky is because it’s coupled with email reuse: attackers don’t have the resources or the time to try every password with every email for any random account, so in non-targeted attacks they check known email and password combinations from previous data breaches. If you were to reuse a nice, long, random password on dozens of sites under different email addresses, the likelihood of your accounts getting breached should be comparable to if you used long, unique passwords with the same email address—unless there’s a reason to target you individually, that is.

The Operator’s Side

With all those legitimate concerns that a user may have regarding privacy and security, is it ethical to block the use of disposable email addresses? The answer isn’t very simple, and there are a few factors to consider on the operator’s side as well.

Operator Concern #1: The Law

If your website has a legal duty to verify the identity of all users, then a reasonable effort must be made to comply with the law. While having a real email address from every user may not be as important as having a real first and last name, it can help track down the rightful account owner if needed.

Operator Concern #2: The User

After considering the law, priority number 2 is the user. How will your chosen response hurt the user experience? How will it enhance the user experience? Finally, what incentives might it create?

With this consideration specifically, the hardest scenario is a social website. On the one hand, tracking users is important for serving ads and effective marketing. On the other hand, privacy-conscious audiences will try to evade your tracking. At the same time, bots may use fake email addresses, and their posts can impact public opinion and ruin the experience for real users. Personally, I would argue that social media sites should defer taking action against a user during the signup stage if a temporary email address is provided, and instead combine this information with other factors to weed out bots and trolls.

Operator Concern #3: The Business

This operator concern is fairly far down the list, and that may seem odd. But the reason is simple: lawyers are expensive, and users are fickle. Any action that causes legal troubles can be potentially catastrophic, and to quote The Social Network: “You don’t want to ruin it with ads because ads aren’t cool.” If users will leave entire platforms because of a couple ads, imagine how many users will be lost if you slow down the registration process. Are those lost users worth getting a real email address out of the users that stay? If requiring valid email addresses isn’t legally required for your organization, maybe it’s better to afford users the freedom to use disposable inboxes. A shorter list of real email addresses isn’t very helpful if your users aren’t happy and business isn’t growing.

Operator Concern #4: Emergency Scenarios

In the event of a data breach, an interruption of service, or any other emergency where communication with users is paramount, users who provided a temporary email address will be in the dark. I would say that this is a reason to check for legitimate email addresses. However, some users may not care at all if there’s an emergency with your website or their data. For these reasons, I argue that communication is key: be upfront and tell the user as early as possible that without a real email address, they might miss important information. If they still choose to provide a disposable email address, that’s their choice and you’ve done everything you can.

Operator Concern #5: Security and Spam

Depending on what your registration process requires, it’s entirely possible that anyone providing a disposable email address has something to hide. They may be looking to gain unauthorized access to your systems, or perhaps a way to avoid paying for a subscription after a free trial ends. It could also be the case that fully registered accounts in good standing on your site are valuable to someone, perhaps to use as bots or in a denial of service attack. These reasons alone are often strong enough to make valid email addresses a requirement.

Part 2: My decision

After going through this list, I decided that I would make a real effort to prevent the use of fake email addresses. The website I’m running is small, and it’s been the target of some attempted attacks in the past. It’s not running on a big server, and the service that’s offered is directly related to security. I don’t sell user data and I don’t send marketing emails, but there have been cases where I’ve needed to contact users urgently. For those reasons, I believe that blocking temporary email addresses protects my interests without asking for too much from my users.

On that note: there’s a good way for users to create a “real” email address that doesn’t compromise privacy and can still block spam. ProtonMail makes it easy to have an account with them as a secondary address: you can choose to receive notifications on a primary email address when a new email arrives. Oh, and their spam filter is pretty solid. (I’m not affiliated with ProtonMail)

Part 3: Enforcement

The solution is the fun part of this problem.

A google search for “Block disposable emails” returns a lot of paid API services that claim to have extensive lists of bad domains—no thanks. Right next to those paid services, however, are many public lists of domains used by these disposable email services. A blacklist based on these free lists is an enticing solution, but it’s not a complete answer. On StackOverflow, one user points out that new domains are constantly being registered by disposable email services, meaning that these lists of bad domains from 5+ years ago are probably worthless today.

If these lists are becoming less and less helpful every day, what options exist besides paying for an API that claims to track disposable email sites and block them as fast as possible? The answer is that we can create our own list.

One of the more controversial HTTP headers is Referer, because it can be leveraged for tracking. Whenever you click on a link, the browser (usually) sends the URL of the page that the link was on. If you type in a URL manually, there’s no header.

Disposable email services are almost exclusively offered through websites, and the emails received in them are displayed in the browser. My verification system involves sending a link to the new user via email (there’s no manual entry option), so when the user clicks the link in the browser, my website will see that the user came from a temporary email site. And while the domains that are used for the emails changes frequently, the domain that hosts the service rarely change.

So that’s how we build our own blacklist. Start with a fairly short list of sites that offer disposable emails, and add them to a Referer blacklist. Then, any time the verification script is run, check if the Referer is in that list. If it is, take whatever action you want against the user, and add the domain from the user’s email to your domain blacklist to prevent users from trying the same site in the future***. By creating a domain blacklist, you can prevent future users from using temporary addresses earlier in the registration process.

*** Implementation note: Automatically blacklisting domains in found in email addresses of uses who appear to be coming from a disposable email website is still a bad idea because it relies on user input, twice. The first time is when you let the user select the domain they want to blacklist. The second time is when they force your “protection” to take action by clicking the link while on a different website. A malicious actor could register using an email from a popular provider, like Gmail or iCloud. If they forward the verification email to a temporary address and click the verification link from a website on your blacklist, no more users would be able to use emails from the targeted provider. For this reason, I recommend an approval system where a log is created any time a bad Referer is detected. After manually reviewing domains in the log, an administrator can choose to blacklist the new domains.