Disposable Email Detection: What Works, What Doesn't, and Why It Matters

If you run a SaaS with a free tier, disposable emails are quietly draining you. Every Mailinator address that signs up and never returns means wasted onboarding emails, inflated activation funnel metrics, and in the worst case, coordinated abuse that gets your sending domain blacklisted.

This post is a practical guide: what counts as a disposable email, why simple blocklist approaches fail, and what actually works in 2026.

What is a disposable email?

A disposable email (also called a temporary email, throwaway email, or DEA — disposable email address) is an inbox that exists just long enough to receive a single confirmation email. Users get an address, grab the confirmation, and the inbox disappears — often within minutes.

Popular providers include:

• Mailinator — the OG, running since 2003
• 10 Minute Mail — self-explanatory
• Guerrilla Mail — one of the largest, with millions of active addresses
• Temp Mail / Temp-Mail.org — the current market leader by volume
• DropMail / FakeMail / EmailOnDeck — dozens of smaller services

Collectively, these services process tens of millions of disposable addresses per day.

Why disposable emails matter for your SaaS

At small scale, a few disposable signups are no big deal. At scale, the costs compound:

1. Inflated signup metrics — your "300 new signups this week" number looks great until you realize half of them will never log in twice.
2. Wasted sending quota — Resend, Postmark, SendGrid all charge per email. Sending to disposable addresses is burning budget.
3. Deliverability damage — sending to mailboxes with no MX records, or getting bounces from expired disposable inboxes, hurts your sender reputation.
4. Free-tier abuse — the attacker's recipe: sign up with disposable email, use the free tier, repeat with a new address.
5. Referral/affiliate fraud — if you pay for referrals, disposable emails are how attackers farm.

One SaaS we talked to estimated that 23% of their free signups were disposable. Blocking them reclaimed about $400/month of Resend quota and raised their 7-day activation rate from 11% to 14%.

Approach 1: The blocklist (and why it alone is not enough)

The obvious approach: maintain a list of known disposable email domains and block them at signup.

Public blocklists do exist — there are open-source lists on GitHub with 3,000 to 100,000+ domains. A typical implementation:

const DISPOSABLE_DOMAINS = new Set([
  "mailinator.com",
  "10minutemail.com",
  "guerrillamail.com",
  // ... thousands more
]);

function isDisposable(email) {
  const domain = email.split("@")[1]?.toLowerCase();
  return DISPOSABLE_DOMAINS.has(domain);
}

This is fine as a first line, and it's better than nothing. But it has two big weaknesses:

Weakness 1: Disposable services add new domains constantly

Mailinator alone uses hundreds of rotating domains. Temp-Mail rotates through thousands. Your static blocklist is out of date the moment you commit it.

Weakness 2: "Catch-all" subdomains

Some services let users generate addresses on arbitrary subdomains. You'd need wildcard matching, and even then attackers can register brand-new domains and point them at open-relay SMTP servers.

So blocklists help — but they're a floor, not a ceiling.

Approach 2: MX and DNS-based checks

The next layer: verify that the email domain actually resolves and has mail infrastructure.

Every legitimate email domain needs:

1. An A or AAAA record — the domain exists.
2. An MX record — the domain can receive email.
3. SMTP reachability — the mail server actually responds.

Many disposable providers skip steps 2 and 3 on "used" addresses — once the confirmation email is delivered, the MX record stops responding. If you check at signup time, you'll see the live record. But if you re-check 24 hours later, about 15% of disposable addresses fail MX lookup.

This gives you a second detection strategy: re-verify suspected addresses asynchronously. Store a list of low-confidence addresses and re-check MX records a day later. Any that fail can be flagged retroactively.

Approach 3: Behavioral signals from the disposable service

Here's something most developers miss: disposable email services leave behavioral fingerprints that aren't on any blocklist.

For example:

• Inbox access patterns — disposable addresses are checked from a small pool of AWS/DigitalOcean IPs that belong to the disposable service's scraping backend, not the "user's" claimed location.
• Send-time distribution — confirmation emails to disposable addresses are opened within 10–90 seconds. Real inboxes show a much broader distribution (minutes to days).
• Link-click velocity — disposable services often auto-click all links in the confirmation email, producing super-fast click-through rates that are statistically impossible for humans.

If you're running your own email sending, you can capture these signals from Resend/Postmark webhooks. For most teams, this is overkill — the first two approaches get you 90% of the way.

Approach 4: Combining signals (what Vouchley does)

A single signal is weak. Combined signals are strong. The detection stack we run on every Vouchley verification:

1. Syntactic email validation (RFC 5322)
2. Disposable blocklist (curated + updated weekly from open sources)
3. MX record lookup (with 2s timeout)
4. Domain age check (very new domains are suspicious)
5. Free-provider classification (not a block signal, but a weight)
6. Role-based detection (info@, admin@, etc.)

The output is a boolean disposable flag plus a weighted contribution to the overall trust score. Even when a specific disposable domain slips past our blocklist, the missing MX record or very-new domain age usually catches it.

Here's what it looks like in the API response:

{
  "score": 22,
  "recommendation": "block",
  "email": {
    "valid": true,
    "disposable": true,
    "free_provider": false,
    "role_based": false,
    "mx_record": true
  },
  "reasoning": "Disposable email provider (tempmail domain)."
}

When to block vs. when to warn

Hard-blocking disposable emails at signup is usually the right call for B2B SaaS. For consumer products, the decision is more nuanced — some legitimate users really do value privacy and use services like SimpleLogin or ProtonMail aliases.

A sensible middle ground:

• Hard block obvious disposable providers (Mailinator, 10MinuteMail) that exist solely for throwaway use.
• Flag for review privacy-forwarding services (SimpleLogin, AnonAddy, Firefox Relay) — they're technically email aliases but real users use them.
• Approve but throttle signups from free providers (Gmail/Yahoo) that otherwise look clean.

Integration in one API call

The whole point of an email validation API is that you don't have to build any of this yourself:

curl -X POST https://api.vouchley.getrevlio.com/v1/verify \
  -H "Authorization: Bearer $VOUCHLEY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"email": "test@mailinator.com"}'

Response:

{
  "score": 15,
  "recommendation": "block",
  "email": {
    "valid": true,
    "disposable": true,
    "free_provider": false,
    "role_based": false,
    "mx_record": true
  },
  "reasoning": "Disposable email provider detected."
}

Cache hits are free, so repeated attempts with the same address cost you zero credits.

What NOT to do

A few common anti-patterns we see:

1. Don't regex-match for "temp" or "throwaway" in email addresses. Real users have addresses like temp-testing@realcompany.com. Use proper domain-level matching.
2. Don't block every new domain. Legitimate startups register domains daily.
3. Don't show the user exactly why they were blocked. Attackers will tune around it. Show a generic "this email can't be used" message.
4. Don't forget to log. Every rejected signup is a data point. If your support inbox fills up with false-positive complaints, you need the logs to tune thresholds.

Conclusion

Disposable email detection isn't a one-off feature — it's an ongoing arms race against services that add new domains weekly. The right approach combines a maintained blocklist, MX validation, domain-age checks, and a weighted scoring system.

You can build all this in-house. Most teams shouldn't. Vouchley's /v1/verify endpoint does every check above plus IP reputation, company validation, and person-match scoring in a single ~200ms call. The first 100 verifications are free.

Your free tier will thank you.