A benchmark run by VerifySwift put 17 disposable email detection services through 272 checks across 16 temporary email providers. The headline numbers are stark: a 59% average detection rate, and 4 services scoring below 50%. Most of the tools developers trust to block fake signups are failing silently.
This post covers what the data shows, where Temp Mail Detector sits, and what the findings mean practically.
The Methodology
Each of the 16 temp mail providers had a fresh address generated. That address was tested against all 17 detection services via their primary interface, whether API, dashboard, or web tool. Every result was screen-recorded and scored: a pass means the service correctly flagged the address as disposable; a fail means it accepted it as legitimate.
This is a domain-level detection test. It measures whether services can identify known temporary mail infrastructure, which is the foundational requirement for any disposable email checker.
The Results Matrix: A Wide Spread
The full results matrix reveals a significant gap between the top performers and the rest. Green scores cluster around the top of the rankings. Red dominates the bottom. Several services that are widely integrated into developer toolkits scored below 10 out of 16.
The overall 59% detection rate is a useful anchor. It means a randomly selected detection service, applied to a randomly selected disposable address, fails to catch it over 40% of the time. For any signup flow where fake accounts carry real cost, that failure rate is not acceptable.
Top Performers
VerifySwift ranked first
This is the service that ran the test, which invites fair scrutiny. Self-published benchmarks where the author wins require a transparent methodology to be credible. In this case, the screen-recorded results and public matrix allow independent verification. The result holds.
TempMailDetector ranked second.
TempMailDetector scored 14⁄16. Two providers slipped through. That is the honest number, and it’s worth understanding in context.
Our results
The two misses prevent TempMailDetector from claiming a clean sweep, and that should be acknowledged directly.
Emailnator, one of the services included in the benchmark, operates on Gmail infrastructure. Detecting it requires the checker to receive and evaluate a full user submitted email address, matching it against known Gmail alias patterns.
TempMailDetector performs validation at the domain level only to remain fully GDPR compliant. No full email address is required or stored. This is a deliberate privacy design decision: the user’s email never touches TempMailDetector’s infrastructure beyond the domain portion.
As for the second provider, mails.org - we are now actively tracking and regularly adding new domains.
How Detection Actually Works
Most disposable email checkers are essentially a lookup against a list of known domains. That is the baseline, and it is not enough. The tools that scored highest in this benchmark layer multiple signals together. Here is what that actually looks like.
Domain blocklists are the starting point. A maintained list of known disposable domains covers roughly 60-80% of throwaway addresses in the wild. The ceiling is low because the lists are reactive: a domain has to be discovered, reported, and merged before it is blocked. That lag is where abuse lives. Internal testing from Nodedata showed a one-week-old blocklist drops to 64% accuracy. At one month, it is 43%. If you are not refreshing weekly at minimum, your list is doing less than half the job.
MX record clustering is where detection gets meaningfully better. Disposable providers reuse mail server infrastructure across many domains. A domain that has never appeared on any blocklist can still be identified by checking where its MX records point. If they resolve to known disposable infrastructure, the domain is disposable regardless of whether anyone has reported it yet. This technique catches newly rotated domains the moment they are deployed, not weeks later when a community list catches up. For manual lookups we provide a lookup mx tool which can help identity provider infrastructure.
Domain age and WHOIS data add a weaker but useful signal. Domains registered in the last year carry elevated risk due to them being newly created.
Pattern recognition and heuristics also play a part in detecting fake addresses. Keyword patterns in the domain (temp, throwaway, disposable), random character strings in the local part, and high-risk TLDs like .tk, .ml, .ga, and .cf are individually inconclusive. Combined with the signals above, they add weight. Missing SPF, DKIM, or DMARC records also correlates with disposable infrastructure, though from our experience many legitimate small domains often lack them too.
The Bottom Performers: A Real Problem
Several services scored in the range of 4-7 out of 16. These are not edge cases. Some are well-known, actively marketed email verification platforms.
The “risky” label some services attach to results also came in for criticism. Flagging an address as “risky” rather than “disposable” shifts the classification burden onto the developer without giving them a clean signal. It is a hedge that makes the tool easier to defend and less useful to implement.
Hardest-to-Detect Providers
Emailnator, Mails.org, and EmailOnDeck were the three providers that most services in this benchmark failed to catch. They are not edge cases. They represent the realistic threat surface for any signup flow in 2025.
Emailnator is the hardest. It generates addresses on Gmail-based domains, meaning the underlying mail infrastructure is identical to a legitimate Google account. A domain level checker has nothing to act on: the domain is not disposable, it is Gmail. Catching Emailnator requires either processing the full submitted address and matching it against known Gmail alias patterns, or maintaining specific heuristics for Gmail based abuse.
Only two out of seventeen services in this benchmark did that correctly. Mails.org and EmailOnDeck rotate domains frequently enough that static lists lag behind. These can be caught but are missed by blocklist only approaches. Their presence in the benchmark failures is a direct indicator of which tools rely on static data versus live infrastructure analysis.
The False Positive Problem
Detection accuracy gets most of the attention, but false positives carry their own cost. Block too aggressively and you lose real users.
Apple’s Hide My Email is the biggest landmine. These are forwarding addresses generated through iCloud, and they do not auto-expire. They forward to a real inbox indefinitely. The user behind one is typically a paying iCloud+ subscriber. This means that hard blocking those addresses at signup loses privacy conscious users who are often more technically sophisticated and more likely to convert on paid products. Apple customers also tend to be higher paying customers.
The right treatment is to flag them, not reject them: route to a separate segment, monitor engagement, and treat as legitimate but worth watching. It’s for this reason that Temp Mail Detector scores Apple Hide My Email users as score 0, does not include them in the block list, but does flag them as a forwarding email.
Firefox Relay and SimpleLogin serve the same function. Users creating accounts with these addresses are protecting their inbox, however as a limited number of free addresses are offered, they are still prone to abuse.
The practical recommendation is to maintain three tiers in your detection response: confirmed disposable (block or require alternative), privacy relay (flag and potentially allow), and unknown (allow with monitoring). Any detection service that collapses these into a single boolean is forcing you to choose between blocking fraud and blocking legitimate users.
Key Findings, Summarised
Static blocklists are insufficient. Services relying on fixed domain blocklists consistently underperformed against providers not yet on those lists. Real-time analysis or regularly updated data is necessary.
Price does not predict accuracy. Several paid, enterprise-positioned services scored below free alternatives. Vendor marketing around detection accuracy is not a reliable signal.
Emailnator is a systematic blind spot. Because it uses Gmail infrastructure, most domain-level checkers cannot detect it without full-address analysis. This is a known limitation. Services that score well against Emailnator are either processing full addresses or maintaining specific heuristics for Gmail alias abuse.
“Risky” classifications are not actionable. A checker that returns “risky” instead of a boolean disposable/not-disposable result is offloading the decision to the developer without the data to make it. This matters for automated signup flows.
Where This Leaves TempMailDetector
For use cases where full-address submission to a third-party is unacceptable, TempMailDetector’s approach is the relevant comparison point. On that basis, the gap between TempMailDetector and first place is one provider category: Gmail-alias-based disposable services.
The benchmark validates domain-level detection as competitive and maps exactly where the remaining gaps are. Closing them is the next step: We are currently training our own model to do exactly that and will soon offer this as a second detection endpoint, allowing customers to choose whether they wish to use our privacy enhanced lookup, or the full email address lookup.
Data source: 3rd party test conducted by VerifySwift, published January 2025. 272 individual tests across 17 services and 16 disposable email providers. Download infographic.
