Is disposable email detection worth adding at all?

Yes, as an input. A burner domain is a genuine signal that the person does not intend to be reachable, and on abuse-prone actions it correlates with trial farming and multi-accounting. The mistake is treating it as a verdict. Used as one escalation among several it costs you nothing; used as a gate it silently refuses privacy-conscious customers who are paying you money.

Why do masked-email services show up on burner lists?

Because structurally they look identical. DuckDuckGo Email Protection, Firefox Relay and iCloud Hide My Email all hand the user a throwaway-looking address on a shared domain that forwards to a real inbox. Community blocklists are built from domain patterns, not from intent, so relays land in the same file as ten-minute-mail. The domain cannot tell you which one you are looking at.

How current are disposable domain lists?

The widely used community list refreshes continuously and we re-pull it every 24 hours, but the ceiling is inherent: new burner domains appear faster than any list absorbs them, and an attacker who cares can register one. Treat coverage as good-not-complete. A list that flags nothing is failing open, which is the correct failure mode; a list you trust absolutely is the problem.

Should the email address be stored to check it?

No, and you should ask any vendor that does. The check is a domain lookup against an in-memory set, so the address never needs to be persisted, logged, or sent anywhere. We keep only the boolean result on the event record. Storing raw signup addresses in a fraud vendor's logs creates a data-protection liability that the signal does not come close to justifying.

When is it right to hard-block on a burner domain?

When the action has a real unit cost and no recovery path: redeeming a promotion, claiming free credit, or starting a trial that provisions paid infrastructure. There the cost of a false negative is money out the door and the cost of a false positive is one annoyed user who can retry with another address. For ordinary signup or login, blocking is almost always the more expensive error.

Detect Account Takeover Before the Login

Account takeover rarely begins with a dramatic exploit. It begins with a valid password used from a device, network, and automation stack the account has never seen. That makes password-only rules a poor boundary: by the time the credential is proven stolen, the attacker is already inside the login flow.

What to check before authentication completes

Evaluate the request before issuing a session, but keep the decision proportional to the evidence. Network intelligence can identify datacenter space, VPN exits, Tor, and residential proxies. Device signals can reveal automation, tampering, and links to other accounts. Velocity adds the missing context: one unfamiliar login is normal; hundreds of unfamiliar logins in a minute are not.

Network: classify the source without treating a VPN as proof of abuse.
Device: look for automation and reuse across accounts.
Velocity: compare attempts by account, device, IP, and ASN.
History: compare the current request with the account's normal pattern.

Use step-up authentication instead of a blanket block

A new country or a privacy relay should not strand a real customer. Combine signals into tiers: allow familiar sessions, ask for an additional factor when the evidence is mixed, and block only when several independent signals agree.

const verdict = await sentinel.evaluate({ token, accountId, ip, device });
if (verdict.decision === 'block') return deny();
if (verdict.decision === 'review') return requireWebAuthnOrOtp();
return createSession();

Bottom line

Account takeover detection works best as a layered pre-authentication decision, not as a second password check.

How to Detect Account Takeover Before the Login Succeeds

What to check before authentication completes

Use step-up authentication instead of a blanket block

Bottom line