The Email Deliverability Verdict: Send, Verify, or Drop an Address
You can score any single email address across seven signals and reach a defensible Send, Verify, or Drop verdict, each with its own handling rule.
Key takeaways
- Catch-all is a domain fact, not an address fact: a catch-all with a matching identity outranks one without, so identity match is the seventh signal that resolves the ambiguity.
- An SMTP 250 on a catch-all domain is a false positive by design - the server answers yes to every probe, so it reports the same result for real and fake local parts alike.
- The 0.3% spam-complaint rate is the enforcement cliff, not the target; practitioners operate below 0.08%, or fewer than one complaint per 1,250 sends.
- In Refolk's index, US RevOps professionals outnumber titled deliverability specialists roughly 130 to 1, so the send decision almost always sits with a generalist who needs a written per-verdict rule.
- Verification only removes the hard-bounce category; spam complaints are downstream of targeting, authentication, and copy, so treating one tool as fixing both is the most common structural error.
- A Valid verdict is perishable: lists decay roughly 2% per month and about a quarter per year, so re-verify any address older than 90 days before a major send.
This guide is for revenue operations, recruiting operations, and anyone who signs off on a send and is answerable for how the list was built. The job is narrow and repeated: take one sourced email address and decide whether it is safe to send to, needs a second channel or check first, or should be dropped before it reaches the queue. What follows is an owned scoring rubric - seven signals, three verdicts, a written handling rule for each - so a catch-all with a matching identity is treated differently from a catch-all with none, and two people grade the same address the same way.
Every ranking page for this problem is a vendor selling you a valid/catch-all/risky bucket and a 0-to-100 number it wants you to trust. None of them tell you what those signals actually prove, or what to do when they conflict. This gives you the model instead of the score.
Who actually makes this decision
The send decision almost always sits with a generalist, not a titled deliverability specialist. In Refolk's index of professional profiles, there are about 1,175 US Revenue Operations professionals against only 9 US deliverability specialists - roughly 130 to 1. That gap is the entire reason this rubric exists in writing.
Nobody has "deliverability" in their title, so the model has to be usable by a RevOps owner at the end of a busy day, not by a specialist with a mail server in a lab. A written per-verdict handling rule is what makes that possible: it removes the judgement from the moment of the send and puts it into a standard you agreed to once.
The population also tells you where the ambiguity concentrates. RevOps and recruiting operations both work B2B, and B2B is exactly the market where catch-all is thickest. That is not incidental. It means the middle verdict, Verify, is the one you will use most, and the one worth building carefully.
| Segment (US) | Count in Refolk's index | Named employers in sample |
|---|---|---|
| Revenue Operations | 1,175 | Mimecast, Pendo.io, MeridianLink |
| Recruiting / Talent Operations | 163 | Accenture, The Browser Company, Cursor |
| Deliverability specialists (US) | 9 | Marigold, Proofpoint, Hightouch |
| Deliverability specialists (UK) | 2 | Oracle, AI Global Media |
The seven signals and what each one proves
Score every address across seven signals. The discipline is not in the number of signals but in being honest about what each one proves and what it looks like when it lies. A signal that predicts engagement risk is not the same as one that predicts a bounce, and confusing the two is where most lists go wrong.
| Signal | What it proves | What it looks like when it lies |
|---|---|---|
| Syntax | Format only, nothing more | A perfectly formed address at a dead mailbox |
| MX record | The domain can receive mail | A live domain with no mailbox behind the local part |
| SMTP RCPT | A real mailbox on a normal server | A clean 250 on a catch-all that accepts everything |
| Catch-all | Domain-wide acceptance policy | Anti-spam software faking catch-all mode temporarily |
| Role-based | Engagement risk, not deliverability | A perfectly deliverable info@ that no human reads |
| Disposable | A throwaway domain by list match | A real domain misclassified, dropping a live lead |
| Identity match | A real person maps to the local part | An old profile for someone who has since left |
Read the table as a sequence of narrowing claims. Syntax proves the least - only that the string is shaped like an email. MX records prove the domain receives email, not that the address is valid. SMTP RCPT proves a real mailbox exists on a normal server, and it is the strongest automated signal you have until a catch-all defeats it.
Catch-all detection proves a domain-wide acceptance policy, not that a person exists. The point is to measure domain-wide acceptance without turning it into person-level proof. Role-based and disposable are classifications, not deliverability tests: they predict engagement risk and list hygiene, and a role account can be flawlessly deliverable and still hurt you because nobody reads it.
Identity match is the seventh signal and the one that resolves everything the others leave ambiguous. It asks a different question - does a real person map to this local part - and it is not a standard SMTP output. It is the signal that separates a catch-all worth sending to from one worth dropping.
Why SMTP alone cannot save a catch-all
An SMTP handshake cannot rescue you on a catch-all domain, because the server answers "yes" to every probe by design. Accepting everything is the whole point of a catch-all, so the server returns the same misleading 250 for real and fake local parts alike. A verification service can report deliverable:true for an address that is, for practical purposes, garbage.
This is the single most important mechanic in the whole rubric. It means you cannot trust a 250 in isolation on a B2B domain, and B2B is where you work. On B2B lists there is a 30-to-50% chance the list contains catch-all domains, and about 4 in 10 enterprise domains return an accept-all status from standard SMTP verification.
How a catch-all defeats an SMTP-only check
- RCPT probeServer returns 250 for the target mailbox
- Random-part probeServer also returns 250 for a made-up local part
- VerdictDomain is catch-all, so the first 250 proves nothing
- ResolveFall back to identity match, not another handshake
The move that resolves it is not another connection. You need a dedicated catch-all check that uses pattern confidence and secondary signals instead of a single SMTP handshake, and above all you need the identity match. When a verifier knows a domain is catch-all, the useful move is to lower confidence without binning the address - because info@ and sales@ on a catch-all are often exactly the leads you want.
On a catch-all domain the server says yes to everyone, so its yes is worth nothing until a real person answers it.
Questions practitioners ask
Should I send to a catch-all email address or skip it?
Neither automatically. A catch-all is a domain-wide accept-all policy, not a verdict on the person, so downgrade the confidence and require an identity match. A catch-all address with a real person mapped to the local part earns a Send on a secondary lower-volume domain; a catch-all with no identity match is a Verify at best, and a Drop if you cannot resolve it before the send window.
Is a role-based address like info@ or sales@ safe to email?
It carries engagement risk, not deliverability failure. Role accounts are often ignored or auto-deleted and represent no single person, which hurts inbox placement over time and can turn into a spam trap once abandoned. Treat role-based as its own flag separate from catch-all: send only when the context genuinely warrants a shared inbox, and never mix role addresses into a high-volume cold send.
What spam complaint rate is safe when sending?
Google, Yahoo, and Microsoft all enforce a hard limit of 0.3%, and Google targets below 0.1%. Practitioners operate stricter, at 0.08%, which is fewer than one complaint per 1,250 emails sent. The 0.3% figure is the cliff where you lose eligibility for mitigation, not a target to aim at. A list heavy with invalids and unresolved catch-alls pushes you toward that cliff within weeks.
When should I drop an email address before it enters the send queue?
Drop when the address fails the syntax or MX gate, matches a disposable domain, or is a catch-all with no identity match that you cannot resolve before the send. Also drop any unknown result that stays unresolved. The Drop verdict exists to keep your bounce rate under 2% and your complaint rate under the 0.08% operating line, both of which protect sender reputation.
How often should I re-verify a Valid email address?
Every 90 days for an active database, and always immediately before a major send. A Valid result is point-in-time: people abandon accounts, get terminated, or change jobs, so lists decay roughly 2% per month and about a quarter per year. A verdict has a shelf life, and re-verifying before a high-volume campaign corrects for a known decay rate rather than being optional hygiene.
Does an SMTP 250 response mean the email is valid?
Only on a normal mailbox server. On a catch-all domain the server answers 250 to every probe because accepting everything is the point, so it returns the same misleading yes for real and fake local parts alike. To tell whether a 250 is real, probe a random local part on the same domain; if that also passes, the domain is catch-all and the original 250 proves nothing about the person.
Try it on the search you came here for
Stop building boolean strings. Just describe the person.
Type one sentence. I plan the search, read GitHub, public LinkedIn and Crunchbase records, and the open web as it is right now, and hand back a ranked list with the reason next to every name.
01Describe them
One plain sentence. Role, city, stack, stage, whatever matters to you.
02I read the web live
GitHub, public LinkedIn and Crunchbase records, the open web. Not a database that went stale last quarter.
03You read the shortlist
Ranked, with the reasoning under every name. Open a profile, ask a follow-up, narrow it down.
- Staff backend engineers in NYC who shipped Rust in production
- Series A fintechs in SF under 50 people, growing headcount this year
- Maintainers of fast-growing Rust web frameworks on GitHub
- No boolean, no filters, no seat to buy. One box.
- Read at search time, so a profile updated yesterday counts today.
- Every step visible as it runs, every name with its reason.
500 free credits on sign-up. No card, no demo call. See real searches.