How to detect and block disposable email addresses in your signup flow

The problem: throwaway emails are free, yours aren't

Anyone can get a working inbox in two seconds from Mailinator, 10 Minute Mail, Temp-Mail or thousands of similar services. People use them to grab free trials repeatedly, bypass "verify your email" gates, and sign up for things they never intend to return to. The cost lands on you: verification emails sent to inboxes that expire in minutes, inflated signup metrics, fraud rings creating accounts in bulk, and a mailing list full of addresses that hard-bounce and damage your sender reputation.

Maintaining your own blocklist doesn't work for long. New disposable domains appear daily, and popular services rotate domains specifically to evade static lists. You need a list that someone else keeps current — which is exactly what this API wraps, along with syntax validation, live DNS checks, and alias normalization.

Step 1: call `/check` at signup

Before you create the account, make one request:

GET /check?email=test@mailinator.com

The response tells you everything about the address in one pass: whether the syntax is valid, whether the domain appears in the 160,000+ disposable-domain list, whether an MX lookup confirms the domain can actually receive mail, whether it's free webmail (Gmail, Outlook, Yahoo), whether it's a role account (admin@, support@, info@), and the canonical form of the address with Gmail dots and +tags stripped.

If you only need a yes/no answer and want the smallest possible response, /is-disposable returns just the disposable verdict. Use /normalize when you already trust the address and only want the canonical form for deduplication.

Step 2: decide what each flag means for you

Don't treat every flag as a hard block — they mean different things:

Disposable: reject outright, or allow signup but withhold the free trial until they verify a real address. Rejecting with a clear message ("please use a permanent email") converts better than a silent failure.
No MX records: the domain cannot receive mail at all, so any verification email is guaranteed to bounce. Safe to reject — this also catches typos like gamil.com.
Role account: fine for a B2B contact form, questionable for a personal account. Many teams allow these but exclude them from marketing sends.
Free webmail: usually fine to accept, but useful as a signal if your product is B2B and you want to prioritize company-domain leads.

Step 3: dedupe with the canonical email

This is the step most signup flows skip. Gmail delivers john+trial1@gmail.com, j.o.h.n@gmail.com and john@gmail.com to the same inbox, so one person can pass email verification for unlimited "unique" accounts. Store the canonical email the API returns alongside the address the user typed, and put a uniqueness constraint on the canonical value. The user keeps their preferred formatting; your database knows it's one inbox.

Edge cases to watch for

Fail open, not closed. If your call times out, let the signup through and re-check asynchronously. A validation hiccup should never cost you a real user.
Check before the verification email, not after. Disposable inboxes receive mail fine — a verification link proves nothing. The point is to catch the address before you send anything.
Don't strip +tags yourself for every domain. Subaddressing rules vary by provider; some domains treat + as a literal character. Let /normalize apply provider-specific rules.
Re-check old lists periodically. Domains get added to the disposable list over time, so addresses that passed a year ago may be known-throwaway now. The /stats endpoint tells you how large and fresh the domain list is.

FAQ

Does this send an email to the address? No. Validation is done via syntax rules, the domain list, and DNS MX lookups — the mailbox owner never sees anything.

Will it block Gmail or Outlook users? No. Free webmail is flagged separately from disposable domains, so you decide how to treat each.

What about brand-new disposable domains? The domain list is continuously maintained, and the MX check catches domains that were registered yesterday and can't actually receive mail.

Where should the check live? Server-side, in the same request handler that creates the account. Client-side checks can be bypassed by anyone with curl.

Copy-paste code

Calling disposable-email-detector-email-validator.p.rapidapi.com — replace YOUR_RAPIDAPI_KEY with your key.

cURL

curl --request GET \
  --url 'https://disposable-email-detector-email-validator.p.rapidapi.com/check?email=test%40mailinator.com' \
  --header 'X-RapidAPI-Key: YOUR_RAPIDAPI_KEY' \
  --header 'X-RapidAPI-Host: disposable-email-detector-email-validator.p.rapidapi.com'

Python

import requests

url = "https://disposable-email-detector-email-validator.p.rapidapi.com/check"
querystring = {"email": "test@mailinator.com"}
headers = {
    "X-RapidAPI-Key": "YOUR_RAPIDAPI_KEY",
    "X-RapidAPI-Host": "disposable-email-detector-email-validator.p.rapidapi.com",
}

response = requests.get(url, headers=headers, params=querystring)
print(response.json())

JavaScript (fetch)

const url = 'https://disposable-email-detector-email-validator.p.rapidapi.com/check?email=test%40mailinator.com';
const options = {
  method: 'GET',
  headers: {
    'X-RapidAPI-Key': 'YOUR_RAPIDAPI_KEY',
    'X-RapidAPI-Host': 'disposable-email-detector-email-validator.p.rapidapi.com',
  },
};

const response = await fetch(url, options);
console.log(await response.json());

Node.js (axios)

import axios from 'axios';

const options = {
  method: 'GET',
  url: 'https://disposable-email-detector-email-validator.p.rapidapi.com/check',
  params: {email: 'test@mailinator.com'},
  headers: {
    'X-RapidAPI-Key': 'YOUR_RAPIDAPI_KEY',
    'X-RapidAPI-Host': 'disposable-email-detector-email-validator.p.rapidapi.com',
  },
};

const { data } = await axios.request(options);
console.log(data);