Valid
Do we have evidence the mailbox exists?
Yes.
The mailbox accepted without catch-all ambiguity — SMTP, or an authoritative provider path corroborated with SMTP. Not an inbox-placement guarantee.
mailbox_exists
Send / accept
Why NexiphorVerifier
Confidence overfalse certainty.
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
Not every 250 means the same thing.
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
A 250 is not always the answer.
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
Four results. Four different decisions.
Status is not decoration. It is the next action, with a reason you can explain.
Invalid
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
Risky
Is there a reason to proceed carefully?
Yes.
Catch-all, non-authoritative acceptance, mailbox full, or a toxic / possible spam-trap signal. Role accounts are labeled separately so you can filter them — they do not change this status by themselves.
catch_all_detected · provider_non_authoritative_rcpt · mailbox_full
Review / suppress / use with context
Unknown
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
Don't just give me a verdict. Show me why.
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
Don't charge for an answer you couldn't establish.
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
Knowing what we don't know matters too.
- We do not claim inbox placement. SMTP verification tells you what the verification path established. It does not guarantee what happens after you press Send.
- We do not claim perfect accuracy or zero bounces. Catch-all detection, disposable lists, and trap signals are real checks — not omniscience.
- We do not invent certainty when a server blocks the probe. That is Unknown, not Invalid.
How this is used
Before you send. Before it enters the sequence. Again later.
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.
Read the evidence·Pricing·Clean a list·A single check·Lists that rot