Most signup guides brag about list size.
“110k domains.”
“300k domains.”
“Biggest blocklist on npm.”
Cool screenshot. Doesn’t mean the gate still works on Thursday.
Here’s the pattern I keep seeing. Someone copies a GitHub dump, wires disposable: true into validation, ships, and sleeps well. A week later a fresh yopmail clone walks straight through createUser. The list still looks huge. The product is already rotting.
Size is a vanity metric. Freshness is the product.
What actually breaks
Day one feels great. Mailinator dies. Guerrilla Mail dies. The dashboard looks clean. You paste a package list into Laravel or Node and call it done.
Then a burner provider spins up a cheap new domain. Or twenty. Your package hasn’t released in three months. The rule still “passes.” Trial seats fill with ghosts who never open the welcome mail. You start rewriting onboarding copy while the real leak is upstream.
Binary blocklists have a second failure mode. They feel productive until you nuke a real person on Apple Hide My Email or SimpleLogin. Those addresses look weird. They are not tempmail. If every unfamiliar domain is guilty, you trade fake signups for angry real ones.
You need both:
- A list that moves
- An allowlist for privacy relays on purpose
Most tutorials ship a static file for #1 and skip #2.
Size without motion is theater
I run Email Score. Signup-gate check: syntax, DNS/MX, disposable, then allow or block. Our disposable domain database is 216,254 domains.
I’m not leading with that number on purpose.
Competitors already market bigger piles. TempMailChecker talks 300k+. A bigger integer doesnt mean their list moved this week. It means they scraped more history.
The only number I care about after an Import is newly added. Everything else was already known.
What we run instead
Once a week we merge three maintainable, disposable-only feeds. Not free-provider lists. Not “every Gmail clone on earth.”
- disposable-email-domains (CC0) — community standard, bindings everywhere, boring in a good way
- fakefilter (BSD-3) — closer to realtime provider monitoring
- groundcat (MIT) — aggregates then MX-validates, plus an allowlist worth respecting
Normalize. Dedupe. Subtract privacy aliases hard: Apple Hide My Email, SimpleLogin, Firefox Relay, Duck aliases, addy.io.
Also refuse to treat Gmail, Yahoo, Outlook, and the usual free providers as disposable. That confusion shows up in bad lists more than people admit.
Then paste into the admin Import tab. One domain per line. Up to 50k per request. The DB skips what it already has.
A quiet week, real numbers
Last Import looked like this:
- Public merge after allowlist: about 16.5k domains
- Already in our DB: most of them
- Newly added: 560
- Errors: 0
The live disposable database is at 216,254 domains now.
The story isn’t “we have 216k.”
The story is 560 domains that would have been misses if wed frozen the list.
If your weekly add count is zero for a month, either burners got polite (they didn’t) or your sources went stale.
Operator checklist you can steal
You don’t need our product to copy the shape.
- Sync on a schedule. Weekly is fine. Daily if trial abuse is loud.
- Prefer permissive disposable-only feeds. Dedupe. Subtract privacy relays on purpose.
- Hard-block known burners. Soft-score the gray area: brand-new domains, catch-all MX, role addresses like info@.
- Fail open if the check times out. A dead validation path that takes signup down with it is worse than a delayed flag.
- Run the check before createUser. Cleaning the users table later is worse than never writing the junk.
- Keep confirmation email for ownership. Disposable detection is a courtesy filter, not proof of a human.
What we deliberately skip as the main gate: heavy SMTP RCPT probes. Slow. Often blocked. Catch-alls lie. Fine as an optional signal elsewhere. Bad as your only signup story.
Where Email Score fits
If you want the live piece without babysitting three GitHub remotes yourself, thats what we built.
One API call. Syntax, DNS/MX, disposable. Signup-shaped verdict. Not a bulk list-cleaner. Not a 0–100 vanity score.
Email Score · Validate emails before you send
Validate syntax, MX, and deliverability before you send. Email validation API built by Neural Evo.
https://emailscore.neuralevo.com
The 216,254-domain database is evidence at the bottom, not the headline. The weekly merge is the habit. If your disposable list hasn’t moved since you pasted it in, it isn’t protecting you. Its decorating the README.
If your list hasn’t moved in 30 days, what are you actually blocking?
Originally published on Medium: https://medium.com/@ishanshrestha/your-disposable-email-list-is-rotting-size-wont-save-you-9edec7a9bfdc

Top comments (0)