Verification without pretending it is certainty
check-if-email-exists tries to answer a deceptively difficult question: can a message probably reach this mailbox? A regular-expression check only tells you whether an address looks plausible. This project also examines DNS mail records, known disposable domains, role accounts, SMTP connectivity, catch-all behavior, disabled mailboxes, and full inboxes.
The most honest part of the design is its top-level result. An address can be safe, risky, invalid, or unknown. That is better than forcing ambiguous SMTP behavior into a Boolean. Mail providers deliberately limit probing, catch-all domains accept unknown recipients, networks block SMTP, and a server response can vary by sender identity or IP reputation. Reacher exposes the evidence underneath the summary, so an application can distinguish bad syntax from a timeout or a catch-all domain.
The project comes in three useful forms. Rust applications can call the library directly. Operators can download a standalone CLI that checks from the local machine. Other stacks can run the Dockerized HTTP backend and post an address to /v0/check_email. The core logic is not trapped behind a hosted dashboard, even though the maintainer also sells a service.
The one-line Docker start is only the first gate
Running docker run -p 8080:8080 reacherhq/backend:latest is easy. The hard requirement appears in the sentence beside it: outbound port 25 must be open. Many cloud and hosting networks restrict direct SMTP traffic. Open issue 1641 shows the practical result, a Docker deployment receiving connection-refused errors and returning unknown for the reachability decision.
The downloaded CLI avoids running a server, but not the network rules. It performs checks directly from the machine. Its options expose the real moving parts: sender address for MAIL FROM, identity for EHLO, SMTP port, SOCKS5 proxy details, and different verification methods for Gmail, consumer Hotmail, business Hotmail, and Yahoo. Yahoo and Hotmail may involve API, SMTP, or headless methods depending on the provider.
Building from source is reasonable for a Rust project. The backend guide asks for Rust and OpenSSL, then runs the release binary through Cargo. The server also contains an HTTP service and a RabbitMQ worker, which gives larger deployments a queue path but adds another service to operate. The minimal container command is appropriate for evaluation, not a complete production architecture. Authentication, rate controls, logs, address retention, and abuse prevention remain the operator's job.
Volume changes the economics. The README says your own IP addresses can handle very small volumes, but more than that requires SMTP proxy servers. Proxies are not an optional performance tweak here. Their availability and reputation directly influence whether a remote mail server answers. Issue 1634 documents a commercial-trial deployment whose configured SOCKS5 service timed out across several addresses, turning checks into unknown after long waits.
Rich output needs careful product policy
The JSON response is the feature to build around. Syntax details include the parsed domain, user name, and a correction suggestion. MX output says whether the domain accepts mail and lists its records. SMTP details report connection, deliverability, disabled status, catch-all behavior, and inbox capacity. Miscellaneous flags identify disposable and role addresses.
Do not reduce all of that to rejecting anything that is not safe. A temporary connection failure should not lock out a real user. A catch-all address may be perfectly valid but impossible to prove through probing. A disposable address may be acceptable for a privacy-respecting product. Good integration stores the reason, defines separate policies for signup, cleanup, and outbound campaigns, and allows uncertain users another verification route such as a normal confirmation email.
Open reports reinforce this caution. Issue 1443 describes smtp.is_deliverable remaining false even for the reporter's own address. Issue 1598 shows Yahoo checks failing inside the headless verification path. These reports are specific to their environments and versions, so they do not establish a universal defect. They show why a test set across Gmail, Microsoft, Yahoo, corporate gateways, catch-all domains, and deliberately invalid addresses is necessary before launch.
Privacy deserves equal weight. Even without sending mail, a verification service processes identifiers and contacts remote infrastructure in ways that can reveal checking activity. Operators should minimize logs, restrict access, set retention rules, and avoid presenting the technique as invisible or authoritative.
Licensing is a real purchasing decision
The repository's README documents a dual model. AGPL-3.0 is available for open-source applications using a compatible license. Proprietary commercial sites, tools, and applications are directed to purchase a commercial license. GitHub currently reports no single SPDX license because of that arrangement. An open pull request proposes switching to MIT, but it has not been merged. Base a product decision on the current published terms, not the proposed change.
This condition makes Reacher less casual to embed than a permissively licensed validation library. Legal review belongs in the setup estimate. A hosted service can be simpler when paying for network infrastructure is preferable to buying software rights and operating SMTP proxies.
Health and verdict
The project dates to 2017 and had 9,427 GitHub stars on August 10, 2026. Version 0.11.7 was released on January 15, and the repository was pushed on March 17. Issues and pull requests remained active into June, including the proposed license change, while GitHub listed 88 open issues and pull requests. The long history and recent release show maintenance; the sizeable queue and unresolved provider reports show continuing operational friction rather than abandonment.
Documentation covers the three entry paths, output schema, core checks, CLI flags, source builds, HTTP request shape, and licensing. Production details are more scattered, especially around queue deployment, proxy selection, security, and interpreting results.
Reacher is worth testing when self-hosting and detailed evidence matter more than a guaranteed answer. Start with the Docker API, confirm port 25, assemble a provider-diverse test list, and record how often results become unknown. If those constraints fit and the license is acceptable, it offers a capable foundation. If not, a narrower typo checker or a managed verification service will be the more dependable choice.