burner-email-providers is a domain list for filtering throwaway signups

Why a list of domains is worth maintaining

The reason for the project is stated by the author in a few sentences. Throw away email addresses are great for single use signups where you would like the content but would rather not give up your email. The author is okay with people using burner addresses to get his free content, with one condition, that he needs to be able to filter them out of his list so that they do not drive up bounces and hurt deliverability. That framing is what separates this from the usual disposable email list, because the purpose is not to block people but to keep a mailing list healthy. It is also the reason the project asks for pull requests with any new providers you find, since the list is only useful while it is current, and a domain that has been dead for two years in the list is noise that makes the matching slower and less trusted.

The API section, split by what they cost

The list is organised by what a provider gives you rather than by provider, which is the useful ordering for an adopter. Under APIs there is a Free group with Disposable, Disposable Email Detector, Firefox Relay and Verifier, and then a Services section with a Free tier group, which currently lists Firefox Relay. The same project appears in both groups, which makes sense because the private relay is an API as well as a hosted service, and the distinction that matters to a developer is whether you can call it yourself or whether you have to sign up for an account and use their web interface. The Verifier entry is the one to look at first if you are evaluating, because a verification endpoint that tells you whether an address is disposable is a different integration from a blocklist, and it means you can check an address at signup time rather than cleaning the list afterwards.

Client libraries in five languages

The Libraries section is the reason to use this repository rather than copying the text file. There is Burnex for Elixir, go-burner-email-providers for Go, burner-email-providers for Node, a validation bundle for Symfony with a burneremail section, and Burner4s for Scala. That is a useful set of choices, because they cover the stacks where a signup form is most likely to live, and a maintained package per language means the list is updated in one place and pulled down rather than vendored into five repositories. The PHP entry is the one to note, because it arrives as a validation bundle rather than as a standalone library, so it fits into a form validation stack rather than into a service of your own, and the list is a string of domains rather than a service with a rate limit or an uptime, which is the trade you make for having no third party in the request path.

Hosting your own, and the one related tool

There is a Host your own section with a Docker image, which covers the case where you want an instance rather than a list, and a Related links section with otm-detector, described as trying to find new burner email provider domains by checking MX records. That is the interesting complement to the list, because a list is behind by definition and a checker of MX records can find a provider nobody has added yet. The two together are a reasonable strategy, a list for the known case and a resolver for the unknown one, and the fact that the list itself is pruned is the same idea applied to the other direction. The README also asks for pull requests with new providers, so the maintenance loop is a contribution from someone who noticed a domain in a signup form.

The package is one text file and a prune script

The package metadata is unusually small, and it explains how the data is distributed. The package is private and named burner-email-providers, with a version of 1.0.0-RC, and the files field contains exactly one entry, emails.txt, so the entire payload is a text file of domains. There is one script, prune, which runs node prune/prune.js, and the single runtime dependency is batch-promises-with-delay, which is what a pruning script that has to check many hosts gently would use. The repository root carries the same two data files, emails.txt and test.txt, along with the prune/ directory, a composer.json, a .vscode/ directory and the readme. The presence of a separate test file suggests the prune script is checked against known addresses before and after a run, which is a small piece of engineering that a list of strings would not usually get.

How a domain list is used, and where it is not enough

The realistic use is a check at signup or a cleanup of an existing list, and the limitation is that a domain list is a heuristic about the domain, not about the person. Two people share a mail server, so a domain that hosts a disposable service may also host a real company, and a real person behind a company mail domain can be caught by an aggressive rule. The other limitation is the direction of travel, because every provider that starts is a provider that is not on the list, and the list is only ever as current as its last commit. The prune script exists precisely because the opposite failure, a list that grows and never shrinks, is what makes a list useless, since a stale domain in a blocklist rejects a real signup. The last thing to check before you use it in a production signup flow is the licence, since the repository is recorded as MIT while the package.json for the npm payload declares it unlicensed, and the two statements in the same project should be reconciled before you ship something that depends on it.

Editorial conclusion

burner-email-providers is worth depending on if you run a signup flow and you care about the addresses that come back, because a maintained domain list with an existing library for your language is cheaper and more current than a regex you write once, and the pruning script means the list does not decay into a wall of dead domains. It is the wrong tool if you need to decide whether a specific address is real, because a domain list is a heuristic, and it is the wrong tool if you need to detect disposable providers that are not on the list, which is the case the related MX record project is aimed at. Before you wire it into a signup flow, read the list format and the pruning behaviour, and check the licence, since the repository metadata and the package metadata name different licences.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. wesbos/burner-email-providers on GitHub