Disposable email checker

Paste a list — one email or domain per line — and see which ones come from temporary providers. Checks against 1,400+ known burner domains.

Why disposable domains matter more than you think

A list padded with burner addresses looks healthy on paper and behaves badly in production. Those recipients never open, never click, and eventually hard-bounce when the provider retires the mailbox. Mailbox providers read that pattern as a signal about the sender, not about the address. Enough of it and your transactional email starts landing in spam for the customers who actually wanted it.

The usual mistake is treating this as a manual step. Someone eyeballs a batch during onboarding review, catches the obvious ones, and misses the rest. Detection belongs in the pipeline, at the moment the address is submitted.

How detection works

The service keeps a curated list of disposable providers and matches the domain exactly. Matching happens before MX resolution, so a burner domain that has perfectly valid mail servers, which most of them do, is still flagged. That ordering is deliberate. Checking MX first would let the whole category through.

What the checker will not catch

• Subaddressing tricks. you+alias@gmail.com is a normal Gmail feature, not a burner, and plenty of legitimate users rely on it.
• Self-hosted throwaway domains. Someone who buys a cheap domain and points it at a catch-all inbox is invisible to a list-based approach.
• Catch-all corporate domains. These accept every address at the domain, so a mailbox-level answer is meaningless. Flagging them as invalid produces false negatives on real customers.

For the third case you need a mailbox-level probe, which is a different and slower check. The API exposes it as the smtp field.

Under the hood

Each line is sent to the verification endpoint. The relevant fields come back in checks.disposable, reason and score:

curl "https://mailprobe.kevin-c0319.workers.dev/v1/verify?email=bob@yopmail.com"

{
  "valid": false,
  "deliverable": false,
  "reason": "disposable",
  "score": 75,
  "checks": { "syntax": true, "disposable": true, "role": false, "mx": { "ok": true } }
}

Note the score of 75 alongside valid: false. The address itself is well-formed and the domain resolves. Only the provider classification fails it. Branching on valid alone would have accepted it.

Get a free API key

FAQ

Is this the same list the API uses?

Yes. The page calls the API directly, so the classification you see here is the classification your backend would get.

Why did the check stop partway through my list?

Anonymous requests are capped per hour to keep the endpoint usable for everyone. A free key raises that to 1,000 checks a month, and paid plans go higher.

Should I block every disposable address?

Rarely as a hard block. Most teams flag them, then decide per flow: reject on free trials, accept on newsletter signup, and always accept when the customer is paying. Hard blocks cost you real users who happened to sign up with a burner address they will abandon anyway.

Can I run this in bulk from a script?

The batch endpoint takes up to 20 addresses per call and counts against the same monthly quota. Above 20, page through it.