disposable-email-domains

disposable-email-domains is a small npm package that ships two static JSON files — an index of over 120,000 exact disposable-email domains and a shorter wildcard list for suffix-based providers like *.33mail.com — for use in signup forms, fraud checks, and email validation pipelines.

The package itself has almost no runtime logic: index.js and wildcard.js are thin CommonJS wrappers around the JSON data, kept current through community pull requests and a small add.js maintenance script that merges, lowercases, sorts, and dedupes new domain contributions. The README notes the project is no longer actively maintained and points to a community fork for the latest list, so teams using this package for anti-fraud filtering should budget for periodically refreshing or supplementing the underlying data.

What You Get

• index.json - an alphabetically sorted, deduplicated array of 120,000+ exact disposable email domains.
• wildcard.json - a shorter list of roughly 400 wildcard domain suffixes (e.g. *.33mail.com) for providers that issue unlimited subdomains.
• Zero-dependency require - both lists load via a single require('disposable-email-domains') call with no runtime dependencies.
• Contribution tooling - an add.js script that merges, lowercases, sorts, and dedupes community-submitted domains from plain-text contribution files.

Common Use Cases

• Signup form validation - reject or flag registrations using a known disposable email domain before an account is created.
• Fraud and abuse prevention - combine the domain list with rate-limiting to cut down on throwaway accounts used for spam or abuse.
• Email list hygiene - filter disposable addresses out of newsletter or CRM imports to protect sender reputation.
• Custom blocklist merging - use the JSON arrays as a seed list that’s merged with an app’s own denylist or a live API.

Under The Hood

Architecture The package has effectively no execution architecture: index.js and wildcard.js are one-line CommonJS wrappers (module.exports = require('./index.json')) around two static JSON files, so consuming code gets a plain in-memory array with no parsing logic, classes, or async behavior to reason about. The only non-trivial code path lives in add.js, a maintenance script (not shipped to consumers) that reads community-contributed domains from contributions/index.txt and contributions/wildcard.txt, concatenates them with lodash, lowercases and sorts the results, removes duplicates, and strips any exact-match domain already covered by a wildcard suffix before rewriting the JSON files. There’s no runtime dependency graph to speak of, and nothing would break from an architectural change — the entire surface area is the shape of the two JSON arrays.

Tech Stack The runtime is plain CommonJS JavaScript with zero production dependencies — consumers get raw JSON via require. The maintenance tooling in add.js depends on lodash for array operations (concat, uniq, toLower), and the test suite uses mocha as the runner with chai plus the chai-sorted plugin and validator’s isFQDN check for assertions. There’s no build step, bundler, or transpilation — the published package is the raw .js/.json files, and a parallel composer.json and component.json exist for PHP/Component-style installs of the same data, though npm is the primary distribution channel.

Code Quality Test coverage in test/index.js and test/wildcard.js is thorough for the package’s narrow scope: custom Chai helpers (isFQDN, lowercase, notInWildcard) assert every domain is a syntactically valid FQDN, lowercase, alphabetically sorted, deduplicated, and — for the exact-match list — not already covered by a wildcard entry. No CI configuration is present in the repo, so these tests appear to run only locally via npm test/npm run prod, and there’s no linter or type checker configured. Naming is plain and consistent given the tiny codebase, but there’s essentially no error handling to assess since the shipped code has no control flow.

API Design Developer experience is about as frictionless as a package can get: var domains = require('disposable-email-domains') returns a ready-to-use array, and require('disposable-email-domains/wildcard.json') gets the suffix list — no configuration, initialization, or async setup required. The tradeoff is that the README itself now warns the repo is no longer actively maintained and points users to a community fork (tompec/disposable-email-domains) for an up-to-date list, so the simplicity comes with a real freshness caveat for anyone relying on it for current fraud filtering.