Products · Agent output, checked against the world
NEXIO
An agent proposes. A deterministic layer refuses to take its word for it.
Nexio finds people worth contacting, and the useful half is what happens after the model has spoken. A language model proposes an address from a pattern; it has no way to know whether that address exists, and it is not built to care. A separate layer then checks the proposal against things that cannot be reasoned into being true — DNS and MX records, the mail provider’s own fingerprint, published sender policy, and whether the domain accepts every address put to it.
What a silent failure looks like
A model proposes an address in the shape a company usually uses. The domain accepts it — because it accepts everything, which is a policy some organisations deliberately adopt. A verifier reporting valid or invalid has nowhere to put that, so it reports valid. The message is accepted, discarded on the far side, and nothing anywhere reports an error. The address stays on the list, and the same thing happens next month.
None
the value of is_catch_all when it cannot be settled · most verifiers store false here
Why it exists
This domain met all four conditions.
The fourth is the one that disqualifies most software.
- 01The answer matters
- A wrong address is a message that never arrives and a sender reputation that quietly degrades. Enough of them and the domain itself stops being delivered.
- 02Nothing independent checks it
- A language model is fluent about facts it cannot verify. Asked for an address it produces a plausible one, and plausibility is precisely the failure mode — nothing about the output says which of them was guessed.
- 03A different second computation is possible
- DNS records, MX fingerprints and published sender policy are facts about the world that no amount of fluency can talk round. They are a genuinely different kind of thing from a generated string, which is what makes the check independent.
- 04The failure is silent
- A wrong address does not throw. It is accepted, queued, and discarded somewhere you cannot see — and a catch-all domain will accept every address you ever try, forever, without complaint.
Built for
Teams whose agents produce claims that something in the world can check.
Not for
Anyone wanting volume for its own sake.
The verification layer refuses proposals, so it returns fewer contacts than the generator produced. That is the product working. A buyer optimising for list size is buying the wrong half.
Four things it will not do.
Design decisions with reasons, not missing features. Each one is a thing the instrument could do and will not.
- It does not treat acceptance as proof.
- A domain that accepts every address it is offered is detected and flagged, and a proposal that would otherwise be marked safe to send is downgraded because of it. Acceptance is a fact about a server’s policy, not about a mailbox.
- It does not report a verdict as a boolean.
- Four states, and the catch-all field is itself three-valued: its null means UNKNOWN rather than false. An address nobody can settle is returned as unsettled rather than rounded to the convenient side.
- It does not block a role address.
- An address like support@ or contact@ is flagged and passed on, because "this is a shared mailbox" is a fact the sender should weigh, not a verdict the tool should reach for them.
- It does not send anything.
- Verification and outreach are different products with different obligations. Nexio establishes whether an address is reachable; what is written to it is somebody else’s decision.
The machinery
Eight layers, and the part of each that is actually hard.
None of this is specific to one domain. It is the same machinery we build into somebody else’s system, in whatever domain their expensive answer lives.
01
Local sanity, before anything is asked of the network
Syntax, typo detection against known providers, disposable-domain and role-account recognition. Cheap checks first, so the expensive ones are never spent on an address that was never plausible.
The hard part
A role account must be FLAGGED and not blocked. Refusing every shared mailbox would discard the correct address for most small organisations, where support@ is the only address there is.
02
DNS forensics — the part that cannot be reasoned with
MX record analysis and fingerprinting, provider identification, SPF and DMARC validation, domain age, and catch-all detection.
The hard part
Catch-all detection is the load-bearing piece and the one everyone omits. Without it, "the server accepted this address" is mistaken for "this address exists" — which is the same misreading the method page uses as its worked example, and it is worth money here.
03
The generative step, boxed in on both sides
A pattern is proposed from cache, from search evidence, or by a model. It arrives as a candidate and nothing more.
The hard part
The temptation is to let a confident model short-circuit the checks below it, because it is right most of the time. Most of the time is exactly the property that makes a silent failure silent.
04
A verdict with four states, and a tri-state inside it
Valid, invalid, risky and uncertain, carried with a separate recommendation — safe to send, likely valid, test at low volume, do not send.
The hard part
Keeping "unknown" distinct from "false" costs a field and a branch everywhere it travels. Collapsing them is one line, and it makes every downstream consumer confidently wrong about a whole class of address.
05
A feedback loop that closes on reality
Bounces are recorded against the pattern that produced the address, so the evidence for a pattern is what happened rather than what was expected.
The hard part
A bounce is late, noisy and sometimes not about the address at all. Treating every one as proof the pattern was wrong would unlearn correct patterns from a bad afternoon at somebody else’s mail provider.
How it is checked
Every figure is computed twice, by engines that share no code.
A checker that imports the model verifies that the solver ran. It does not verify that the answer is right.
The generator and the checker are different KINDS of thing
One is a model producing plausible text. The other is DNS lookups and protocol behaviour. They cannot share a failure mode, because they do not share a way of being wrong.
Six phases, and the model only speaks in one of them
Local sanity, DNS forensics, pattern proposal, digital footprint, scoring, and a feedback loop. The generative step is phase three, and everything after it exists to disagree with phase three.
Real bounces are fed back against the pattern
A proposal that looked right and was not is recorded against the pattern that produced it, rather than forgotten. The instrument learns which of its own guesses were wrong.
The uncertain answer survives to the caller
Greylisting, a timeout and a refusal are three different things, and the verdict says which. A layer that collapsed them would be reporting a policy as an absence.
Starting
What you need before the first run.
- An account
- NEXIO is behind a sign-in. The data inside belongs to whoever signed in, and it is not shared between accounts.
- One real case
- Not a sample. The instrument is only interesting on something you already have an answer for, because the first useful result is the two engines agreeing — or not — on a figure you can check yourself.
- Somewhere to disagree
- If the second engine contradicts you, that is the product working. It is worth deciding in advance who looks at a disagreement, because an alert nobody owns is an alert nobody reads.