Why some sites block disposable email — and how to tell before signing up

May 21, 2026·11 min read

You paste a tenmin.app address into a signup form. The form turns red: "Please use a real email address." The site doesn't seem to do anything else special — there's no IP block, no captcha — just that one rejection. What happened, and what (if anything) can you do about it?

This guide walks through the mechanics: how validation libraries decide that an address is "disposable," where the blocklists come from, why some sites care and others don't, and a short list of legitimate workarounds for the cases where the rejection is just friction.

What "blocked" actually means at the form layer

When a website checks the email you just typed, it usually does three different things at three different stages:

Syntax check. Is this even a well-formed email address? Most forms run a regex on the local-part and domain, accept anything that parses, and move on.
Domain check. Does this domain accept mail at all? The site looks up the domain's MX records (the DNS entries that tell mail servers where to deliver) and, increasingly, compares the domain against a known-bad list.
Risk scoring. Does this address smell suspicious? Some services run the address through a paid risk-scoring API that combines blocklist membership, age of the domain, whether the address was seen in a recent data breach, whether the format looks machine-generated, and similar signals.

Step 2 is where disposable-email rejection usually happens. The site doesn't try to send you mail and watch it bounce — that would take seconds and the form needs to respond in milliseconds. Instead, it consults a list.

Where the blocklists come from

There are about a dozen widely-used public lists of "disposable email domains." The oldest and most cited is on GitHub, originally maintained by the SimpleLogin team ironically enough, and it contains around three thousand entries. Most validation libraries — email-validator on npm, mailcheck, the Python disposable_email_domains package, Laravel's EmailValidator — pull from a list like this at build time and either ship a bundled snapshot or fetch fresh copies periodically.

Entries land on the lists in three ways. First, public disposable-email services like Mailinator, Guerrilla Mail, and 10MinuteMail have been on every list for years. Second, spammers and bot operators set up their own throwaway services to abuse signup bonuses, and once an operator notices their lead magnet getting a thousand fake signups from a new domain in a weekend, that domain joins the lists. Third, when a service deliberately wants to be included (which is, perhaps surprisingly, what most legitimate disposable-inbox services want, because it sets a clear expectation with sites that genuinely don't want throwaway signups), the operator opens a pull request and is added.

tenmin.app is on the major lists. We submitted ourselves; we'd rather a bank's signup form reject us cleanly than have a user attempt to verify their identity with us and end up locked out later.

Why some sites block and others don't

Banks, crypto exchanges, identity-verification providers, government portals, and any service that's regulated for know-your-customer compliance — all of these block. Their signups are not interchangeable; they need to be able to reach the human behind the account months or years from now, and a disposable address quite literally can't promise that.

Most consumer SaaS — newsletter sign-ups, free trials, demo accounts, coupon unlocks, forum registrations, lead-magnet downloads — doesn't block. The signup is genuinely low-stakes, the website's growth metric is "form submissions" not "verified users," and rejecting disposable mail would drive away a small but real fraction of legitimate users who simply prefer not to hand over their real address.

Between the two extremes are services that block sometimes. Many companies use risk-scoring APIs that block disposable addresses only when other signals are also suspicious: a new IP, a request from a known VPN range, a user-agent that looks like automation. If you hit the form from a clean browser on a residential connection and nothing else is unusual, you might get through. If you're already on a VPN and you're also using a throwaway address, the rejection is more likely.

How to tell before you sign up

Three simple checks save most of the frustration.

1. What does the privacy policy say about the email?

If the policy says they use the address for "service updates, account notifications, and password recovery," they need a real one. If it says "to send you your discount code and occasional product updates," a disposable address is fine. The policy almost always tells you, in language much clearer than the signup form itself.

2. Does the service have a paid tier and does the signup feed into it?

Free trials of paid software almost always need a stable address — you'll need it to log back in later, to recover a forgotten password, or to receive an invoice. Free tools that don't have a paid tier (most "give us your email for the PDF" forms) don't need it. Look at the pricing page before the signup page; it'll tell you.

3. Is the signup form already pre-emptively warning about disposable email?

Some forms say "no disposable, temporary, or role addresses." That's a clear signal: not only will they block, they've already paid for a service that does it well. Don't fight it, use a real address (or an aliasing service if you specifically don't want to give them your real one — see our comparison guide).

What to do when you get rejected

First, double-check that the rejection is actually about the domain and not the local part. Some forms reject any address with a hyphen, anything shorter than five characters, or anything that doesn't match a particular regex. Try a fresh tenmin.app address with a longer local part to rule that out.

If the domain really is blocked, your options in order of preference are:

Use an aliasing service instead. SimpleLogin, Addy.io, and Apple's Hide My Email all use domains that aren't on disposable lists. The address is stable, you can turn it off later, and you get past the validation. If you specifically wanted a disposable address because you didn't want long-lived clutter, you can delete the alias after the signup is complete and get most of the same benefit.
Plus-address your real inbox. If the signup is low-stakes and the sender just shouldn't get to email you forever, [email protected]works on every block list (because it's a real Gmail address with a tag) and you can filter it later.
Set up a catch-all on your own domain. If you own a domain — or are willing to spend a dollar a year to own one — Cloudflare Email Routing will accept anything sent to it and forward to your real inbox. The domain isn't on any blocklist, and you can change the forwarding rules whenever you like.
Reconsider whether you actually need to sign up. If the only way to get past the form is to use your real address, ask yourself whether the thing on the other side is worth that. The answer is often no.

The grey-area question: should you try to bypass the block?

There's a category of "disposable but not on blocklists" services that sells itself specifically as a workaround. The mechanic is usually that they run on a brand-new domain that hasn't been added to the public lists yet. This works, briefly, until the operators of the sites you're signing up for notice the pattern and the domain gets added too.

We don't operate one of these. We submitted tenmin.app to the major blocklists deliberately, for two reasons. First, the only sites that bother to maintain that validation are sites that genuinely don't want throwaway signups, and we'd rather not send our users into a service whose terms they're about to violate. Second, every time a bypass-style disposable provider gets popular enough to matter, it gets blocked, and the users who set things up against it are stranded. We'd rather you know up front whether the signup will work.

If you have a use case where a site explicitly forbids disposable addresses and you really want one anyway, you're probably solving the wrong problem. The site already told you what it wants. Use an aliasing service, give them what they asked for, and disengage on your own terms later.