Disposable Email Detection: Flag It, Don't Block On It

Disposable email detection is the cheapest fraud signal to add and the easiest one to over-trust. A domain list, a set lookup, one boolean. It takes an afternoon, it flags real abuse, and teams routinely wire it straight into a hard block at signup.

That last step is where it starts costing money. This is what the signal actually contains, what it cannot contain, and what our own signup form does with throwaway inboxes, which has changed twice.

What the list actually is

Every disposable email checker, ours included, is a domain membership test. We pull the disposable-email-domains community blocklist, a little over nine thousand domains on 10 October 2026, refresh it every 24 hours, and hold it in memory as a set. An address is checked by taking everything after the @, lowercasing it, and testing the domain and its parent, so x.mailinator.com matches on mailinator.com.

That is the whole mechanism. It is worth being blunt about the consequences:

• It is a list, so it lags. New burner domains appear faster than any list absorbs them, and anyone motivated can register one for a few dollars.
• It fails open by design. If the feed is unreachable we keep serving the last copy; if it is empty we flag nothing. A dead feed must never turn into a wall of refused signups.
• It knows domains, not intent. This is the part that bites.

The masked-email problem

Ten-minute-mail and Apple's Hide My Email are structurally the same thing: a throwaway-looking address on a shared domain that forwards somewhere real. One is used to farm free trials. The other ships by default on every iPhone.

Community blocklists are assembled from domain patterns, not intent, so they cannot separate them, and lists differ on whether they try. One large community list names Firefox Relay, iCloud Hide My Email, SimpleLogin and addy.io among its burners. The list we load names one alias service, Blur’s opayq.com, and none of those four on 10 October 2026.

The users behind those addresses are not a marginal segment. They are the privacy-conscious, technically literate buyer — disproportionately the person evaluating a developer tool, and disproportionately the person who pays for one.

What our own signup does with throwaway inboxes

Maskbreak’s own signup form has changed its answer twice, and both turns are worth knowing before you copy either.

17 July 2026: the block came out. The form used to reject disposable domains outright. We removed the check because, as we read the list then, it also caught masked-email services, so it refused privacy-conscious people, the likeliest buyers of a developer tool, to stop an abuse case other limits already covered: the address still had to receive a one-time code, accounts and signup attempts were capped per network address, and the free allowance caps what an abusive account is worth.

7 October 2026: known throwaway inboxes are refused again. We decided that new accounts should be opened with a work address or a regular mail provider. Creating an account, or moving one to a new address, is now refused when the domain is on the public disposable list or on our own short list of temporary-inbox services that no public list carries yet. A company’s or a person’s own domain never goes on that list, however unused it looks, the major mailbox providers can never be refused, and existing accounts were left as they were. The refusal ends with a way out: “If this is your regular inbox, write to support@maskbreak.com.”

8 October 2026: email aliases too. Forwarding services, DuckDuckGo Email Protection, Firefox Relay, iCloud Hide My Email, SimpleLogin, addy.io, Proton Pass, Blur and 33mail among them, are refused as a class, from a list of our own, since the public list names only Blur. That cost is chosen, not missed: the privacy-conscious people the July change let in must now sign up with their real address.

The customer-facing signal did not change with either decision. In the API a disposable domain still only moves a decision, as the next section describes, and an alias address is not flagged at all unless the public list names its domain. Our signup is a gate we chose for our own free plan; for yours, the advice below stands.

Use it as an escalation, not a gate

The useful framing: a burner domain slightly raises the probability that a session is abusive. It never establishes it. So the signal should move a decision, not make one.

Concretely, in our pipeline a disposable domain adds 15 to the risk score, appends disposable_email to the reason list, and escalates a decision of allow to review. That is the entire effect. It cannot escalate review to block, and it cannot rescue a session that network or device signals already condemned.

The asymmetry is intentional. A burner address on an otherwise clean residential session is a mild curiosity. The same address arriving from a datacenter range through an antidetect browser, on a device already linked to four accounts, is a different story — and in that case the network and device signals are what carry the verdict, with the email merely confirming it.

In practice

Pass the address to evaluate() and read the result. The address is checked transiently — it is never stored or logged, and only the boolean survives on the event record.

let verdict;
try {
  verdict = await sentinel.evaluate({
    token,
    email: req.body.email,     // checked transiently, never stored
    accountId: req.user?.id,
  });
} catch (err) {
  return stepUp();             // no token or no answer: evaluate() throws
}

// verdict.email -> { disposable: true }
// verdict.reasons -> [..., 'disposable_email']
// verdict.decision -> 'review'  (escalated from 'allow')

if (verdict.decision === 'block') return refuse();
if (verdict.decision === 'review') return stepUp();   // OTP, card check, manual queue
return proceed();

The important line is the middle one. If review routes to the same place as block in your application, you have built a hard block with extra steps, and you refuse the people the July change above was made for without having decided to.

If you genuinely want burner domains refused outright — and for some businesses that is the right call — make it an explicit policy decision rather than a side effect. In the dashboard, disposable_email is one of the signals you can bind to a block action, which overrides the engine's decision while leaving engine_decision intact so you can still see what the pipeline actually thought.

When blocking is the right call

The test is whether the action has a real unit cost and no recovery path:

• Promotion and referral credit. Money leaves on redemption. Refuse burners here.
• Free trials that provision paid infrastructure. Each signup has a floor cost you cannot claw back.
• Anything granting immediate withdrawal or transfer. Irreversible by definition.

And where it is usually wrong:

• Ordinary account signup. The abuse is multi-accounting, and device linking answers that far more precisely.
• Login. The address already exists in your database; the domain tells you nothing new.
• Newsletter and waitlist forms. The cost of a fake row is a row. The abuse these forms do attract is the opposite of a burner: in email bombing, a script enters someone else's real address on newsletter forms across many sites, and the confirmations pile up in that person's inbox. No domain list sees it, because the address is genuine.

What it can never tell you

A burner domain does not mean fraud, and a reputable domain does not mean safety. The overwhelming majority of card testing, account takeover and bonus abuse we see arrives on ordinary Gmail, Outlook and corporate addresses, because attackers operating at any scale buy aged accounts rather than register throwaways.

Read the signal for what it is: weak evidence about intent to be contactable, useful in combination, dangerous alone. If disposable email is doing heavy lifting in your risk model, the model is thin — the questions that actually separate abuse from customers are whether the network is a proxy or datacenter exit, whether the browser is telling the truth about itself, and whether this device has been here before under other names.

On storing the address

A domain membership test needs no persistence. Ours is an in-memory set lookup: the address is not written to disk, not logged, and not retained after the request. Only the resulting boolean is kept on the event.

This is worth checking with any vendor you evaluate, because the default is often worse. Shipping every signup address to a third party and having it retained for months is a real data-protection exposure, and it is a poor trade for a signal this weak.