Why NexiphorVerifier
Email verification is not simply good or bad. The useful question is how much we actually know about an address — and whether that is enough to act.
When the evidence says Valid, we say Valid. When it says Risky, we say Risky. When the probe cannot establish the answer, we say Unknown. We do not turn uncertainty into a green badge because a cleaner dashboard looks better.
The problem
A mail server can accept a recipient without proving that the intended mailbox exists. A probe can also fail because the server delayed, filtered, or blocked the attempt.
Those are different situations. History makes that visible — Valid, Risky, Invalid, and Unknown sit side by side instead of collapsing into good and bad.
The catch-all
Imagine a server that accepts every random address you send it. The first 250 is not proof of a person. Nexiphor keeps that as Risky — catch-all detected.
That distinction matters when a green badge becomes a send decision.
Four results
Status is not decoration. It is the next action, with a reason you can explain.
Did the mail server accept this address?
Yes — this address, not a fake one.
Mail server accepted it. Their mail server accepted this address and rejected a fake one. Status is Valid. Score is ordinal evidence strength (not 100% certainty). Send with caution. This is not Mailbox confirmed.
recipient_accepted_discriminated
Send with caution
Do we have evidence this address should not be used?
Yes.
Syntax, a reserved or non-routable domain, a known disposable domain, missing MX, or a definitive mailbox rejection.
invalid_syntax · disposable_domain · mx_not_found · smtp_rejected
Remove / block
Is the status hiding more than one claim?
Yes — three.
Risky means do not treat it as confirmed. Domain accepts unknown addresses: their server accepts every address. Accepted — limited verification: the mail server accepted this address, but there is no independent confirming signal. Accepted by receiving server: supporting signs are strong, but there is no mailbox-specific confirmation. Mailbox full: do not send right now. Only Confirmed is safe to send.
catch_all_detected · provider_non_authoritative_rcpt · mailbox_full
Read the claim, then send with caution or try later
Did we actually establish the answer?
No.
Timeout, greylist, probe blocked, or the mail server was unreachable. Unknown is also refunded.
smtp_timeout · smtp_temp_fail · smtp_blocked · smtp_unavailable
Wait / retry / do not pretend
Evidence
The report keeps the reason, the signals, the host, and the technical path with the classification. Export carries the same evidence — not just a label.
Unknown
If verification cannot reach a definitive result, Nexiphor keeps the uncertainty visible and returns the credit.
See the refund policy.
The principle
Your list does not become safer because the dashboard looks greener.
Risky is not Valid with extra steps. We would rather leave one address unresolved than turn uncertainty into a green check.
Limits
How this is used
Clean the file before the campaign. Check the address before the lead enters a sequence. When the server is ambiguous, do not turn it into Valid. Weeks later, re-verify — lists rot.
Your job is to decide who to send to.Ours is to tell you what the evidence actually supports.
