The complete guide to disposable email detection

Syntax-valid, MX-record-valid, and still worthless for your product: that's a disposable email address from 10minutemail, guerrillamail, mailinator, or one of several hundred similar throwaway-inbox services. If you're not filtering these, a meaningful slice of your "verified" signups are addresses nobody will ever check twice.

Here's why this is a genuinely different problem from syntax or MX validation, and how to actually solve it.

Why there's no algorithmic tell. A disposable-mail domain looks completely normal — valid syntax, real MX records, sometimes even a legitimate-looking domain name. There's no structural pattern that distinguishes mailinator.com from gmail.com at the protocol level. The only reliable signal is a maintained list of known disposable domains, checked against the domain part of the address:

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

The catch: the list has to stay current. New disposable-mail domains spin up constantly — some services rotate domains specifically to dodge blocklists. A list you snapshot once and never update degrades within weeks. The community-run disposable-email-domains project is a solid free starting point and is actively maintained, but you need a process to re-sync it, not a one-time import.

Where this fits in the validation pipeline. Order matters, because each check is progressively more expensive and should only run if the previous one passed:

1. Syntax — near-instant, always run
2. MX record lookup — one DNS call, catches typo'd/dead domains
3. Disposable-domain check — a set lookup against your list, catches throwaway-but-technically-valid addresses

Running them in that order means you only pay for the disposable-domain check on addresses that already passed the cheaper filters — no wasted work on obviously broken input.

What it doesn't catch: a user who signs up with a real Gmail address they simply never check again. Disposable-domain detection targets services designed for throwaway use, not general inbox abandonment — that's a retention problem, not a validation one.

I run this exact pipeline (syntax → MX → disposable-domain, each opt-in past the first) as an endpoint on Validate with a synced domain list, if you'd rather not own the re-sync process yourself. Sibling APIs on the same account: QR API and Currency API.