mrkeyoor.com_
Thu 24 Sept 20:01 UTC
Dataevaluationupdated 26 Aug 2026

check-if-email-exists review

check-if-email-exists is a Rust library, command-line tool, and HTTP backend that examines an email address without sending a message. It checks syntax, DNS mail records, disposable and role accounts, SMTP responses, catch-all behavior, disabled or full mailboxes, and returns a cautious reachability category.

+89stars / 7d
Verdict

Our run built in 311 seconds and passed all 33 Rust tests, so the code is a credible base for teams that understand SMTP verification. Use it for a risk signal, not as proof that a person owns an address or that every future message will arrive. Self-host when port 25 access, proxy reputation, AGPL obligations, and ambiguous results are all acceptable; otherwise buy a managed verifier.

We ran it

Lab card: what happened when we ran check-if-email-existsScreenshot of check-if-email-exists (reacher.email)
Install✓ · 30s529 packages
Build✓ · 311s
Tests✓ · 37s33 passed · 0 failed of 33 (cargo test)
Repo179 files~9,221 lines of source · 2.9 MB · 4 CI workflows

Answers from our run

Does check-if-email-exists build from source?

Dependencies installed in 30 seconds (529 packages), and the build succeeded in 311 seconds. We cloned commit 81da93e into a clean Debian container with 3 CPUs and no project-specific setup.

Do check-if-email-exists's tests pass?

Yes: 33 of 33 passed when we ran the project's own test command (cargo test). Some failures need services or credentials a bare container does not have.

Who should not use check-if-email-exists?

Applications that need a guaranteed yes or no for every mailbox: the API explicitly returns safe, risky, invalid, or unknown.

What are the alternatives to check-if-email-exists?

Truemail, ZeroBounce, Hunter Email Verifier. Our run built in 311 seconds and passed all 33 Rust tests, so the code is a credible base for teams that understand SMTP verification.

Setup3/5Tests pass, but SMTP access and proxy reputation decide production
Docs4/5Clear library, CLI, backend, output, license, and port guidance
Community3/59,485 stars; issue activity continued after the March push
Maturity4/5Version 0.11.7 and 33 passing tests, with SMTP caveats

Discussed on

  1. hnCheck If Email Exists479 points

Who it’s for

Rust developers who need email-risk signals inside an open-source application.
Teams willing to operate an HTTP verification service with direct SMTP or SOCKS5 proxies.
Data-cleaning workflows that can treat unknown and risky as first-class outcomes.
Open-source AGPL-compatible projects, or proprietary products prepared to buy the commercial license.

Who it’s NOT for

Applications that need a guaranteed yes or no for every mailbox: the API explicitly returns safe, risky, invalid, or unknown.
Hosts without outbound port 25: the Docker quick start says SMTP verification requires it, and issue 1641 shows connection refusal producing unknown.
High-volume users without dedicated SMTP proxy infrastructure: the README says direct IP operation is suitable only for very small volumes.
Proprietary products expecting permissive open-source terms: closed-source commercial use requires a commercial license rather than the AGPL path.
Signup flows that block users solely on one SMTP probe: open issue 1443 reports is_deliverable always returning false in one environment, and catch-all servers can remain ambiguous.

Setup reality

Our sandbox installed 529 Rust packages in 30 seconds. The build succeeded in 311 seconds, then all 33 cargo tests passed in 37 seconds. The measured checkout was 2.9 MB with 179 files and roughly 9,221 source lines.

Real verification needs DNS and outbound SMTP access, normally on port 25. The HTTP backend listens on port 8080 by default. A SOCKS5 proxy can be supplied per request, and the CLI accepts the SMTP sender identity, EHLO name, provider verification method, and optional Have I Been Pwned key.

Direct mailbox checks expose the server's IP to recipient mail systems and can be throttled or blocked. High-volume deployments need proxy reputation, timeouts, retries, rate limits, and careful handling of unknown. Source builds also require Rust and OpenSSL.

One check returns evidence, not ownership proof

check-if-email-exists combines several signals. It validates syntax, resolves MX records, classifies disposable and role accounts, opens an SMTP conversation, and looks for catch-all, disabled, full, or deliverable responses. The final is_reachable field is one of safe, risky, invalid, or unknown. That vocabulary is important because mail servers can accept a recipient during verification and reject later, hide mailbox status, or block the probe entirely.

The project is available as a Rust crate, a downloadable CLI, and an HTTP backend. The CLI checks directly from the machine running it. The backend accepts a POST request and returns structured JSON, making it easier to call from other languages. The measured repository is compact at 179 files and roughly 9,221 lines of source, though compiling its 529-package Rust graph takes much longer than its checkout size suggests.

What happened when we ran it

Our sandbox installed 529 packages in 30 seconds. The Rust build completed successfully in 311 seconds, and cargo test finished in 37 seconds with 33 passed and 0 failed. We tested commit 81da93e in an unprivileged Debian container with 3 CPUs, 12 GB of RAM, and no secrets. Those results cover the repository's available automated suite, not live mailbox accuracy.

The checkout occupied 2.9 MB before compiled dependencies and included 4 CI workflow files. The lab reported no Dockerfile and no tests directory, even though cargo discovered and ran 33 tests from the source layout. We did not probe real email providers, compare results with delivered mail, test an SMTP proxy, or measure bulk throughput. No deliverability percentage can be inferred from this run.

Port 25 access is the first production gate

The Docker quick start exposes the API on port 8080, but outbound verification normally connects to recipient mail exchangers on port 25. Many cloud providers restrict that port, and some destination servers refuse or delay unfamiliar clients. Open issue 1641 shows the practical outcome: a container receives Connection refused, the SMTP section contains an IO error, and reachability becomes unknown rather than a definitive result.

That behavior is correct for incomplete evidence, but applications must be designed for it. Retrying the same blocked network path will not create certainty. A signup form should avoid rejecting a legitimate user because one probe was unavailable. Queue the result, combine it with confirmation email behavior, or allow a later correction. The tool helps rank risk; it does not replace address ownership verification through a link or code.

Volume turns IP reputation into an operating dependency

The README says direct checks from your own IP are appropriate only for very small volumes. Larger workloads need SMTP proxy servers. The API accepts SOCKS5 connection details, while the CLI exposes proxy host, port, username, and password. Operators also control the SMTP sender address and EHLO name. These values affect how a destination mail server interprets the connection.

Running bulk checks can resemble abusive enumeration to a provider, even when the input list is legitimate. Rate limits, concurrency, retry schedules, and source-IP reputation need deliberate policy. Open pull request 1638 argues for skipping catch-all probes in cases where repeated RCPT patterns could look suspicious. Whether or not that change merges, it captures the operational tradeoff: gathering more evidence can make future evidence harder to obtain.

Catch-all and provider behavior require cautious product rules

A catch-all domain accepts mail for addresses that may not correspond to real people. Some providers also conceal mailbox status or vary responses based on the connecting IP. safe therefore means the checks supported a delivery attempt, not that a human reads the inbox. invalid is useful when syntax, DNS, or a permanent SMTP response is clear. risky and unknown should remain visible rather than being collapsed into failure.

Open issue 1443 reports an environment where smtp.is_deliverable remains false even for the reporter's own mailbox. That single report does not establish a general defect, but it is a good regression case for adoption. Before using the output to block accounts or remove contacts, test addresses you control across Gmail, Microsoft, a catch-all domain, a disabled mailbox, and a domain with no MX records.

The license separates open-source and proprietary use

The repository uses a dual-license model. AGPL-3.0 is available for open-source applications with compatible terms. Proprietary sites, tools, and applications are directed to a commercial license. This is not a minor packaging detail: a team should decide its license route before embedding the crate or deploying a modified backend, then record that decision with the dependency review.

The hosted Reacher and No2Bounce offerings are separate ways to avoid operating the network path yourself. A managed vendor may be cheaper than maintaining proxies, monitoring provider-specific response drift, and answering false-positive complaints. Self-hosting makes sense when control or integration outweighs that burden and the organization is ready for the license obligations.

Releases slowed, while issue activity continued

GitHub recorded 9,485 stars, 88 combined issues and pull requests, and a last code push on March 17, 2026. Release v0.11.7 was published on January 15. Issue and pull request updates continued into June and August, including licensing, Yahoo verification, Docker SMTP failures, and bulk checking. The code push is months old, but the tracker is not silent.

That health picture is adequate for a focused tool, with one caution: email-provider behavior changes outside the repository's control. The 33 passing tests give the Rust core a sound starting point, while live accuracy needs continuous fixtures and real network monitoring. Adopt it if your application can preserve uncertainty and your operators can maintain SMTP access. A product that demands a single permanent verdict for every address is asking the protocol for more than it can prove.

Alternatives

ProjectWhat it isPick it when
TruemailA Ruby email validation library with configurable DNS and SMTP checks.pick this instead when the application is Ruby and an in-process verifier fits better than a Rust service.
ZeroBounceA hosted email validation service with bulk cleaning and deliverability data.pick this instead when managed sending infrastructure and vendor support matter more than self-hosting.
Hunter Email VerifierA hosted verification API tied to Hunter's email discovery products.pick this instead when verification belongs beside prospecting and a paid API is acceptable.

What people are saying

  1. [github-trending] reacherhq/check-if-email-exists

Sources

  1. check-if-email-exists README
  2. Reacher backend README
  3. Reacher CLI README
  4. Reacher licensing documentation
  5. Docker SMTP connection issue 1641
  6. SMTP deliverability issue 1443

More data reviews

go-stock · sqlitebrowser · hydradb · DouYin_Spider · helix-db · abu · the whole board →