Why a Bulk Email Pre-Filter Should Return "unknown" Instead of Probing SMTP

PROOFNEXA — Sun, 09 Aug 2026 14:19:19 +0000

A bulk email verifier has an uncomfortable job: it is asked to predict whether an address is usable, even though the strongest signal—whether a mailbox actually accepts mail—is usually private, dynamic, or unsafe to probe at scale.

That is why I prefer a pre-filter with an explicit "unknown" outcome.

The problem with false certainty

A syntax check can tell us that name@example.com is shaped like an email address. DNS can tell us whether the domain publishes mail exchangers. A few address patterns can reveal obvious role accounts or disposable providers.

None of those checks proves that a particular mailbox exists or will accept a message.

If a tool turns every ambiguous row into "valid", the downstream team may:

import risky rows into a CRM;
spend sender reputation on addresses that were never verified; or
mistake a heuristic for a deliverability guarantee.

The safer contract is three-valued:

"allow": bounded public signals found no obvious reason to stop;
"suppress": the row failed a deterministic syntax, domain, or policy check;
"unknown": the available signals are not strong enough to decide.

The third state is not a weakness. It is the honest boundary of the evidence.

A privacy-bounded pipeline

For a first pass, the pipeline can remain deliberately boring:

Parse and normalize the address.
Check the domain's public DNS/MX state.
Apply deterministic checks for disposable, role, and free-provider patterns.
Preserve the reason codes and the raw input row identifier.
Return an explicit outcome and keep ambiguous cases separate.

There is no SMTP connection, mailbox login, message sending, inbox discovery, or CAPTCHA bypass in this workflow.

That makes it useful before a campaign or CRM import, while avoiding the claim that a public DNS signal can see inside a mailbox provider.

What I would measure

A real evaluation should report more than a success count. I would keep at least:

the number of "allow", "suppress", and "unknown" outcomes;
the reason-code distribution;
the percentage of rows that were not decidable;
processing time and failure rate; and
if a team later measures campaign outcomes, those results as a separate experiment.

The last point matters. A local test, an HTTP 200, or a saved Dataset proves that the pipeline ran. It does not prove that a mailbox exists, that a campaign will deliver, or that a buyer saved money.

The useful product boundary

The smallest useful product is therefore not "guaranteed email verification." It is a bounded pre-filter that helps a team decide which rows need review before they enter a sending workflow.

I packaged that workflow as a self-service starter kit and kept the limits visible: up to 500 rows per pass, public DNS and address-pattern signals, explicit unknown results, and no deliverability guarantee.

Details and the one-time kit are here: https://dns-snapshot-signal.rotenkus.chatgpt.site/email-pre-filter

For metered automation, the public Apify Actor is separate: https://apify.com/invaluable_rondeau/email-verifier-bulk

Disclosure: this article was drafted with AI assistance and reviewed by the author. The links above describe my own product; they are included after the technical explanation, not as a substitute for evidence.

I measured where Claude Code actually spends tokens: 96.8% is re-reading history, my typing was 0.01%

PROOFNEXA — Thu, 30 Jul 2026 14:41:37 +0000

Claude Code writes a log of every session to ~/.claude/projects/. Each line is JSON, and message.usage holds the token counts the API actually returned.

I aggregated 32 sessions. These are not estimates.

96.8% is re-reading conversation history

Type	Tokens	Share
Re-reading history (`cache_read`)	1,370.9M	96.8%
Cache writes	37.7M	2.7%
Model output	6.7M	0.5%
What I typed in	0.2M	0.01%
Total	1,415.5M	100%

My own typing is 0.01%. Shortening prompts optimizes one ten-thousandth of the bill.

The mechanism: the model re-reads the whole conversation every turn. So once a large return enters the context, you keep paying for it on every following turn. Drop a 10k-char return in, talk for 20 more turns, and you paid for 200k chars.

88.8% of that history is tool return values

Not prose. Not your instructions. Tool output.

It is not call frequency. It is return size

Tool	Share	Calls	Per call
Full page fetch (browser)	63.3%	417	33,645 chars
Reading a whole file	13.0%	258	11,132 chars
Screenshot	4.0%	3	296,827 chars
Bash	3.7%	967	839 chars
Extracting only the values with JS	0.4%	164	504 chars

Look at the last two rows.

967 Bash calls cost less than 3 screenshots. One screenshot is ~354 Bash calls.

And in the same browser task, fetching the whole page costs 33,645 chars while extracting just the values you need costs 504. A 67x difference.

Three things that actually move the number

Never read a whole file. 11,132 chars per read. Grep for the line numbers first, then read that region. Read the whole thing exactly once, when you first need the structure.
Do not take screenshots out of habit. 296,827 chars each. If the state is readable as text, read it as text.
Never fetch a whole web page. Extract the handful of values you need. 33,645 becomes 504.

Conversely: stop rationing shell commands. 967 calls came to 3.7%.

Caveats

This sample skews toward web research, so browser calls rank first. If you mostly write code, file reads will lead. Measure your own logs.
cache_read is billed at a lower rate than fresh input, so token share is not cost share.
Whether weekly usage limits deplete in proportion to this split is unverified; the formula is not published.
Sample: 32 sessions, 2,478 tool returns.

Measure your own

~/.claude/projects/

One folder per project, .jsonl inside. Each line is JSON: message.usage for tokens, tool_result for the returns.

Take the method, not my numbers. Your top consumer will differ, and that is the one worth cutting.

DEV Community: PROOFNEXA