The disposable email problem (and why lists aren't enough)
Why disposable email lists always lag behind, how throwaway services evade them, and the DNS and domain signals that catch what lists miss.
Disposable email services give anyone a working inbox in seconds, no account needed, often gone within the hour. People use them for reasonable things: avoiding marketing spam, testing, privacy. For a SaaS product, though, they usually mean one of three things: a free-trial loop, a fake account, or a signup you’ll never reach again.
The standard defense is a blocklist of known disposable domains. You need one. It isn’t enough on its own, and it helps to understand why.
What disposable addresses cost you
- Trial and credit abuse. Each new inbox is a new free trial. If trials carry real cost (compute, AI credits, SMS, seats), this adds up.
- Fake accounts. Spam, scraping, referral fraud and review manipulation all start with cheap identities.
- Dead contacts. The inbox expires, so password resets, invoices and onboarding emails bounce later.
- Polluted metrics. Signups that were never going to activate drag down every funnel number.
Note what email verification doesn’t solve: most disposable services can receive mail, so “click the link we sent you” works fine for the abuser. Confirming the inbox exists proves nothing about whether it’s throwaway.
Lists: necessary, not sufficient
Community-maintained lists are the foundation. The widely used open-source disposable-email-domains project, for example, publishes thousands of domains under a permissive license, plus an allowlist for domains that were wrongly added. We use lists like it, along with our own and others, and check every source’s license.
Lists still miss things, structurally:
1. New domains appear constantly
Domains are cheap. Services add fresh ones as old ones get listed. A list is a snapshot of what someone noticed and contributed; there’s always a gap between a domain going live and it reaching every list.
2. Some services hide behind ordinary-looking domains
Not every throwaway domain looks like tempmail-something. Some look like a small business or a personal site. A human reviewer can miss them; a regex certainly will.
3. Lists contain mistakes
Domains get added that aren’t disposable: a small business, a university, an alias service. Blocking those turns away real users, which is why good lists carry an allowlist and why you need a way to correct them quickly.
4. Relay services aren’t disposable, but they aren’t companies either
Apple Hide My Email, Firefox Relay, DuckDuckGo Email Protection, SimpleLogin and addy.io forward to a real person’s inbox, persistently. These users are reachable and usually legitimate. But the address says nothing about their company, and some products care about that. Treat relay as its own category and decide by policy, rather than lumping it in with disposables.
Signals that catch what lists miss
Because a list can’t keep up, we look at how a domain is set up, which is harder to fake at scale.
Shared mail infrastructure. Disposable services run many domains on the same mail servers. When an unknown domain’s MX host also serves several domains already known to be disposable, the new domain very likely belongs to the same operation. We treat an MX host serving three or more known disposable domains as a disposable signal (mx_shared_disposable). One rotation of domains doesn’t help an operator who keeps the same servers.
Domain age. A domain registered days ago is not proof of anything; companies register domains every day. Combined with other signals, it’s telling. RDAP gives you the registration date (new_domain when younger than 30 days).
No real website. A parking page, a “this domain is for sale” page, or nothing at all (parked_domain, no_website). Companies that sign up for B2B software usually have a site.
No email authentication. Functioning business domains increasingly publish SPF and DMARC. A brand-new domain with neither (no_spf_no_dmarc) is weak evidence alone, and useful in combination.
Forwarding-only mail. A domain whose MX points at a free forwarding service has no mailboxes of its own (mx_forwarding_service). Fine for a personal project; a yellow flag on a trial signup.
Lookalikes and typos. gmaii.com and confusable-character domains imitating big providers (lookalike_domain, typo_suspected) are either mistakes or tricks; either way they deserve a second look.
None of these signals should block on its own. They shift confidence. When confidence falls too low, the honest answer is “unknown”: review it, don’t reject it.
Things that look suspicious but aren’t
- Subaddressing.
jane+trial@acme.iois a normal feature of most mail providers. It’s not disposable. If you care about repeat trials, compare on the normalized address (+tagremoved) instead of blocking. - Privacy-minded users. Relay users often just don’t want spam. Decide whether your product needs a company identity before treating them as abusers.
- Small companies with odd setups. A three-person company on a hosting provider’s mail service, with no DMARC, is still a company.
A layered approach
- Lists for the known: disposable, relay, shared providers, with an allowlist for corrections.
- DNS and domain signals for the unknown: shared disposable MX, age, website, authentication records.
- A review lane for low confidence, instead of a hard block.
- Normalization so
+tagsand case differences don’t create “new” users. - Feedback that’s reviewed by people, so one report fixes the verdict for everyone, and nobody can get a competitor’s domain blocked by spamming reports.
- Controls beyond email for high-value abuse: payment-method checks, rate limits on expensive actions, device signals.
Email checks won’t stop a determined attacker with a real company domain. They stop the cheap, scalable abuse, which is most of it, before it costs you anything.
How isBusinessEmail handles it
Every check runs this stack and tells you which signals fired:
curl -sG https://api.isbusinessemail.com/v1/check \
--data-urlencode "email=disposable@test.isbusinessemail.com"
You get is_disposable, is_relay, category, a recommendation under your chosen policy, and the reason codes behind it. With deep=true, domain age and the homepage check are included. If you find a disposable domain we miss, report it; confirmed reports reach every customer within about a minute.
Browse the disposable domains list, try the disposable email checker, or see the free trial abuse playbook.
Frequently asked questions
What is a disposable email address?
A throwaway inbox from a service that gives anyone a working address in seconds, with no account needed, often gone within the hour. People use them to avoid marketing spam or for testing, but on a SaaS signup they usually mean a free-trial loop, a fake account or a contact you'll never reach again.
Why aren't disposable email blocklists enough?
New domains appear constantly, some services hide behind ordinary-looking domains, and lists contain mistakes. There is always a gap between a domain going live and it reaching every list.
How do you detect a disposable email domain that isn't on any list?
Look at how the domain is set up: mail servers shared with known disposable domains, a very recent registration date, a parked or missing website, no SPF or DMARC, and forwarding-only mail. Combine these signals instead of blocking on any single one.
Is Apple Hide My Email a disposable email address?
No. Relay services such as Apple Hide My Email, Firefox Relay and DuckDuckGo Email Protection forward persistently to a real person's inbox. The person is reachable, but the address says nothing about their company, so treat relay as its own category.
Does email verification stop disposable signups?
No. Most disposable services can receive mail, so a confirmation link works fine for the abuser. Confirming that an inbox exists says nothing about whether it's throwaway.