A few days ago I tried to sign up for a public open-data service (the ECMWF, if you care) using a Proton Mail alias, and the form rejected my address as “potential spam”. My frustration was mixed with a bit of guilt: in 2018 I published Burnex, an Elixir package that compared emails against a large list of known burner domains, temporary inboxes like yopmail.fr that exist to receive a confirmation link and disappear. The library itself was relying on the fairly popular wesbos/burner-email-providers list.

At the time, I was working on a collaborative fact-checking platform where account authenticity mattered, and we needed some confidence that users were not fake or batch-generated. A domain blocklist felt like a cheap heuristic for a broader trust problem.

I may be late to the party, but let me put it clearly: I no longer recommend systematically blocking burner domains at signup.

TLDR;

If you are deciding signup policy today, do not automatically reject users for using privacy email services. Distinguish between public shared inboxes and personal aliases, and only block the former. The person behind an alias is more likely protecting themselves than trying to scam you, and the spammers have already moved on. If you maintain or consume a blocklist, consider splitting the categories and encourage good practices in your documentation.

Burners and aliases are not the same thing

A distinction that we often forget when it comes to email blocklists: a classic burner email is a public, short-lived inbox anyone can access, useful for clicking a verification link once and walking away. An email alias is the opposite: a permanent forwarding address tied to your account, that you control, can disable, and can trace back to a specific signup when your password appears in a breach.

Nowadays, tools like Firefox Relay and Apple Hide My Email are mainstream products, not edge-case hacker tools. Mozilla markets Relay as a way to keep your identity private when signing up for new accounts, and Apple sells Hide My Email as a way to share an address without sharing your real one (though they may be overselling that promise).

Blocklists that treat alias providers like throwaway inboxes end up blocking people who are trying to protect themselves. That matters beyond signup friction: aliases limit cross-site tracking, reduce spam after breaches, and let you know exactly which service leaked your address when junk mail starts arriving at a forwarding address you gave only to them. We should want more people using aliases, not fewer.

Blocklists don’t stop determined abusers

Determined abusers have never been limited to blocklisted domains. Gmail’s + aliasing creates unlimited variations of the same inbox ([email protected], [email protected]), services like Emailnator can help you generate infinite variations of these throwaway Gmail addresses on demand. Custom domains cost a few dollars a year while looking indistinguishable from legitimate business email. Unlike your users, spammers have the means and the time to work around a domain blocklist. For them it is a small obstacle, not a wall.

Yes, blocklists still catch some low-effort automated signups. But the cost is asymmetric: a naive bot gets slowed down slightly, while a real user with a legit alias gets hard-rejected with no recourse. You are optimizing for the attacker who gives up easily and punishing the user who takes privacy seriously. The people blocklists were meant to stop were never really stopped; they just learned to use domains you trust.

Beyond blocklists, email verification in general (including confirmation links) should not be treated as proof that an account is real, unique, or trustworthy. It only proves that someone could receive an email at that address once.

There are still valid uses

Checking whether an email domain appears on a known-disposable list is still a reasonable signal to feed into a broader trust or risk score, to surface suspicious patterns across a batch of signups, or to ignore them in your marketing campaigns.

If I were to rebuild Burnex today, I would narrow its scope to genuinely public and shared inboxes (addresses like mailinator.com where anyone can receive your verification email) rather than conflating those with personal forwarding services that happen to use a non-mainstream domain:

# Public burner inbox, probably ok to block
Burnex.is_burner?("[email protected]")

# Personal alias, usually not ok to block
Burnex.is_alias?("[email protected]")

But the problem is not just how one library categorizes domains: the upstream list Burnex relied on (wesbos/burner-email-providers) is consumed as-is by signup validators, third-party packages, and APIs worldwide. Many integrators block every domain in emails.txt without curating it, so the list’s categorization choices have real downstream effects.

For those who come after

I have opened an issue to propose exactly that split in wesbos’ list: keep one file for public shared inboxes (yopmail.fr, mailinator.com, and similar) and add a second for personal alias and forwarding providers (passmail.net, anonaddy.me, mozmail.com, and the rest). Then update the README with recommendations for good practices.

Due to a lack of time and because I don’t use Burnex anymore in the products I maintain, I deprecated the project in early 2026. Since then, Klemen Sever offered to take over the project, and I have transferred ownership.