How websites detect disposable email addresses

Method 1: domain blocklists

The oldest and simplest method. Open-source projects and commercial vendors keep lists of domains that belong to temp-mail services, and a site rejects any address whose domain is on the list. It is fast, needs no network call, and catches the big, well-known services.

Its weakness is time. Temp-mail operators register new domains all the time precisely because sites use these lists, and even list vendors concede that new domains keep appearing (Abstract). A domain registered this morning is on nobody's list yet. Two details matter if you maintain your own list: match parent domains too (so a.tempbox.example is caught by tempbox.example), and update it automatically.

Method 2: mail-server (MX) matching

Every domain that receives email publishes MX records naming the servers that accept its mail. Here is the useful fact: a temp-mail service can register a hundred new domains cheaply, but it usually points them all at the same few mail servers, because running mail infrastructure is the expensive part. So instead of asking "is this domain on a list?", you ask "do this domain's mail servers belong to a known disposable service?".

That catches rotating domains on the day they appear. Castle has written up the same clustering idea in detail (Castle). A sketch of the check:

// Node.js: flag a domain whose mail servers belong to a known disposable service.
import { resolveMx } from 'node:dns/promises';

// Mail-server hosts you have seen behind known temp-mail domains (your own list).
const DISPOSABLE_MX_HOSTS = new Set(['mx.tempbox.example', 'in.burner-mail.example']);

async function mailServerLooksDisposable(domain) {
  try {
    const records = await resolveMx(domain);
    return records.some(r => DISPOSABLE_MX_HOSTS.has(r.exchange.toLowerCase().replace(/\.$/, '')));
  } catch {
    return null; // DNS failed: unknown, not "disposable"
  }
}

Three cautions. Big shared mail hosts serve millions of ordinary domains, so never treat a major provider's servers as disposable. A DNS timeout tells you nothing, so return "unknown" rather than blocking. And a domain with no MX records at all is not automatically a throwaway: some mail setups rely on other records, so treat it as a weak hint at most.

Method 3: patterns and context

Lists and mail servers judge the domain. Other checks judge the rest of the sign-up:

• Name patterns. Many temp-mail domains have tell-tale names ("tempmail", "10minute", "throwaway" and friends).
• Machine-made local parts. [email protected] doesn't look like anything a person chose. A random-looking address isn't proof, but it is a signal.
• Domain age. Some teams also look up when a domain was registered, since a days-old domain sending sign-ups is unusual. It needs a registration-data lookup and has more false alarms on new businesses.
• Sending a code. Verifying the inbox proves it works now; a temp inbox works for an hour, so it doesn't prove the address is lasting.

Why Gmail aliases are a different problem

Some "temporary email" services don't use their own domains at all. They hand out dotted and plus-tagged spellings of real Gmail inboxes. The domain is gmail.com, the mail servers are Google's, and every check above passes. Catching that takes inbox normalisation and a comparison with earlier sign-ups, covered in the Gmail dot trick.

What to do when you find one

On a newsletter form, a disposable address may be harmless. On a casino or sportsbook registration, where the account can claim money and you'll need to reach the player later, most operators refuse it. Show a short, neutral message ("please use a permanent email address") rather than accusing the user.

How InlineShield does it

InlineShield runs these checks for each sign-up it screens: known disposable domains and their parent domains, tell-tale temp-mail names, and, for domains on no list, matching the domain's mail servers against the infrastructure that known disposable services use. Major webmail providers are never matched that way. It also recognises random, machine-made addresses, and it never emails the player to find out. With the default rules, a disposable address, listed or matched through its mail servers, is blocked (verdict BLOCKED, recommendedAction: "block"). More in disposable email detection; for gaming operators, see bonus abuse prevention.