76,826 domains · updated just now

Is this a disposableemail address?

Check any domain or address against 76,826 known disposable email providers — instantly, and for free.

Your result will appear here
Try

No rate limit (unless abused)

The problem

What is a disposable email?

An inbox handed out instantly, with no signup, and thrown away minutes later. Services like mailinator.com or yopmail.com exist so someone can clear a "confirm your email" step without ever giving a real address.

🚪
Signups that vanish

Accounts abandoned the moment they are created, quietly inflating every growth number you report.

♻️
Trials on repeat

One person, a fresh address each time, taking the same free trial for as long as it works.

📭
Mail nobody reads

Onboarding sequences and receipts sent to an inbox that stopped existing an hour ago.

The API

One endpoint. One field.

A full address works too — everything before the @ is discarded before the lookup. Subdomains resolve through their parent, so inbox.mailinator.com is caught by mailinator.com.

false and 400 are different claims — checked and clean versus that was not a domain. A typo should never read as a clean address.

GET /c/<domain>
200{"disposable":false}clean
200{"disposable":true}disposable
400{"error":"…"}not a domain
Integrate

Drop it in

curl https://disposable.aops.network/c/mailinator.com
{"disposable":true}

curl https://disposable.aops.network/c/gmail.com
{"disposable":false}

Each example sends only the domain, so the local part never leaves your process. Treat a non-200 as "unknown" rather than failing the signup — a check that is down should not block a real user.

Under the hood

Built with Rust

The answer is 19 bytes of JSON, so a web framework would be the entire workload — parsing headers into a hash map costs more than the question does. So there isn't one. HTTP is parsed inline, both answers are byte-for-byte constants compiled into the binary, and serving a request allocates nothing at all.

No garbage collector means no pauses, so the tail latency you see is the network rather than the server. It builds to one statically linked binary carrying its own libc — which is why the Docker image needs no operating system inside it.

FROM scratch — the entire image
/server1,946,496
/database1,176,939
Docker image3.0 MB

Two files, no distribution, no package manager, no shell — nothing underneath collecting CVEs between releases.

The machine

What is answering you

One core of a mid-2010s Haswell, capped at 32 MB of RAM, behind a proxy that terminates TLS on the same two vCPUs. The container speaks plain HTTP on a port that is not even published.

The VPS
cpuHaswell @ 2.594 GHz
cores2 vCPU, no SMT
memory3.7 GB, no swap
disk38 GB
hypervisorKVM
Docker container caps
cpu1 of the 2 cores
memory32 MB
workers1, from the cgroup quota
memory used, idle5.9 MB
peak seen7.7 MB

The 5.9 MB is mostly the blocklist, plus the page held in three encodings. It grows under load — every open connection takes an 8 KB read buffer, so a few hundred at once add a couple of MB — and the highest ever seen is 7.7, less than a quarter of the cap. available_parallelism honours the cgroup quota, so the one-CPU cap means the server starts exactly one worker thread rather than one per host core; its own startup log says 1 workers.