Stopping Spam at the Gate: Why I Built is-burner-email

I was doing some routine database cleanup for one of my side projects a few months ago, and honestly, it was depressing. For every real person signing up, I had three accounts sitting there with domains like @10minutemail.com or @trashmail.net.

These "burner" emails are the worst. They bloat the database, trash your analytics, and make sending out a simple project update feel like screaming into the void. It's one of those minor annoyances that quietly morphs into a massive headache when you just want to know how many actual human beings are using your app.

I needed a way to stop this at the sign-up gate. So, I built a tiny open-source package called is-burner-email to deal with it.

The Problem with Existing Solutions

My first instinct wasn't to write custom code. I just wanted to npm install something or hook into an API and call it a day. But the existing options out there were pretty disappointing.

• Paid API gateways are totally overkill. I’m a home-server guy building side projects in my free time, not an enterprise SaaS company. Paying a monthly subscription just to check a string against a blocklist? No thanks.
• Dependency hell is real. A lot of the open-source libraries I checked out were pulling in half a dozen other packages just to parse a string or make a basic HTTP request.
• Stale data is everywhere. Most of the GitHub repos I found haven't had a commit in years. Burner email providers change their domains constantly, so an outdated list is basically useless.

I just wanted something fast, dumb, and completely self-contained.

Enter is-burner-email

You can grab the code over on GitHub: kristijandraca/is-burner-email.

The whole point of this project is extreme minimalism. I wanted a quick tool to drop into my auth flows without having to think about it. Here’s the rundown:

• Zero dependencies: Whether you use pip, composer, or go get, you are installing just the checker. No HTTP clients, no weird regex libraries.
• Stupidly fast: Since the domain lists are hardcoded and bundled locally at build time, checking an email takes less than a millisecond. No network calls.
• CLI included: Every language package ships with a simple burner <email> CLI tool if you just want to check a domain directly from your terminal.

How to Use It

Dropping this into your codebase is easy. Just run the email through the checker right before you hit your database.

If you are using JavaScript/TypeScript, grab the package:

npm install is-burner-email

Also there is support for Python, Go, PHP, C#/.NET, and Kotlin/JVM.

Then toss it into your route. Here’s what it looks like in a basic Express setup:

import { isBurnerEmail } from 'is-burner-email';

app.post('/register', (req, res) => {
    const { email, password } = req.body;

    // Catch the disposable domains right away
    if (isBurnerEmail(email)) {
        return res.status(400).json({ 
            error: "Please use a real email address." 
        });
    }

    // ... create the user normally ...
});

The Trade-offs: Speed vs. Freshness

I had to make a choice here: do I query a live database, or do I bundle a massive static list of domains directly into the package?

I went with the static list. Why? Because I refuse to add latency to a sign-up flow. If my app has to make a network request to some random API just to validate an email, that's a new point of failure. If that API goes down, my users get stuck.

The obvious downside is that a static list goes stale. Burner domains are like whack-a-mole. To fix this, I wired up a cron job using GitHub Actions. Every week, it automatically pulls from the big community blocklists, aggregates the data, and opens a Pull Request.

But I don't let it auto-publish. A human (me) reviews the diff and merges it before cutting a patch release. You get the safety of reviewed code, the speed of local checks, and all you have to do is bump the package version whenever you update your dependencies. For my own sanity, that’s a trade-off I'll take any day.

Conclusion.

We shouldn't have to pull out a credit card or bloat our package managers just to block fake signups. is-burner-email is my attempt at a dead-simple, universally available fix to keep your database clean and your metrics honest. Whether you are spinning up a quick Express server or writing a massive C# backend, you can drop this right in.

If you end up tossing it into one of your projects, let me know! And definitely hit me with a pull request if you spot some obscure new trash-mail domain slipping through the cracks. Happy tinkering!