How disposable email blocklists actually work — why your favourite domain stops working at signup

You sign up to a service. You paste a temp-mail address. The verification code never arrives. You try a different temp-mail domain. The verification code arrives. What happened?

The service ran your email through an anti-fraud blocklist. The first domain was on the list; the second wasn't. This post is the technical breakdown of how those lists are built, who maintains them, and why this game is fundamentally never won by either side.

Who maintains the lists

There's no single official blocklist. There are several commercial vendors and a few open-source community lists.

• NeverBounce, Kickbox, ZeroBounce — commercial email-validation APIs. Sign up for a free trial; pass them an email; get back a JSON object with fields like disposable: true. Their lists are continuously updated from their own intelligence + crowdsourced data.
• SaaS-specific in-house lists — large platforms (Twitter, Discord, Stripe, Cloudflare) maintain proprietary lists on top of the commercial ones, augmented with their own signup-pattern data.
• Public GitHub lists — the most-starred is disposable-email-domains/disposable-email-domains with ~100k entries. Free to use; not as fresh as commercial lists.
• RBL / DNSBL projects — Spamhaus, SORBS, and the Spamhaus DBL specifically include a flag for disposable domains. Some servers query these at SMTP time.

Detection signals

How does a domain end up on a list? Several signals, in decreasing order of strength:

1. Self-identification. The temp-mail provider publishes its domain list on its homepage. Vendors crawl those pages and ingest the domains.
2. MX-record patterns. Disposable providers tend to have a small number of MX hosts shared across many domains. When a vendor sees a new domain pointing to mail.gw's MX records, it's flagged.
3. Anonymous WHOIS + recent registration. Short registration history + privacy-protected WHOIS = suspicious. Combined with high signup volume on the destination service, flagged.
4. Behavioural signals. If 90% of accounts created with @somedomain.com never log in again, services internally flag the domain.
5. Crowdsourced reports. Commercial vendors run honeypot signup flows; when a domain comes up in their honeypot mail consistently, the domain gets flagged.

The provider counter-measures

Disposable-email providers know the game. Their counter-measures:

• Domain rotation. Mail.tm publishes a list of ~10 active domains; rotates them every few weeks; quietly provisions new domains as old ones get blocked.
• Custom-domain offerings. TempMail.lol's paid tier lets you bring your own domain — invisible to public blocklists.
• Per-user random subdomains. Some providers generate unique subdomains for each user, so the full-qualified address looks unique.
• MX hiding. Some providers hide their actual MX behind opaque cloud-mail proxies (SES, Mailgun) so the MX-pattern signal is degraded.

Why the cat-and-mouse never ends

The fundamental problem: anti-fraud blocklists optimise for precision, not recall. Each new disposable domain costs them an incremental update; each new SaaS service has to update its upstream blocklist subscription. Meanwhile, every new disposable provider that registers a domain creates a window of acceptance before the list catches up.

Both sides have an economic incentive to keep playing. Disposable providers get traffic from users who need a working address. Anti-fraud vendors charge per API call. Stripe / Discord / Cloudflare see fewer fake signups. Nobody wins, but nobody loses either.

What this means for users

Practical implications:

• The domain you used yesterday may not work today. PocketInbox handles this with multi-provider failover.
• Newer providers slip past more blocklists. Mail.tm (newer) tends to have higher acceptance than Guerrilla Mail (older).
• Custom-domain temp-mail (paid) defeats the lists. If a service is critical, TempMail.lol's paid tier with a custom domain is reliable.
• Aliases beat disposable for long-term. SimpleLogin / Addy / Apple Hide My Email use real-looking domains; service-specific blocklists rarely catch them.

What this means for SaaS founders

If you're running the signup form on the other side: blocking disposable email is too blunt a tool. Real users with real reasons to use a temp address (privacy concerns, alpha test users) get rejected. Better:

1. Soft-block. Allow signup; flag the account for extra verification (email-only, no SMS, lower trust score for the first 7 days).
2. Behavioural scoring. Look at signup time-of-day, IP patterns, mouse movements (yes, really). Disposable-email + datacenter-IP + zero session-time signups are bots; flag those, not the domain.
3. Email-as-secondary-identity. Phone number or OAuth (Sign in with Google / Apple) as primary; email is notification-only. Removes the temp-mail attack surface.

The PocketInbox stance

We don't see anti-fraud blocklists as an enemy. We see them as a friction tax that shifts the cost of bot-resistance from the service to the user. We try to minimise the user-side cost (failover, OTP detection) and we're honest with users about when temp mail won't work (Discord, dating, banking).

Need an inbox right now and want to know which provider has the best chance of slipping past your target service's blocklist? Check our use-case guides — we publish empirical acceptance rates per service per provider.

Related: Why is disposable email blocked here? · Best temp-mail services 2026 · Disposable vs alias email.