Deliverable and undeliverable are the easy cases
Deliverable means every check passed and the mail server accepted the mailbox during the SMTP probe. The reason is always accepted_email. These addresses are safe to store and send to, with the usual caveat that any mailbox can disappear later.
Undeliverable means at least one check failed definitively. The reason tells you which: invalid_syntax for a malformed string, invalid_domain when the domain does not resolve, no_mx_record when it has no mail servers, rejected_email when the server replied 550 to RCPT TO, and mailbox_full when the server reported a quota problem. Remove these from your list or ask the user to correct them.
Risky means the address might work
Risky addresses passed the technical checks but carry a signal that makes them less trustworthy. The reason field is what you should branch on. Disposable addresses come from temporary inbox services and will stop working within hours. Role accounts like support@ or billing@ reach a shared inbox rather than a person. Catch-all domains accept every address, so the mailbox probe proved nothing.
Two further reasons, low_quality and low_deliverability, cover addresses with patterns associated with abuse or domains with a history of poor acceptance. The score field, from 0 to 100, summarizes how confident the service is across all signals.
{
"email": "anyone@catchall-corp.com",
"status": "risky",
"reason": "catch_all",
"score": 61,
"checks": { "syntax": true, "domain": true, "mx": true, "smtp": true,
"disposable": false, "role_account": false,
"catch_all": true, "free_provider": false },
"domain": { "name": "catchall-corp.com", "provider": "google",
"mx": ["aspmx.l.google.com"] },
"suggestion": null,
"billed": true,
"duration_ms": 842
}Unknown means the server did not answer
Unknown is the status people most often mishandle. It means the service could not complete the mailbox check: the server timed out, replied with a temporary greylisting code, or does not accept SMTP probes at all. The reasons are timeout, greylisted, and unavailable_smtp.
None of these say anything bad about the address. Many perfectly good corporate mailboxes sit behind servers that greylist unfamiliar connections. Treating unknown as invalid throws away real customers. VeriDock does not bill unknown results and makes re-verification within 30 days free, so the right move is to accept the signup and retry the check later.
Unknown is a statement about the mail server's behavior, not about the mailbox.
What your application should do with each status
The safest policies are simple and depend on where the check runs. At signup, block undeliverable, accept deliverable and unknown, and decide risky by reason: block disposable, accept role_account and catch_all, and send low_quality to review. For list cleaning, suppress undeliverable, keep deliverable, segment risky by reason, and retry unknown before the next send.
- deliverable: store it and send.
- undeliverable: reject or ask for a correction, using the suggestion field when present.
- risky: branch on reason; disposable is usually a block, catch_all is usually a keep.
- unknown: accept for now, retry within 30 days at no cost.
Key takeaways
0/4Try it on a real address
Run syntax, DNS, MX, disposable, and role checks on any address. No signup needed.
Frequently asked questions
Verify addresses with one API call
250 free checks every month, recurring. Unknown results are never billed.