Stopping Disposable Email Signups: A Developer's Guide

If you run a SaaS product, you've probably seen it: a wave of signups from mailinator.com, guerrillamail.com, 10minutemail.com, and hundreds of similar domains. These are disposable email services — inboxes that exist for minutes and then vanish. Some of your users have legitimate reasons to use them (testing, privacy). Most of the time, though, they signal something you don't want.

Why disposable emails hurt SaaS products

Trial abuse. Free trials exist because most people convert after experiencing the product. A user who signs up with a throwaway inbox has zero intent to convert — they're extracting the free tier and moving on. At scale, this quietly inflates your trial numbers and deflates your conversion rate, making both metrics unreliable.

Dead communication channels. Password resets, billing notices, usage warnings, and dunning emails all go nowhere. The user never sees them, then churns or files a support ticket about being "locked out." You pay for the email infrastructure either way.

Skewed analytics and dirty data. Cohort analysis, activation funnels, and LTV calculations all degrade when a meaningful slice of your user base is unreachable by design. Every downstream metric inherits the noise.

Reputation damage. Bounces from dead domains hurt your sender reputation with mailbox providers, which affects deliverability for your real users too.

None of this means every disposable signup is malicious. It means they're almost never worth the cost of keeping, and blocking them at the edge is cheap.

Detecting disposable emails with one API call

Maintaining your own list of disposable domains is a treadmill — new services appear weekly, and lists go stale. A lookup API keeps the detection current so you don't have to. The Glitch Store's email disposable check endpoint does exactly this:

curl

curl -X POST https://theglitchstore.com/api/email-disposable-check \\
  -H "Content-Type: application/json" \\
  -H "Authorization: Bearer $YOUR_API_KEY" \\
  -d '{"email":"test@mailinator.com"}'

The response tells you whether the domain is a known disposable provider:

{
  "email": "test@mailinator.com",
  "disposable": true,
  "domain": "mailinator.com"
}

Node.js

async function isDisposableEmail(email) {
  const res = await fetch('https://theglitchstore.com/api/email-disposable-check', {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
      Authorization: `Bearer ${process.env.API_KEY}`,
    },
    body: JSON.stringify({ email }),
  });

  if (!res.ok) {
    // Fail open or closed depending on your policy (see below)
    console.error(`Disposable check failed: ${res.status}`);
    return false;
  }

  const { disposable } = await res.json();
  return disposable;
}

// In your signup handler:
if (await isDisposableEmail(email)) {
  return res.status(422).json({
    error: 'Please use a permanent email address to sign up.',
  });
}

Call this during registration, before creating the account. It's a single synchronous request added to your signup path — fast enough that users won't notice.

False positives and tradeoffs

No blocklist is perfect, and how you handle mistakes matters more than the check itself.

• Corporate and privacy-forward domains. Some companies route mail through domains that resemble disposable services, and privacy-conscious users at real companies occasionally forward through aliasing services. If your market includes developers and security engineers, expect some friction here.
• Fail open vs. fail closed. If the API is unreachable during a signup, do you allow the registration or reject it? Failing open keeps legitimate users flowing but lets throwaways through; failing closed does the opposite. For most SaaS products, failing open on infrastructure errors while still rejecting confirmed disposables is the sane middle ground.
• Message matters. A generic rejection frustrates people. Tell users why — "we require a permanent email address" — and offer support contact for false-positive reports. Track those reports; if a specific legitimate provider keeps getting flagged, that's a bug worth reporting to the API maintainers.
• Softer alternatives. If hard-blocking feels too aggressive, use the flag as a risk signal instead: require email verification plus a card on file, cap features, or shorten the trial for flagged accounts. Blocking is one policy point on a spectrum, not the only option.

Pricing without commitment

The endpoint costs $0.01 per credit with no subscription — you pay per lookup, nothing recurring. That makes it easy to start conservatively (check only new signups) and expand later (re-screen existing accounts, gate API key creation) without renegotiating a plan or worrying about unused capacity.

At typical signup volumes, the cost is trivial next to what a month of trial-abuse-driven infrastructure and support load runs you.

Wrapping up

Disposable email blocking won't transform your business overnight, but it's a small, well-understood fix: cleaner data, fewer dead accounts, better trial metrics, and less email waste. One API call at the signup boundary, a clear error message for the rare false positive, and per-use pricing that matches your actual traffic. Ship it and move on to problems that are actually hard. " }