Stop Disposable Emails

Disposable Email Detection That Doesn't Go Stale

Q: How do I add disposable email detection to my signup flow?

Pass the signup email as one optional field on the /v1/evaluate call you already make. The response gains email.disposable, and a hit adds the disposable_email reason, raises the risk score, and escalates an 'allow' decision to 'review'. No separate email-validation API, no second vendor.

Q: What happens when a burner email is detected?

The response carries email.disposable: true, the reasons array gains disposable_email, the risk score rises, and an 'allow' decision escalates to 'review' — it does not auto-block. Whether a burner address means 'ask for a different email', 'limit the trial', or 'let it through' is your policy, in your code.

Q: What if the domain feed goes down — will Gmail get blocked?

No. The feed is signal-only and fail-open by design: it can only add the disposable_email signal, never override anything else, and an outage means Sentinel keeps using the last good copy. If the feed ever came back empty, nothing would be flagged. There is no failure mode in which a real mail provider gets blocked by the feed.

Q: Do you store the email addresses I send?

No. The address is compared in memory against the disposable-domain list and immediately discarded — only the resulting true/false flag is stored with the evaluation record, never the address itself. This is written into our privacy policy, not just the docs.

Q: Are masked-email services like Firefox Relay flagged too?

Some are — the community-maintained feed includes several relay and hide-my-email services alongside true burners, and those users are often privacy-conscious real customers. That is exactly why a hit escalates to 'review' instead of auto-blocking: you decide whether masked email is acceptable for your product.

Burner domains are registered faster than any bundled blocklist ships. Sentinel checks the signup email against a continuously refreshed feed — one optional field on the evaluate call you already make, checked in memory and never stored.

[ Start Free — No Credit Card ] [ View API Docs ]

< 40msResponse time globally

Free1,000 requests/hour — no card, no expiry

1Optional field to add the check

0Email addresses stored — ever

The Problem

What you're up against

Burner domains born daily

Disposable-mail operators register fresh domains continuously, precisely because static blocklists exist. The domain that soaks your verification emails today may not have existed when your bundled list last shipped.

Verification proves nothing

A burner mailbox receives your OTP and clicks your link just fine — that's the whole product. Email verification confirms the mailbox exists, not that a person intends to stay past the free tier or first promo.

The blocklist you bundled is rotting

Most teams pin an open-source domain list at build time and forget it. Every day after deploy it catches less, and updating it means a dependency bump, a review, and a release — for data that changes daily.

One human, fifty addresses

Email uniqueness is your weakest identity check. Anyone with a burner service has unlimited "unique" identities — so trial limits, promo caps, and one-account rules quietly stop meaning anything.

How Sentinel Helps

What Sentinel does for you

Add disposable email detection with one optional field on the /v1/evaluate call you already make
Check against a continuously refreshed feed of thousands of burner domains — not a snapshot
Signal-only and fail-open: a feed outage can never block a legitimate mail provider
The address is checked in memory and never stored or logged — only a true/false flag persists
Cross-browser device linking ties the fifty burner-address accounts back to one machine

Case Study

97%

reduction in fake account registrations in our illustrative composite scenario of a fintech targeted within days of launching a signup bonus

[ Read Full Case Study ]

Integration

Where the check goes

Disposable email detection is not a separate API. Pass the address the visitor typed as an optional email field on the same /v1/evaluate call that scores the device and network — the response gains email.disposable, and a hit adds the disposable_email reason, raises risk_score, and escalates an allow decision to review.

// One optional field adds the burner-email check to the verdict you already get
const verdictRes = await fetch('https://sntlhq.com/v1/evaluate', {
  method: 'POST',
  headers: {
    'Authorization': 'Bearer ' + process.env.SENTINEL_KEY,
    'Content-Type': 'application/json'
  },
  body: JSON.stringify({
    token: req.body.sentinel_token,
    email: req.body.email  // optional — checked transiently, never stored
  })
});
const risk = await verdictRes.json();
if (risk.email && risk.email.disposable) {
  // 'disposable_email' is now in risk.reasons; allow was escalated to review
  return res.status(422).json({ error: 'Please use a permanent email address' });
}

See a verdict before you integrate

Don't take the docs' word for it — run your own connection through the live scanner on the homepage, or paste any IP into the free IP lookup tool. Both are keyless previews with a reduced signal set — the full API adds device intelligence, multi-account linking, and the email check.

Under the Hood

The signals that matter here

A feed, not a snapshot. Sentinel checks the domain against a continuously refreshed feed of thousands of known disposable-mail domains, matching the exact domain and one parent level (so mail.burner.example is caught when burner.example is listed). A burner domain registered this morning to soak verification emails is flagged the same day — without you shipping a dependency bump.

Signal-only, fail-open by design. The feed can only ever add the disposable_email signal — it never overrides network or device intelligence, and it never blocks on its own. If the feed source goes down, Sentinel keeps the last good copy; if it ever came back empty, nothing would be flagged. There is no failure mode where an outage blocks Gmail, Outlook, or any real mail provider.

The address is never stored. The email is compared in memory and immediately discarded — only the resulting true/false flag is kept on the evaluation record, never the address itself. That's a commitment in our privacy policy, not just a docs footnote, and it's why you can send the field without expanding your data-processing surface.

The human behind fifty burner addresses. Every burner address looks unique — the hardware underneath doesn't. Sentinel's cross-browser device ID, its "times seen" counter, and per-customer account linking tie signup #2 through #50 back to the same machine, even across fresh browser profiles and rotating proxies. Linking is hash-only and scoped to your account: you see your own repeat offenders, nothing else.

FAQ

Common questions

How do I add disposable email detection to my signup flow?

Pass the signup email as one optional field on the /v1/evaluate call you already make. The response gains email.disposable, and a hit adds the disposable_email reason, raises the risk score, and escalates an 'allow' decision to 'review'. No separate email-validation API, no second vendor.

What happens when a burner email is detected?

The response carries email.disposable: true, the reasons array gains disposable_email, the risk score rises, and an 'allow' decision escalates to 'review' — it does not auto-block. Whether a burner address means 'ask for a different email', 'limit the trial', or 'let it through' is your policy, in your code.

What if the domain feed goes down — will Gmail get blocked?

No. The feed is signal-only and fail-open by design: it can only add the disposable_email signal, never override anything else, and an outage means Sentinel keeps using the last good copy. If the feed ever came back empty, nothing would be flagged. There is no failure mode in which a real mail provider gets blocked by the feed.

Do you store the email addresses I send?

No. The address is compared in memory against the disposable-domain list and immediately discarded — only the resulting true/false flag is stored with the evaluation record, never the address itself. This is written into our privacy policy, not just the docs.

Are masked-email services like Firefox Relay flagged too?

Some are — the community-maintained feed includes several relay and hide-my-email services alongside true burners, and those users are often privacy-conscious real customers. That is exactly why a hit escalates to 'review' instead of auto-blocking: you decide whether masked email is acceptable for your product.

Catch burner emails without storing a single address

Free tier: 1,000 requests/hour. No card, no expiry. One optional field adds the check to every signup.

[ Get Started Free ] [ Talk to Sales ]

Stop other fraud vectors

Stop Fake Signups Stop Trial Abuse Stop Multi-Accounting