Skip to content

How to check if an email address is disposable (with and without code)

· 5 min read · Disposable email

To check if an email address is disposable, take the domain after the @, reduce it to the registrable domain (mail.yopmail.fr becomes yopmail.fr), and look it up in a disposable-domain list such as the community-maintained one on GitHub. If it's listed, the address is disposable. If it isn't, a quick MX lookup and a search for the domain usually settle the rest; in code, a list lookup or an API call does all of this in one step.

Below are the manual checks first (no code, a couple of minutes per address), then the code and API options, then a checklist you can paste into a runbook.

Manual check: four steps, no code

Use this when you're reviewing a handful of suspicious signups, a support ticket, or a lead someone flagged.

1. Get the registrable domain

Take everything after the last @. Lowercase it. If it has extra labels in front, strip them down to the part someone actually registers: inbox.mailinator.com is mailinator.com, but example.co.uk stays example.co.uk because co.uk is a public suffix. Lists store registrable domains only, so searching for a subdomain will miss.

2. Search the public disposable list on GitHub

The disposable-email-domains repository keeps its list in one plain-text file, disposable_email_blocklist.conf, with one domain per line. Open the file on GitHub and use your browser's find (or GitHub's file search) for the exact domain. It holds roughly 9,900 domains as of 2026 and is updated several times a week.

  • Listed: the address is disposable. Done.
  • Not listed: keep going. The list only knows about domains someone has reported, and throwaway services register new ones all the time.

3. Look up the MX records

MX records say which servers accept mail for the domain. From a terminal:

dig +short MX mailinator.com
# 1 mail.mailinator.com.
# 1 mail2.mailinator.com.

nslookup -type=mx example-domain.com   # Windows equivalent

What to look for:

  • No MX and no A record at all: the domain can't receive mail. The address is fake or mistyped, which is a different problem from disposable but has the same outcome.
  • MX pointing at a known disposable service's mail host (the domain's own name or a sibling of something already on the list): strong sign it's another front for the same service.
  • MX pointing at Google, Microsoft or a normal hosting provider: probably a real mailbox, personal or business.

MX alone never proves an address is disposable. It tells you where mail goes, and a lot of throwaway services run their own perfectly normal mail servers. The details, including null MX records, are in checking MX records to see if a domain can receive email.

4. Search the domain and visit it

Search for the domain name in a search engine and open the website, if there is one. A disposable service usually shows itself immediately: a homepage that hands you a random inbox, "temporary email" or "10 minute mail" in the title, a list of alternative domains in the footer. A company domain shows a company.

A domain with no website, no search results and a working mail server is not proof of anything, but it's worth a second look.

Also look at the part before the @

A disposable domain is not the only throwaway signal. Strings like ccjxx90sze@gmail.com are machine-generated, and the domain is a normal webmail provider, so steps 2 to 4 will all come back clean. If the local part looks like keyboard noise, treat it with the same suspicion, but be careful: some real names and handles look odd too.

In code: three options

Option What it catches What it misses Upkeep
Bundle the GitHub list Listed disposable domains, offline, sub-millisecond New domains, random local parts You must refresh the list (weekly is reasonable)
List plus DNS check Above, plus domains that can't receive mail Same as above List refresh, DNS timeouts to handle
Lookup API Listed domains, random local parts, category (free, company, etc.) New domains until the list catches up An API key and a fail-open path

Option 1: the list in your own code

Download disposable_email_blocklist.conf, load it into a set at startup, and check the registrable domain against it. We wrote this up end to end for Node.js and Express and for Python (Django and FastAPI), including the Public Suffix List step and how to keep the list fresh without a deploy.

Option 2: one API call

If you'd rather not own the list, call an API. pingutil's lookup endpoint takes an email and returns a category and a verdict. With skip_enrichment: true it skips company enrichment and answers fast.

curl -s -X POST https://pingutil.com/v1/lookup \
  -H "Authorization: Bearer $PINGUTIL_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "input": "someone@mail.yopmail.fr", "skip_enrichment": true }'
{
  "domain": "yopmail.fr",
  "category": "disposable",
  "verdict": { "is_spam": true, "low_trust": false, "reason": "disposable_domain" }
}

(Response trimmed.) The fields to act on:

  • category: "disposable" means the registrable domain is on the disposable list. pingutil syncs from the same community list weekly.
  • verdict.is_spam is true for disposable domains and also for randomized local parts on any domain. That's usually the one field to block on.
  • verdict.reason tells you which: disposable_domain or randomized_local_part, among others.

You can try addresses without a key in the live demo (rate-limited per IP, fine for spot checks). For production, get a free key; it's limited to 60 requests per minute and there's no bulk endpoint, so it suits per-signup checks rather than scanning a million-row table. Full field reference is on the API page.

Two rules for any network check in a signup path: set a short timeout (two seconds is plenty), and fail open. If the check can't run, let the signup through and log it. An outage on someone else's server shouldn't stop real people from creating accounts.

What a "not disposable" answer does not tell you

Be clear about the limits of every method above, including ours:

  • New domains slip through. A throwaway service that registered a domain this morning isn't on any public list yet.
  • Privacy relays aren't disposable. Apple Hide My Email, Firefox Relay and SimpleLogin forward to a real inbox, but their addresses look random. pingutil can flag some of them as randomized. Read why relay addresses are not disposable email before you block them.
  • It says nothing about whether the mailbox exists. A real gmail.com domain with a made-up local part passes every domain check. Only a confirmation email proves someone controls the inbox.

Checklist

  • Reduce the address to its registrable domain before checking anything.
  • Search the domain in disposable_email_blocklist.conf on GitHub (or your copy of it).
  • Run dig +short MX <domain>; no MX and no A record means mail can't arrive.
  • Search the domain and open its website; temporary-inbox services are obvious on sight.
  • Look at the local part for machine-generated strings.
  • In code: refresh any bundled list weekly, or use an API with a short timeout and a fail-open path.
  • Decide what "disposable" means for you: block outright, or flag the account and limit what it can do.

Questions people ask

Is there a free way to check if an email address is disposable?
Yes. Take the domain after the @ and search for it in the community disposable-email-domains list on GitHub, which holds roughly 9,900 domains as of 2026. If it is listed, the address is disposable. If it is not, the domain may still be a new throwaway service the list has not caught yet.
Can I tell if an email is disposable just by looking at it?
Sometimes. Well-known services like mailinator.com or yopmail.com are easy to recognise, and a random string like ccjxx90sze@ is a strong hint. But many disposable services use ordinary-looking domains, so check the domain against a list rather than trusting your eye.
Are Apple Hide My Email and Firefox Relay addresses disposable?
No. They are privacy relays that forward to a real, long-lived inbox. They often look random, so a checker that scores randomness can flag them, but the person behind them is usually a real user.