Today we are doing two things at once. We are publishing github.com/BillionVerify/disposable โ the most complete open-source disposable email domain database we are aware of, updated every day โ and we are unbundling disposable detection from the rest of our verification pricing: on the BillionVerify API, disposable hits cost zero credits, full stop, regardless of which plan you are on for the rest of your verification work. If you have ever pulled a list of leads from Apollo, scraped contacts off Google Maps, or run a cold email campaign and watched your bounce rate creep above two percent, this announcement is for you. Disposable inboxes are the single most preventable cause of sender-reputation damage in B2B outreach, and we believe the data that catches them should be a public utility.
Key takeaways
| Point | Details |
|---|---|
| The repository is live and free | BillionVerify/disposable is MIT-licensed, daily-updated, and contains the most comprehensive open list of disposable, temporary, and throwaway email domains we have been able to assemble. |
| Our API charges zero credits for disposable hits | Whether you call /verify/disposable, /verify/single, /verify/bulk, or /verify/file, any address that resolves to a disposable domain costs zero credits. You still need a BillionVerify account and an API key โ and the rest of email verification (catch-all, SMTP probing, full mailbox validation) is billed under our normal plan pricing โ but the disposable check itself is free, no matter which plan you are on. |
| Disposable detection is a data problem, not an algorithm problem | The reason most verifiers miss new disposable providers is not bad code โ it is stale lists. Daily-refreshed domain coverage is the only durable defense. |
| Cold email and lead-scraping workflows are the highest-risk surface | Google Maps scrapes, Apollo exports, B2B agency campaigns, and local-business outreach pull from sources where disposable contamination runs hot. Verifying before you send is the difference between a healthy domain and a burned one. |
| Open and free changes the competitive baseline | Every major verification vendor treats disposable detection as a billable line item. We are unbundling it. |
Why we are doing this
Email is the only channel where the cost of a mistake is asymmetric. A single batch sent to a contaminated list does not just waste that batch โ it teaches mailbox providers that your domain is the kind of sender that mails dead inboxes. Recovery from that signal takes weeks. Prevention takes a domain lookup that fits inside two milliseconds.
The economics of that prevention have been distorted for years. The disposable-domain list itself โ a flat file of strings โ is being sold as part of premium tiers by vendors who scraped most of it from open repositories in the first place. Meanwhile the open repositories that do exist are maintained part-time by volunteers who, however heroic, cannot keep pace with the rate at which new disposable services spin up. We sit on top of one of the larger commercial verification pipelines on the internet. We see new disposable domains the day they go live, because our customers send to them. There is no reason that data should sit behind a paywall.
So we are giving it away on both ends: the raw list as an open repository, and the lookup as a free layer of our hosted API. Pick whichever fits.
What disposable email detection actually is
Email verification, as a discipline, is a stack of cheap checks layered in front of expensive ones. Syntax validation comes first โ does the address parse, are the characters legal, is the length under 254. Then domain checks โ does the domain exist in DNS, does it have MX records pointing somewhere that accepts SMTP. Then mailbox-level checks โ does the server actually accept mail to that local part, or does it reject. Each layer is more expensive and more revealing than the one before.
Disposable detection sits between domain validation and SMTP probing, and it is the single highest-leverage check in the entire stack. The reason is simple: SMTP probing against a disposable domain often returns "accepted" because the temporary inbox does exist โ for a few hours. Your verifier marks the address valid. Your campaign platform marks it delivered. Then the inbox expires, your message lands on a server that no longer has a recipient, and you get a hard bounce attributed back to your sending domain. SMTP cannot save you here because SMTP is telling the truth. The inbox really did exist at the moment of the check. The problem is that "exists right now" is not the same as "will exist when your sequence reaches step three."
The only signal that catches this reliably is the domain itself. If yopmail.com is on the list, every address at yopmail.com is disposable, full stop, regardless of what the mailbox server says. There is no clever algorithm that improves on the list. There is only the list, and how complete and current it is.
This is why "disposable detection" in practice reduces to "do you have the right domain database." Pattern matching on local parts helps slightly โ addresses with twelve random characters are suspicious โ but pattern matching alone produces unacceptable false-positive rates on legitimate human emails. The list is everything.
The open-source landscape today
We are not the first project to publish a disposable domain list. We want to be clear about that, because the existing community deserves credit and because choosing the right tool depends on understanding what is already out there.
The most widely used open list is ivolo/disposable-email-domains, originally maintained by Ivo Lukaฤ and now collectively stewarded. It is a JSON file of a few thousand domains, mostly the well-known providers like Mailinator, Guerrilla Mail, 10MinuteMail, and YOPmail. It is excellent as a baseline and has been embedded in countless libraries. Its limitation is coverage: the list captures the long-running, brand-name disposable services but lags significantly on the long tail of newer providers, which is where most contamination actually originates today.
FGRibreau/mailchecker is the most polyglot option, with bindings in roughly twenty languages and a domain list assembled from multiple sources. It is broader than ivolo's list and is reasonably well-maintained, but it bundles disposable detection with package distribution, which means updates ship at the cadence of language-specific releases rather than the cadence of the underlying threat.
Other community efforts include 7c/fakefilter (focused specifically on disposable filtering with active issue triage), amieiro/disposable-email-domains (WordPress-oriented, well-organized into allow and deny lists), and martenson/disposable-email-domains (one of the older curated lists, still referenced widely). Each has tradeoffs. None of them, in our testing, catches more than a fraction of the disposable domains we see in production traffic.
The structural reason for these gaps is not maintainer effort โ it is data flow. Volunteer-curated lists update when someone notices a new disposable service and files a pull request. By the time that PR lands, the service has been live for weeks or months and has already been seeded into thousands of lead-generation databases. The lag is fundamental to the model.
github.com/BillionVerify/disposable: how ours is different
Our repository is updated daily, automatically, from a pipeline that observes new disposable services as they emerge across our verification traffic and a set of complementary signal sources. We do not wait for community reports. The dataset is significantly larger than any of the volunteer-maintained alternatives, with broader coverage of the long-tail providers that have been the actual source of bounce-rate problems for our customers over the past two years.
The repository ships the raw domain list in plain text and JSON. There is no library to install, no SDK to integrate, no version drift. Pull the file, embed it in your application, and you have a working disposable check. The license is MIT, which means you can use it in commercial products without attribution requirements, and you can fork and redistribute freely.
We are also publishing the methodology behind how we collect, validate, and de-duplicate entries, because the value of an open dataset is its auditability. A closed list of disposable domains is worth less than an open one even if it is larger, because you cannot inspect what is on it or why. We want this dataset to be the one researchers, anti-fraud teams, and competing verification services build on.
We expect โ and welcome โ other vendors to consume this list. The point is not to lock anyone out. The point is that the floor of disposable detection should be free and current for everyone, so that competition in email verification moves to the layers that actually matter: SMTP intelligence, catch-all classification, role-based filtering, and infrastructure reliability.
The free API: if you do not want to self-host
For teams that prefer not to vendor a list into their own codebase, we run the same data behind a hosted API. The BillionVerify verification platform has a dedicated /v1/verify/disposable endpoint that is purpose-built for sign-up forms and real-time validation โ pure in-memory lookup, single-digit millisecond responses. Calling it consumes zero credits, regardless of which plan you are using for the rest of your verification volume. You will still need a BillionVerify account and an API key to use it (the same way you would for any other endpoint on the platform), and the endpoint runs under our standard per-account rate limits, but there is no metering against your credit balance no matter how often you call it.
Disposable detection is also free on our main verification endpoints โ /verify/single, /verify/bulk, and /verify/file. If you upload a list of a hundred thousand addresses and twelve thousand of them turn out to be disposable, you are billed for the eighty-eight thousand non-disposable addresses, and the disposable ones are filtered out at the planning stage before they ever consume SMTP capacity. The rest of email verification โ catch-all detection, SMTP probing, role-based filtering, full mailbox validation โ is billed under our normal plan pricing, since those checks have real compute cost behind them. Only the disposable layer is unbundled and given away. The one narrow exception: if you explicitly opt your request into SMTP probing on a disposable address (a configuration most users never touch), we will run the probe and charge a credit if it returns a definitive result.
The reason for this policy is simple: charging for disposable detection penalizes the customers who do the responsible thing. If you are running verification before sending, you are protecting the mailbox-provider ecosystem from junk, and the dirtier your list happens to be, the larger your bill becomes โ which creates a perverse incentive to skip verification entirely. We would rather make the responsible behavior free and let the rest of our pricing reflect actual compute cost.
Where disposable contamination actually hurts the most

Disposable inboxes are not evenly distributed across email lists. They cluster in specific acquisition channels, and the channels they cluster in happen to be the ones where senders are operating at the highest volume with the thinnest margin for error.
Cold email
Cold email is the single highest-risk channel for disposable contamination, because the entire premise โ reaching prospects who have not opted into your list โ depends on operating below the bounce-rate thresholds that mailbox providers use to gatekeep new senders. A disposable hit in a cold email batch is not just a wasted message. It is a domain-reputation event. Sending platforms like Smartlead and Instantly will pause your campaigns automatically if your bounce rate crosses two or three percent. Disposable contamination at five or ten percent โ which we see routinely in unverified lead lists โ guarantees you trip those thresholds. The cost is not the cost of the bounce. It is the cost of the cooldown period and the slow climb back to good standing.
Google Maps lead scraping
Google Maps is one of the richest sources of small-business contact data, but the email addresses scraped from Maps listings are notoriously inconsistent. Many small businesses publish a generic info@ or contact@ address that is real but disengaged. Others publish addresses that route through cheap email-forwarding services whose underlying providers occasionally appear on disposable lists. And a substantial minority โ particularly in newer or single-operator businesses โ publish disposable addresses outright, sometimes because the business owner used a throwaway when setting up their listing. Verifying a Maps scrape against a disposable list before you import it into your outreach platform is non-negotiable.
B2B leads from data providers
B2B lead databases โ Apollo, ZoomInfo, Cognism, Clay, Lusha โ aggregate contacts from web scraping, public filings, and user-contributed data. The quality varies dramatically by vintage and source. We have seen lists from major providers run two to five percent disposable in the worst pockets, particularly when the contact data was sourced from sign-up forms on free tools where users routinely provide throwaway addresses to avoid downstream marketing. The good providers know this and verify before delivery; the rest pass the cost of cleanup to you.
Local business outreach
Local business outreach โ agencies and SaaS tools targeting restaurants, contractors, retail, service providers โ is structurally similar to Google Maps scraping in its disposable risk profile. Local businesses are more likely than enterprise contacts to be running their email through unconventional setups: Cloudflare email routing, free hosting providers, occasionally outright disposable services used as a privacy buffer when filling out business directory listings. The diversity of email infrastructure on this segment makes domain-list validation the only practical first-pass filter.
B2B agencies running outreach at scale
B2B agencies sit at the highest-volume end of the cold-outreach world and consequently absorb the most reputation risk per campaign. An agency running outbound for fifteen clients across a hundred sending domains cannot afford to discover post-send that any one of those domains has been contaminated. The blast radius of a single bad campaign rolls up across the entire client roster. Disposable filtering at the list-cleaning stage is the difference between an agency that can scale and one that is constantly putting out reputation fires.
The common pattern across all five of these scenarios is volume plus opacity. You are sending at scale into a contact set you did not control end-to-end. You have no way to know, address by address, which contacts are real and which are throwaway. The domain list is the cheapest, fastest, highest-recall filter available, and applying it before the send is the difference between a deliverability story and a deliverability incident.
How we compare to the rest of the email verification market
Every major email verification vendor offers disposable detection. None of them, to our knowledge, charges nothing for it, and none of them open-sources their list. Our vs page walks through the head-to-head against the field in detail; here is the short version on how each handles disposable specifically.
ZeroBounce, NeverBounce, Kickbox, Emailable, EmailListVerify, ClearOut, Bouncer (UseBouncer), EmailHippo, Mailtester Ninja, Hunter.io, Verified.email โ all detect disposable addresses as part of their core verification result. The disposable check is included in the per-address price; if you verify a list of a hundred thousand emails and twenty thousand are disposable, you are billed for all hundred thousand. None of these vendors publishes the underlying domain list. A few claim "millions" of disposable domains in their detection database; the actual coverage we have observed in practice is closer to the open-source baselines than the marketing copy suggests.
The market structure here is straightforward: disposable detection is one of the easiest checks in the verification stack to perform and one of the highest-margin to bill, because the cost of running the check is essentially zero โ it is a hashmap lookup โ and customers are willing to pay for "verified" status regardless of which layer of the stack produced the verdict. That spread is what we are collapsing.
Our position is that the floor of email verification โ syntax, domain existence, disposable status โ should be commodity infrastructure, the same way DNS itself is commodity infrastructure. Vendors should compete on the parts of the stack that genuinely require expertise and investment: real-time SMTP probing, catch-all classification, sender-reputation analytics, MCP and AI-native integrations, infrastructure latency, customer support. Free disposable is our way of putting our money where our mouth is on that argument.
Getting started
If you want the data, clone the repository: github.com/BillionVerify/disposable. The list is in a single file, easy to vendor or pull at build time. If you want the API, create a BillionVerify account and call /v1/verify/disposable with your API key โ there is no separate billing setup for disposable detection, and it stays free no matter which plan you choose.
If you operate at higher volume and want the disposable check folded into a full verification flow with SMTP probing, catch-all classification, and bulk processing, the same account works for that too. Disposable hits inside those flows remain free; the non-disposable addresses that actually require deeper checks are what your plan credits are for.
We will be maintaining the repository indefinitely. If you spot a disposable domain we are missing, file a pull request or send us a note โ we will fold it in within the day.
FAQ
Is the BillionVerify disposable list really free for commercial use?
Yes. The license is MIT, which permits commercial use, modification, distribution, and private use, with the only requirement being that the original license notice be included with copies of the data. You can vendor the file directly into a closed-source SaaS product, embed it in a CLI, ship it inside a mobile app, or use it as the basis for a competing verification service. There is no attribution requirement on the end user.
How is your list more complete than ivolo or mailchecker?
The volunteer-maintained lists update at the cadence of pull requests. Our pipeline updates daily from observed disposable traffic across the BillionVerify verification platform plus a set of complementary signal sources. The result is significantly broader coverage of the long-tail and recently-launched disposable providers that the community lists tend to miss. We will publish coverage benchmarks against the major open alternatives in a follow-up post.
Why is disposable detection free on your API when other vendors charge for it?
Because charging for it punishes the customers who do the right thing. A customer running verification before they send is protecting the mailbox-provider ecosystem from junk, and we do not want to disincentivize that by tying their bill to the dirtiness of their list. The actual compute cost of a disposable lookup is negligible. We would rather make the responsible workflow free and price the rest of our service โ catch-all classification, SMTP probing, full mailbox validation โ on real compute cost. You still need a BillionVerify account and an API key, and the rest of your verification volume runs under your normal plan, but the disposable check itself never burns credits.
Should I use the API or self-host the list?
If you are validating high volumes inside a hot path โ sign-up forms, CRM imports, real-time enrichment โ the API is faster than maintaining a fresh copy of the list yourself, because we handle the daily updates and you get single-digit millisecond responses. If you are running offline or air-gapped, or if you have policy reasons to avoid an external API call inside your sign-up flow, self-hosting is the right answer and the data is identical.
Does the free disposable check work with check_smtp:true?
The dedicated /v1/verify/disposable endpoint is disposable-only and does not support SMTP probing โ for that you would call /v1/verify/single or /v1/verify/bulk. On those endpoints, disposable hits are still free by default. The one edge case is if you explicitly request SMTP probing on a disposable address and the probe returns a definitive result; in that single case the probe consumes one credit. This is opt-in and most users never touch it.
How do I integrate this with my cold email or B2B outreach workflow?
The simplest integration is to run your contact list through /v1/verify/file before you import it into your sending platform. Disposable addresses are filtered out at the planning stage and never enter your campaigns. For ongoing acquisition, drop the /v1/verify/disposable lookup on whatever form, scraper, or enrichment step is producing new contacts, so disposable addresses are caught at the source rather than after they accumulate in your CRM.

