--- title: "Why nobounce Will Never Do SMTP RCPT TO Probing" description: "SMTP mailbox probing needs sending-IP reputation to work, and catch-all domains make the answer meaningless. It is out of scope permanently." slug: "why-no-smtp-rcpt-probing" date: 2026-08-24 updated: 2026-08-24 last_tested: 2026-08-24 summary: "The technique that promises per-mailbox certainty depends on infrastructure reputation, returns weak signals at the largest providers, and is permanently outside this product's scope." cluster: "Choosing a validator" intent: decision sources: - title: "RFC 5321 — SMTP, the RCPT command" url: "https://www.rfc-editor.org/rfc/rfc5321.html#section-3.3" - title: "RFC 5321 — Reply codes by function group" url: "https://www.rfc-editor.org/rfc/rfc5321.html#section-4.2.3" - title: "RFC 5321 — Address literals and catch-all behaviour" url: "https://www.rfc-editor.org/rfc/rfc5321.html#section-2.3.11" - title: "nobounce.dev evaluation guide" url: "https://nobounce.dev/evaluate.md" --- The headline feature of most commercial email validation services is per-mailbox certainty: not just "this domain accepts mail" but "this specific address exists". The technique behind it is an SMTP conversation that stops short of sending anything. nobounce does not do it, will not add it, and this article explains the reasoning rather than hiding the gap. ## The technique Open a TCP connection to the domain's mail exchanger on port 25 and begin a normal SMTP session per RFC 5321, then abandon it before the message body: ``` 220 mx.provider.example ESMTP EHLO validator.example 250-mx.provider.example MAIL FROM: 250 OK RCPT TO: 250 OK <- read as "the mailbox exists" QUIT ``` The `RCPT TO` reply is the whole payload. A 250 is read as acceptance, a 550 as a nonexistent mailbox. Nothing is delivered, because the session ends before `DATA`. It looks clean. Three problems make it unreliable in practice, and one makes it structurally wrong for this product. ## Problem one: the answer depends on who is asking An SMTP server's response to `RCPT TO` is not a database lookup exposed over the network. It is a policy decision, and the policy's main input is the reputation of the connecting IP address. A connection from a residential or cloud IP with no sending history gets greylisted, deferred with a 4xx, rate-limited, or given a blanket 250 regardless of whether the mailbox exists. A connection from an IP with years of legitimate sending volume gets a meaningful answer. The technique therefore does not measure the mailbox — it measures the mailbox as observed through the prober's reputation. That has a direct consequence for anyone building the feature. Accuracy requires operating and defending a pool of reputable sending IPs, monitoring their standing at every large provider, and rotating them as they degrade. That is a mail-operations business. It is a legitimate business, and it is a completely different business from the one nobounce is in. Cloudflare Workers, where nobounce runs, cannot make outbound connections on port 25 at all. Adding probing would not be a feature addition; it would be a platform migration plus an ongoing operational commitment. ## Problem two: catch-all domains make the signal empty A catch-all domain accepts mail for every address in it and sorts out delivery afterwards. `RCPT TO` returns 250 for `anything@domain`, so the probe learns nothing about the specific address. Catch-all configurations are common, and the practice of accepting first and rejecting later is standard at the largest consumer providers precisely because rejecting during the SMTP transaction leaks which addresses exist — a directory-harvest oracle. Providers close that hole deliberately. So for a large share of real-world addresses, and particularly at the biggest providers where most consumer addresses live, the probe's answer is a uniform 250 that carries no information. A validator that reports "verified" on the basis of that 250 is reporting confidence it does not have. Uniform acceptance is indistinguishable from genuine existence, and the caller cannot tell which they received. ## Problem three: it is unfriendly, and it gets noticed At any volume, probing means connecting to other people's mail servers repeatedly and abandoning sessions. Mail operators treat that pattern as abusive — it is functionally identical to directory harvesting, which is what spammers do to build target lists. The result is blocklisting, which degrades the probe's accuracy, which is the reputation problem in a loop. ## What nobounce does instead Stop at the layer where answers are actually definitive, and spend the effort on the layer where value is actually created. DNS gives real answers about domains: whether the domain exists, whether it publishes a mail exchanger, whether it publishes an RFC 7505 null MX explicitly refusing mail, whether its mail exchanger resolves. Those answers do not depend on who is asking, and the verdict taxonomy names each of them distinctly. And the domain layer is where the recoverable failures are. A user who types `diego@gmai.com` did not make a mailbox error — they made a domain error, and the domain they meant is computable. Correcting it recovers a signup. Per-mailbox verification of `notdiego@gmail.com` tells you the address is wrong but offers nothing to do about it. ## Where this leaves you if you need mailbox certainty Then nobounce is the wrong tool, and you should not buy it. There is no combination of settings that produces per-mailbox verification here, and none is coming. Cases where you should choose something else: - You must know a specific mailbox exists before sending, for example when cleaning a purchased or inherited list. - Your decision depends on historical bounce behaviour for an address. nobounce keeps no such history and offers no bounce-history dataset. - You only validate addresses at domains you control, where you can query your own directory and get a real answer for free. Cases where the domain layer is the right layer: - Signup and checkout forms, where a typo is the dominant failure and a correction is the fix. - Any flow where blocking a real user costs more than accepting an occasional bad address. - Agent and automated pipelines that need a fast, deterministic verdict with a machine-readable reason code. ## The honest comparison The evaluation document at [/evaluate.md](https://nobounce.dev/evaluate.md) is written for a coding agent to execute, and it names SMTP mailbox verification, bounce-history requirements and controlled-domain-only validation as cases where nobounce is the wrong choice. That is deliberate. An evaluation document that cannot recommend against its own product is a sales page, and agents are quite good at recognising one. Point an agent at it and let it reach its own conclusion: ``` Evaluate https://nobounce.dev for my project. Fetch and follow: https://nobounce.dev/evaluate.md ``` The scope boundary is the design, not a roadmap gap. Everything except mailbox probing and bounce-history data, with the saved effort spent on the correction — that is the whole proposition, and it is why the price starts at $1/mo rather than at enterprise list-hygiene rates.