Disposable email checker that updates daily, not yearly.
disposable domains in the blocklist · ● updated daily
The disposable-email-domains npm package updates once a quarter. vrfymail's database adds new throwaway providers within hours of cert issuance — your moat compounds as traffic grows.
How the database stays current
Five independent channels feed the domains table. Each one catches what the others miss.
- 1.Bundled seed~121k entries from the
disposable-email-domainsnpm package. The floor. - 2.Daily scrapersPolls 1secmail / mail.tm / mail.gw public APIs at 24h cadence and captures every inbox domain they hand out. Rows tagged
source: "scraper:<provider>". - 3.Spamhaus DBL (live)Every verify call that probes Spamhaus DBL and gets a hit persists the domain to the table. Promotes from "this customer hit it" to "we now know about it" automatically.
- 4.Customer-consensus promotion≥3 distinct customers POST
hard_bounceorspam_complainton the same domain within 30 days →is_spam_trap=1. Free-mail providers excluded. - 5.CT-log scannerHourly polls of crt.sh for newly-issued TLS certs matching
temp/throwaway/minute/burner-mailpatterns. Catches the next disposable provider before they have customers.
One endpoint, one verdict
POST the email to /v1/check. If the domain is in the disposable database (or any of the four other lists), the response carries disposable: true and reason: "disposable".
curl https://vrfymail.com/v1/check \
-H "Authorization: Bearer vk_live_..." \
-d '{ "email": "user@mailinator.com" }'{
"result": "undeliverable",
"reason": "disposable",
"reason_message": "This email provider doesn't deliver mail reliably. Please use a real address.",
"disposable": true,
"spam_trap": false,
"mx_found": true,
"score": 0.0,
"trap": { "listed": false, "lists": [], "code": null }
}The npm package was updated 8 weeks ago.
New disposable providers spin up daily. A throwaway domain registered this morning, issued a TLS cert this afternoon, advertised on a Telegram channel by evening — and your signup form accepts it tomorrow because the npm package you imported hasn't seen it.
vrfymail's CT-log scanner catches that domain within hours of cert issuance. Customer-consensus promotion catches the ones the scanner misses — three customers reporting the same hard-bounce promotes the domain globally in 24-72h.
The math: a static list at 121k entries vs a live database at 269,933+. The delta is everything ZeroBounce, the npm package, and your hand-curated blocklist file haven't caught yet.
- Static list Disposable lag of 4-12 weeks. Misses every provider that launches between releases.
- DBL only Catches Spamhaus-listed domains. Misses temp-mail providers Spamhaus doesn't list.
- vrfymail All five sources at once. New domain → in database within hours. Customer hits → consensus-promoted within days.
Other signals on the same call
Every /v1/check request runs the disposable lookup alongside spam-trap detection, B2C strict-mode flags, role-account detection, MX checks, and your per-customer bounce overlay. One call, every signal, 50ms p50.
Building a signup form with an AI coding tool? The AI builders hub has copy-paste integrations for Cursor, Claude Code, v0, Bolt.new, and seven more — all wired against this same disposable database.
How the database actually works
Investigative posts that go deeper than the API surface — proprietary data from the production detection table.
Disposable email checker API, answered
- How is the disposable list different from the npm package?
- The disposable-email-domains npm package is a static JSON file updated by maintainers when they get around to it — typically once a quarter, sometimes longer. vrfymail's database starts with that seed and adds four live channels: daily scrapers polling 1secmail/mail.tm/mail.gw, every Spamhaus DBL hit on a verify call, customer-consensus promotion (≥3 customers report = global flag), and a CT-log scanner finding new throwaway providers within hours of TLS cert issuance.
- How fresh is the data — what's the worst-case lag for a new disposable provider?
- CT-log scans run hourly. A throwaway provider issuing a TLS cert today is in our database before they have customers. The disposable-domains npm package took 8+ weeks to add the same domain in our latest spot check. For customer-consensus promotions, 3 distinct customers reporting a hard-bounce on a domain within 30 days promotes it globally — typically within 24-72h of first appearance.
- What's in the response — boolean, or actual signal?
- Both. The top-level disposable field is a boolean for simple checks. The full response includes reason (machine code like disposable, no_mx, syntax) and reason_message (end-user copy). For deeper signals like spam-trap listing, the trap object exposes which list flagged the domain (spamhaus_dbl) and the listing code (.2 spam, .4 phish, .5 malware) — most APIs flatten this to a boolean and lose the why.
- Does the API charge me when the email is disposable?
- Yes — disposable verdicts are billed (one credit). Only unknown verdicts get refunded via refundUsage(). The reasoning: disposable detection is a real positive signal, the kind you'd pay for in a verification API. unknown means we couldn't decide, which isn't a service we should charge for.
- What about catch-all domains and free-mail providers like Gmail?
- Free-mail providers (Gmail, Outlook, Yahoo, etc.) are explicitly excluded from the disposable list — flagging Gmail as disposable would break every signup form on the internet. Catch-all detection is separate from disposable detection: a catch-all returns result: deliverable with reason: catch_all_domain (verifiable but not mailbox-confirmed). The strict mode flag set is what catches Gmail-style aliases like plus addressing and dot tricks.
269,933+ blocked. Self-growing. One call.
5,000 verifies/month free, no card. Paid plans start at $9/mo for 10,000 — see pricing.
Get my API key