Email validation API: valid, risky, catch-all, and unknown explained
How to interpret validation API results without treating SMTP evidence as magic certainty.
APIValidationList hygiene
Why validation statuses are not all equal
Mailbox providers do not all answer SMTP probes the same way. Some confirm users, some hide existence, some greylist, and some accept every address at the domain. That is why WillItInbox separates status, sub-status, confidence, and evidence.
| Result | Meaning | Default policy |
|---|---|---|
| valid | The mailbox appears reachable. | Accept and monitor bounces |
| invalid | Syntax, DNS, or mailbox evidence says it should fail. | Suppress |
| risky | Role, disposable, catch-all, or policy signals increase risk. | Segment or review |
| unknown | The provider did not produce reliable evidence. | Retry or send conservatively |
Catch-all is not valid
A catch-all domain accepts random local parts. That means SMTP acceptance does not prove the specific person exists. For cold outbound, catch-all addresses should usually be sent at lower volume. For product signup, you may still accept them but should watch activation and bounce signals.
How to integrate the API
- Use single validation in forms where quality matters.
- Use batch validation for small CRM or enrichment jobs.
- Use bulk validation for CSV imports and campaign hygiene.
- Tie validation policy back to deliverability checks using the sample report.
If you need the broader list hygiene strategy, read the existing list hygiene and sunsetting guide.
Keep reading