Disposable Email Detection: Why Most Tools Fail (and What Actually Works)
A 272-test benchmark pitted 17 disposable email detection services against 16 known disposable providers. The average detection rate? 59%. One tool scored a perfect 16/16. Another - WhoisXML - caught zero. If you're relying on a throwaway email checker right now, there's roughly a coin-flip chance it's missing half the threats coming through your forms.

Disposable emails aren't just a nuisance. They're a symptom of a data pipeline with no verification layer. Fix the symptom, and you're playing whack-a-mole. Fix the pipeline, and the problem mostly disappears.
What You Need (Quick Version)
Three tiers, depending on your resources and risk tolerance:
Free/DIY: Grab the [disposable-email-domains](https://github.com/disposable-email-domains/disposable-email-domains) GitHub repo (~4.9k stars) and add MX record heuristics. You'll catch 60-80% of disposable signups. Good enough for low-stakes forms.
API-based detection: Pick a service that runs real-time infrastructure analysis - MX clustering, domain age, behavioral signals - not just a bigger static list. The 272-test study showed only 1 out of 17 tools caught everything.
Upstream prevention: Stop filtering bad data after it enters your system. Verify emails at the point of collection, before anything touches your CRM (and your contact management software).
What Disposable Emails Are (and Aren't)
Not all throwaway addresses work the same way. The category breaks into four distinct types, and lumping them together is how teams end up blocking legitimate users.

Auto-destruct addresses are the classic variety. Services like 10MinuteMail and Guerrilla Mail generate an inbox that self-destructs after a set window - usually 10 to 60 minutes. These are the easiest to detect because the domains are well-known and rarely change.
Shared inbox services like Mailinator take a different approach. Anyone can read any inbox at their domain. No authentication, no privacy - just a public dumping ground. These domains are relatively stable and appear on most blocklists.
Gmail-based disposable services are where detection gets hard. Emailnator generates addresses on real Gmail-based domains, so the underlying infrastructure looks identical to legitimate Gmail. Only about 2 out of 17 services in the January test flagged these correctly.
Privacy relays are a different animal entirely. Apple's Hide My Email, Firefox Relay, and SimpleLogin generate unique forwarding addresses tied to a real person's inbox. These don't auto-expire, and the user behind them is often a paying customer (Hide My Email requires iCloud+). Treating these the same as a 10MinuteMail address is a mistake we'll come back to.
Why Detection Matters
Castle's October 2025 fraud tracker identified 1,700 domains, each responsible for 400+ abusive signup attempts across their network. That's not theoretical risk. That's active, ongoing abuse at scale.
The downstream damage compounds fast. Disposable addresses bounce, which tanks your sender reputation (see how to improve sender reputation). Spam traps slip in alongside them, which can get your domain blocklisted entirely (and force spam trap removal). Every fake signup pollutes your analytics, inflates your CAC calculations (use this CAC guide), and wastes sales team time on phantom leads. We've seen teams lose weeks of pipeline velocity chasing contacts that never existed.
Should you block disposable mail at all? This is a genuine debate in the r/SaaS community, and the answer depends on what you're protecting. For free trials and gated content, absolutely - disposable signups are pure waste. For product signups with no monetary gate, aggressive blocking costs you privacy-conscious users. The right move is layered: block the obvious throwaway domains, flag the ambiguous ones, and never hard-block privacy relays.
How Detection Actually Works
No single method catches everything. The tools that scored highest in independent testing layer multiple signals together.

Domain Blocklists
The simplest approach: maintain a list of known disposable domains and reject matches. Well-maintained lists cover roughly 60-80% of temporary email addresses in the wild. The problem is they're purely reactive - a new domain has to be discovered, reported, and added before it's blocked. That lag is where abuse lives.
MX Record Clustering
This is where things get interesting. Disposable services reuse mail server infrastructure across many domains. The domain powerscrews.com looks innocuous, but check its MX records:
$ [dig MX](https://support.dnsimple.com/articles/dig-reference-guide/) powerscrews.com +short
10 in.mail.tm.
That single line ties it directly to the known disposable provider mail.tm. MX clustering catches newly rotated domains by linking them to known disposable infrastructure, even if the domain itself has never appeared on a blocklist. It's the single most effective technique for staying ahead of domain rotation.
Domain Age and WHOIS Signals
Domains registered within the last 30-90 days carry elevated risk. When a fresh domain also has privacy-protected WHOIS records, the signal gets stronger. The limitation is GDPR - European registrations now routinely redact WHOIS data regardless of intent, which reduces this signal's reliability for EU-based domains.
Pattern Recognition and Authentication Gaps
Keyword analysis (temp, disposable, throwaway in the domain), random character strings in the local part, and risky TLDs like .tk, .ml, .ga, and .cf all serve as weak signals. Individually, none are conclusive. Combined with other signals, they add useful weight.
Email authentication records - SPF, DKIM, and DMARC - provide a supplementary signal too, since disposable domains often lack proper authentication setup (see DMARC alignment).
Behavioral Signals
The final layer sits at the application level. Multiple accounts from the same device fingerprint, zero engagement beyond email verification, rapid automated signup patterns - all indicate throwaway email abuse. These signals require application-level instrumentation but catch threats that purely email-based detection misses entirely.

You just read that a month-old blocklist catches only 43% of disposable domains. Prospeo skips that problem entirely - our proprietary 5-step verification with catch-all handling, spam-trap removal, and honeypot filtering means 98% of emails we deliver are real people at real inboxes. No throwaway addresses polluting your pipeline.
Stop playing whack-a-mole. Start with clean data at the source.
Why Most Tools Fail
The decay rate on static lists is brutal. Internal testing from Nodedata showed a week-old blocklist backup drops to 64% accuracy. At one month old, it's 43%. You're missing more than half of disposable signups within 30 days of your last update.
Here's the thing: the root cause is domain rotation. Disposable providers spin up new domains constantly - it's trivial and cheap. By the time a community-maintained list adds a domain, the provider has already moved to three new ones. Services like Emailnator make this worse by using real Gmail-based infrastructure, which means the domain itself isn't disposable at all. The address is. Only 2 out of 17 detection services caught Emailnator in the independent test.
The consensus on r/SaaS was blunt: "static blocklists are dead." The tools that performed best use real-time infrastructure analysis - MX clustering, live domain checks, behavioral heuristics - not just bigger lists. Price had zero correlation with accuracy. Some of the most expensive tools scored below 50%.
Open-Source Blocklists
If you're going the DIY route, these are the repos worth knowing:
| Repo | Domains | Updates | Stars | Notes |
|---|---|---|---|---|
| disposable-email-domains | ~4,000 | Weekly/monthly | ~4.9k | Best-maintained; has allowlist |
| disposable/disposable | ~100,000 | Daily | ~1,000 | Broadest; mixed quality |
| 7c/fakefilter | ~5,000 | Daily (automated) | ~239 | Misses some providers |
| wesbos/burner-email-providers | ~5,000 | Weekly/monthly | ~1,100 | Occasional false positives |
| throwaway-email (npm) | 180,000+ | Automated aggregation | - | One of the largest; npm install available |
For Python, the canonical repo has a PyPI package:
from disposable_email_domains import blocklist
For Node:
npm install throwaway-email@latest
One implementation pitfall that trips up most teams: the lists contain second-level domains, so you need proper subdomain matching. An address like @xxx.yyy.zzz must match against yyy.zzz where zzz is a public suffix - not just the full string. The disposable-email-domains repo includes multi-language examples that handle this correctly.
Don't skip the allowlist. The canonical repo maintains an allowlist.conf for domains frequently misidentified as disposable. Without it, you'll block legitimate signups and spend hours debugging support tickets.
Build vs. Buy
Use open-source lists if you're processing fewer than 1,000 signups per day, have engineering bandwidth to refresh weekly and tune false positives, and can tolerate missing 20-40% of disposable emails.

Buy an API when fraud directly impacts revenue - free trial abuse, promo stacking, account takeover. You need real-time detection at scale without maintaining infrastructure analysis in-house, and the 64%-to-43% accuracy decay of stale lists isn't acceptable.
Sometimes the answer isn't better detection - it's fixing the data pipeline itself. If your problem isn't just disposable emails but bad data across the board (typos, role-based addresses, spam traps, invalid domains), reactive filtering will never keep up. Prospeo's 5-step verification checks for disposable domains, spam traps, honeypots, and invalid mailboxes before data reaches your CRM, with a 7-day data refresh cycle and 98% email accuracy (more on email deliverability).
Let's be honest: if your average deal size is under five figures, you probably don't need a dedicated disposable email checker at all. You need clean data at the point of entry. The entire "detect and filter" approach exists because teams let unverified data into their systems and then scramble to clean it. That's backwards.
What the Benchmarks Show
The January 2026 benchmark tested 16 disposable providers against 17 detection services:
| Tool | Score (of 16) | Tier |
|---|---|---|
| VerifySwift | 16/16 | Top performer |
| TempMailDetector | 14/16 | Strong |
| VerifyMail | 14/16 | Strong |
| Reoon | ~14/16 | Strong |
| Mid-tier tools | 8-12/16 | Average |
| MillionVerifier | ~4/16 | Weak |
| WhoisXML | 0/16 | Failed |
The average across all 17 tools was 59%. Four services scored below 50%. Some tools claim 99%+ accuracy on their websites, but independent testing tells a completely different story. Price had zero correlation with accuracy - some of the cheapest tools outperformed premium services.
For pricing context across the verification space (and a broader list of Bouncer alternatives):
| Tool | Free Tier | Paid Rate |
|---|---|---|
| QuickEmailVerification | 3,000 credits/mo | ~$5/10K credits |
| BillionVerify | 100 daily checks | ~$0.0006/email |
| ZeroBounce | Free tools available | ~$16-20/1K credits |
| Hunter | 50 verifications/mo | ~$15/1K credits |
| NeverBounce | Free tools available | ~$18/1K credits |
| Kickbox | Free tools available | $10-50/1K (volume) |
| Prospeo (full verification) | 75 emails/mo | ~$0.01/email |
That last row deserves context. Prospeo isn't a disposable-only detector - it's full email verification with disposable domain flagging, spam-trap removal, catch-all handling, and deliverability checks in a single pass. At $0.01 per email with a free tier, it's competitive with dedicated disposable checkers while solving a broader problem.
The False Positive Problem
Blocking every address that looks disposable will cost you real customers.
Apple's Hide My Email is the biggest landmine. These addresses don't auto-expire - they forward to a real iCloud inbox indefinitely. But users can turn off the relay at any time, which means future sends hard bounce. Oracle's analysis recommends keeping hard bounce rates under 2% per month to protect deliverability (see email bounce rate).
Hide My Email requires paid iCloud+, and it's easiest to use through Safari, which holds roughly 18% of worldwide browser usage. That's not a trivial adoption ceiling. Firefox Relay and SimpleLogin serve similar privacy-conscious users who aren't trying to defraud you - they're trying to protect their inbox.
In our experience, teams that hard-block Apple relay addresses lose 5-10% of their highest-value signups. These are privacy-aware users who tend to be more technically sophisticated and more willing to pay for premium products. Flag relay addresses, don't block them. Route them into a separate segment, monitor engagement, and treat them as legitimate-but-risky. Rejecting people who are actively paying for a premium privacy service isn't how you catch fraudsters - skip that approach entirely.

Every disposable signup inflates your CAC and wastes your sales team's time. Prospeo refreshes 300M+ profiles every 7 days - not 6 weeks - so stale and fake contacts never reach your CRM. At $0.01 per verified email, cleaning your pipeline costs less than one bad bounce.
Fix the pipeline, not the symptom. Verify emails before they enter your system.
FAQ
Can disposable emails be detected with 100% accuracy?
No. The best tool in the 272-test benchmark caught 16 out of 16 providers, but the average was 59%. Services like Emailnator use real Gmail-based domains that evade most detectors. Perfect accuracy isn't realistic with current methods.
Should I block all disposable emails at signup?
Block them on free trials and lead magnets - disposable signups there are pure waste. For product signups, hard-blocking costs you privacy-conscious users on Apple Hide My Email or Firefox Relay. Flag and segment those addresses rather than rejecting them outright.
What's the best free disposable email checker?
The disposable-email-domains GitHub repo is the gold standard for DIY - ~4.9k stars, actively maintained, includes an allowlist. For a hosted free tier with full verification including disposable flagging, QuickEmailVerification offers 3,000 credits per month.
How often should I update my blocklist?
Weekly at minimum. A month-old list drops to 43% accuracy per Nodedata's internal testing. If you can't commit to weekly refreshes, use a real-time API - the accuracy decay makes stale lists worse than useless.