Verification and Catch-All Handling
Outcome: every found address carrying a verification status, a written catch-all policy, and a sending list that contains only what you can defend.
- Surface
- App and MCP server
- Level
- Beginner
- Uses
verify_email- Credits
- ~0.3 per row
- Prerequisite
- Lesson 02's found addresses
Two steps, not one
Finding an address and confirming it exists are different operations against different systems.
- Find returns a candidate. It may come from a provider’s database, or from a pattern applied to a domain.
- Verify checks the mailbox at the receiving server, and returns a status.
Skipping the second means shipping guesses. The cost of that is not the wasted send — it is the sending domain’s reputation, which takes weeks to recover and degrades every campaign in the meantime.
Reference: Verify email, verify_email.
The statuses
| Status | Meaning | Send? |
|---|---|---|
| Valid | Mailbox confirmed to exist | Yes |
| Invalid | Confirmed not to exist | Never |
| Catch-all | Domain accepts everything; this mailbox cannot be confirmed | Depends — see below |
| Unknown | Server did not answer conclusively | Treat as catch-all, or retry later |
| Disposable | Temporary or throwaway domain | Never |
| Role | info@, sales@, support@ | Segment-dependent |
Only valid counts as contactable in every number you report. Everything else is a separate bucket with its own policy.
Catch-all domains
Some mail servers accept messages to every address at the domain, so no external check can confirm whether a specific mailbox exists. This is common at larger organizations and at anyone using certain security gateways.
Three defensible policies:
Drop them
Safest. You lose real people — often a meaningful share at enterprise accounts, since catch-all configurations skew large.
Separate sequence on a secondary sending domain
The sensible default. Lower volume, isolated reputation risk, and you learn the actual bounce rate for that bucket without endangering your primary domain.
Send normally
Only when catch-alls are a small share of the list and your sender reputation has genuine headroom. Measure before deciding this, not after.
Never mix policies within one sending domain. If catch-alls are going out at all, they go out from somewhere whose reputation you can afford to lose. The whole point of the separate domain is that a bad bucket cannot damage the good one.
Bounce-rate thresholds
The numbers that make this concrete:
| Bounce rate | Consequence |
|---|---|
| Under 2% | Healthy |
| 2–5% | Warning zone; providers begin to notice |
| Above 5% | Filtering, throttling, and reputation damage that persists for weeks |
| Above 10% | Sending domain effectively burned for cold outreach |
A verified list typically lands under 2%. An unverified one lands anywhere between 8% and 30% depending on segment. That gap is what this lesson is about.
Role addresses
info@, hello@, sales@, support@. Verification usually confirms these exist, which is not the same as them being useful.
| Segment | Verdict |
|---|---|
| Local business, trades, clinics | Yes — the owner reads it, often the only route in |
| Small agencies and consultancies | Usually yes |
| Mid-market B2B | Rarely — routed to support or ignored |
| Enterprise | No |
And the message must change: a shared inbox is read by someone busy who did not ask to hear from you.
Do this now
Verify every found address
The whole column, not a sample.
Count the statuses
Valid, invalid, catch-all, unknown, disposable, role. Record the distribution.
Compute your real contactable count
Valid only.
Decide the catch-all policy
Based on what share of your list they are.
Set up the secondary domain
If you chose the separate-sequence policy. Do this before the first send, not after.
Filter the export view
Valid only, or valid plus catch-all routed separately.
Recompute hit rate
Verified hits ÷ rows attempted. This number is lower than lesson 02’s and it is the honest one.
Check your work
- Every address has a status
- Only
validcounts in your contactable number - Catch-all policy is written and implemented as a filter
- Disposable and invalid addresses are excluded
- Your verified hit rate is recorded, replacing the unverified one
Where this breaks
Sending to an unverified list to “test deliverability” destroys the thing you were testing. There is no small-scale version of this experiment: a few hundred bounces is enough to register with the major providers, and the domain carries that history forward. Verify first. There is no case where the reverse order is correct.
Further automation
Verification decays. An address valid today can be dead in six months, and re-verifying everything quarterly is expensive. The cheaper loop is re-verify on bounce, plus a scheduled job-change check that tells you who moved — then re-enrich only those. Lesson 08 sets the cadence.
Next lesson
04 — Personal email, and when to use it, the fallback path and the rules around it.
Reference for this lesson: Verify email, verify_email, Emailable, Outreach integrations.