Valid, Risky, Invalid, Catch-All: How to Read an Email Verification Report
An email verification report sorts every address into valid (the mail server confirmed the mailbox), invalid (it will bounce) or risky (the domain takes mail but the mailbox could not be confirmed). Catch-all is a kind of risky: the domain accepts any address, so the row is risky with reason "Accepts all addresses" and gets a higher, medium or lower likelihood grade. Send valid, test risky in small batches, and suppress invalid.
The columns
A SimpleVerifier results file keeps your original columns and adds:
| Column | What it holds |
|---|---|
status |
valid, risky or invalid |
reason |
The specific cause, in words |
send_advice |
safe, care, retry or do_not_send |
catch_all_confidence |
higher, medium or lower, on catch-all rows only |
catch_all_signals |
The signals behind that grade |
The reasons under each status
| status | Reasons | send_advice |
|---|---|---|
| valid | Mailbox exists | safe |
| risky | Accepts all addresses (catch-all), Role-based address, Provider hides mailbox status, Server would not confirm, Mailbox check unavailable | care or retry |
| invalid | Invalid format, No mail server, Typo domain, Disposable address, Mailbox not found | do_not_send |
Three risky reasons need a word:
- Accepts all addresses. We test a random address at the domain first. When it is accepted, no mailbox there can be confirmed.
- Provider hides mailbox status. Microsoft consumer mailboxes (outlook.com, hotmail.com, live.com). Microsoft is currently refusing mailbox checks from our server's network, so they are not probed. The domain receives mail; the mailbox is unconfirmed.
- Server would not confirm. The server refused or deferred our check. That is often a judgement about the checking server, not the address, so send advice is retry.
Provider behaviour is measured in our study of how 51 mailbox providers answer verification checks.
Reading catch-all rows
Catch-all is common on business domains (what to do with catch-all emails). Sort those rows on catch_all_confidence:
- Higher: the address matches the name format of confirmed addresses on that domain. Test first.
- Medium: mixed or weaker signals. Wait for the test result.
- Lower: several spellings of one name, placeholders, disposable or random-looking addresses. Usually drop.
The method and numbers are on the catch-all scoring page, and the full workflow is in catch-all emails: what to do.
Turn the report into three lists
- Send: status valid.
- Test: status risky, grouped by reason, best group first. Send 100 to 300 from a warmed inbox and compare the bounce rate.
- Suppress: status invalid. Keep them on a suppression list so they are not re-imported.
If your list lives in Instantly, Smartlead, HubSpot or Mailchimp, the native integrations write the status back to each lead as sv_status, so you can filter on it without moving files.
Run 100 free checks on a sample and read your own report with this page open.
Results not to act on blindly
- A "valid" on a catch-all domain from another tool. The server accepted a random address too, so that is a guess.
- Old results. A confirmed mailbox can close. Re-check results older than a few weeks before a big send.
- Valid role addresses. info@ and sales@ may exist but suit cold outreach poorly.
For how statuses map across other verifiers, read email verification statuses explained.
Common questions
What do valid, risky and invalid mean in an email verification report?
Valid: the recipient's mail server confirmed the mailbox exists. Invalid: the address will bounce, because of bad format, no mail server, a disposable or typo domain, or a mailbox the server says does not exist. Risky: the domain takes mail, but the mailbox could not be confirmed.
Is catch-all the same as risky?
In SimpleVerifier, yes. A catch-all domain accepts any address, so the row is risky with reason Accepts all addresses. It also gets a catch-all likelihood grade, higher, medium or lower, to help you rank those rows.
Should I send to risky emails?
Not as part of the main send. Group them by reason, send a small test batch from the best group from a warmed inbox, and compare the bounce rate before sending more.
Why are Outlook.com and Hotmail addresses risky?
Microsoft consumer mailboxes (outlook.com, hotmail.com, live.com). Microsoft is currently refusing mailbox checks from our server's network, so they are not probed and come back risky with reason Provider hides mailbox status. iCloud is probed and gets a per-mailbox answer.
What does send_advice retry mean?
The recipient's server did not answer our check, for example it refused or deferred the connection. A later check may succeed; treat the row as risky until then.
Check your list before you send
Real mailbox checks over SMTP, and nothing is sent to the address. Sign in with Google and your first 100 email checks are free, no card. Plans for bigger lists are on the pricing page.