Internal product
A self-hosted email verification engine built for explainable results
An internal product: a bulk verification CLI with DNS and multi-stage SMTP checks that explains each classification instead of emitting a black-box score, deployed on its own verification node and run on real lead lists.
Source not public
Our own engineering. We will screen-share the code, the architecture, and the tests with anyone seriously evaluating us; publishing the repository invites the scrapers we spend our days defeating.
- Headline figure
- 34 reason codes · 25 output columns
- Status
- Delivered
- Practice
- Build · Data
- Sources
- 2 figures
documented classification system; every verdict traceable to the check that produced it, June 2026
Internal product
Email infrastructure
engineering record
The problem.
Bulk email verification services return a single opaque score at a price. Operating our own cold-email outbound meant needing something cheaper that also explained itself: why an address was classified the way it was, especially on catch-all domains, which accept mail for any address and so defeat a plain mailbox check.
What was built.
- Python 3.10+ bulk verification CLI using DNS and multi-stage SMTP checks
- Provider profiles with greylisting and tarpit handling
- Catch-all domains given a score rather than passed or rejected outright
- SPF, DMARC, PTR, TLS, legitimacy, confidence, and bounce-risk signals
- 34 documented reason codes and 25 output columns per address
- Concurrent bulk runs via multiprocessing
- pytest suite and GitHub Actions workflows for CI, CodeQL, deployment, and health
- Deployed on a dedicated verification node and run on real lead lists, with results delivered as CSVs
Timeline.
Research session: the target set as matching a commercial tool's reason codes on a 99,000-address benchmark set, not just its verdicts; catch-all domains to be scored rather than passed or rejected; SMTP-probing prototype committed
Repository created; provider profiles, 34 reason codes, 25 output columns, a pytest suite and GitHub Actions workflows for CI, CodeQL, deploy and health landed over the following three months
Production run from the verification node on a 602-address lead list: 421 valid, 11 invalid, 157 risky, 13 unknown in 742 seconds, each with its reason code; results delivered as four CSVs
Next version of the verifier started in a second repository
What this case claims, and what it does not.
On the record
- Architecture and operating maturity, as built
- Internal product, clearly labeled as such
- The June 2026 run summary, as recorded
Withheld, and why
Figures that exist internally and are not on this page, with the reason.
- An accuracy percentage
- There is no published benchmark methodology yet, so no accuracy figure is claimed and no comparison to a vendor is made.
- Where it runs
- Production hostnames, sending identities, and addresses stay private.
Elsewhere on the site
Read next
Where to next
Have a problem in this shape?
Send a short description. The form opens with this case already named, so you only add the part that is yours. We will tell you whether it is worth building at all.