MailChecker

MailChecker is a zero-dependency, cross-language library for catching temporary and disposable email addresses at signup. It pairs strict RFC-grounded regex validation with a bundled blocklist of over 55,000 known throwaway domains (yopmail-style services, spam-box providers, and similar), so an address can fail either on malformed syntax or on belonging to a domain nobody wants receiving real communication.

The same domain list and validation logic are code-generated from a single template pipeline into native implementations for Node.js, browser JavaScript, PHP, Python, Ruby, Rust, Go, Elixir, and Clojure, so teams standardize on one blocklist across a polyglot stack instead of maintaining separate disposable-email logic per service.

What You Get

• A single isValid(email) function returning a boolean — strict regex format check plus disposable-domain blocklist check in one call
• A bundled, regularly-updated blocklist of 55,000+ disposable/throwaway email domains, checked against the target domain and all of its parent domains
• addCustomDomains(domains) to extend the built-in blocklist at runtime with an organization’s own denylist
• blacklist() to inspect the full in-memory Set of blocked domains directly
• Native, functionally-equivalent implementations for Node.js, browser JavaScript, PHP, Python, Ruby, Rust, Go, Elixir, and Clojure generated from one shared template and domain list
• Bundled TypeScript type declarations (types.d.ts) for the Node/JS API
• Zero runtime dependencies in the Node package

Common Use Cases

• Rejecting disposable-email signups at registration time before an account or trial is provisioned
• Gatekeeping newsletter and lead-capture forms to keep list quality high and avoid paying for throwaway contacts
• Pre-validating email addresses server-side before triggering a transactional verification email, to cut wasted sends
• Enforcing one shared disposable-domain policy across services written in different languages (a Node API and a Python worker, for example) via the same generated blocklist
• Layering into fraud/abuse prevention alongside rate limiting, to raise the cost of creating throwaway accounts for spam or abuse

Under The Hood

Architecture MailChecker’s core logic is deliberately tiny: the Node build (platform/node/index.js) is a generated file wrapping a hardcoded Set of domains and a single unanchored regex literal, exposing isValid, blacklist, and addCustomDomains. isValid lowercases the input, tests it against the regex, then walks the domain right-to-left through isBlacklisted — checking example.com, then com, so subdomains of blocked domains are caught without needing every subdomain listed explicitly. The nine per-language implementations under platform/* are not hand-maintained separately; gen.js drives lib/generator.js, which globs every *.tmpl.* file, injects the shared domain list (list.txt, loaded via lib/loader.js) and regex string through Mustache (mu2), and writes out each language’s native file, guaranteeing the blocklist and validation semantics stay identical across bindings.

Tech Stack The Node/browser runtime artifact has zero dependencies — dependencies: {} in package.json — keeping it safe to drop into any signup path. The build/dev tooling (glob, async, lodash, mu2/eventemitter2, mocha/should) lives entirely in devDependencies and never ships to consumers. Other language platforms carry their own idiomatic toolchains (Cargo for Rust, go.mod for Go, a gemspec for Ruby, setup.py for Python), each generated from the same list.txt source of truth rather than duplicating it by hand.

Code Quality test/platform.node.test.js exercises the public API with Mocha/should: format validity/invalidity (including whitespace and newline edge cases), disposable-domain rejection across a random 2,000-domain sample of the real blocklist, subdomain matching, and the addCustomDomains runtime-extension path. Every other language binding has its own parallel test file (platform.python.test.py, platform.ruby.test.rb, platform.go, etc.), run via Docker in CI so behavior parity across nine languages is actually enforced rather than assumed. The generator itself has coverage too (test/generator.test.js, test/loader.test.js). The main risk surface is the 56,000-line list.txt data file, which is community-curated and reviewed by PR rather than programmatically validated for staleness.

API Design The public surface is deliberately minimal — isValid(email), blacklist(), addCustomDomains(domains) — with consistent naming translated idiomatically per language (isValid/is_valid/valid?). Bundled types.d.ts gives TypeScript consumers full autocomplete with no @types package needed. There’s effectively no boilerplate: install, require, call isValid(). The tradeoff for that simplicity is a fairly blunt API — no async variant, no way to query which specific rule (regex vs. blocklist) failed, and extending the blocklist is additive-only within a process, not persisted.