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.

Residential Proxy Detection After Rotation

Residential proxies are difficult to catch with a denylist because the address is the least stable part of the connection. A request can leave through a normal-looking ISP today and a different household tomorrow.

Why IP reputation alone misses the abuse

Reputation databases are useful context, but a clean residential IP does not prove a clean session. Proxy pools rotate addresses to dilute complaints and distribute velocity.

Signals that remain useful

Device continuity: the same device appearing across many accounts matters more than the current IP.
ASN and network context: consumer access can still be unusual when paired with proxy infrastructure.
Velocity: account creation, checkout, and login bursts reveal automation.
Session consistency: timezone, language, headers, and browser capabilities should tell a coherent story.

Build a graduated response

Use detection to add evidence, not to create a universal hard block. Mixed evidence can trigger verification; multiple independent indicators can justify a block.

Bottom line

Residential proxy detection is a correlation problem. IP intelligence starts the investigation; device, velocity, and session signals finish it.

Residential Proxy Detection: Signals That Survive Rotation

Why IP reputation alone misses the abuse

Signals that remain useful

Build a graduated response

Bottom line