Email Verification Statuses: Safe, Risky, Invalid & Catch-All

Every email on a lead list carries a verdict: safe, risky, invalid — sometimes catch-all or unknown. Those labels decide your bounce rate, which decides your deliverability, which decides whether any of your outreach lands at all. This guide explains what SMTP email verification actually checks, what each status means, and the decision rules for acting on each one — whether your list arrives pre-verified or you run it through a checker yourself.

How SMTP email verification works (without sending an email)

A verifier walks the same path a real message would take, then stops just before delivery. Nothing is sent and nothing lands in an inbox — the verifier reads the mail server's responses along the way and turns them into a verdict.

The four checks, in order

• Syntax — is the address structurally valid? Catches typos like [email protected] and stray spaces. Instant, and instantly disqualifying when it fails.
• DNS and MX records — does the domain exist, and does it publish MX (mail exchange) records naming a server that accepts mail? A domain with no mail servers means every address on it is undeliverable, no further checks needed.
• The SMTP handshake — the verifier connects to that server and issues the opening commands of a real delivery: HELO, MAIL FROM, then RCPT TO with the address in question. The server's answer to RCPT TO is the verdict — a 250 accept, or a 550-class rejection meaning the mailbox doesn't exist. The verifier then disconnects without ever sending a message body.
• Flag checks — along the way, good verifiers also test whether the domain is catch-all (more on that below), whether the address belongs to a known disposable-email service, and whether it's a role account like info@ or billing@.

Two things stop this from being a perfect oracle. First, the SMTP commands originally built for direct mailbox queries (VRFY, EXPN) are disabled on almost every modern server, so verifiers must infer from delivery responses instead. Second, servers don't have to answer honestly or at all: large providers throttle unfamiliar IPs, greylisting temporarily rejects first-time connections by design, and catch-all servers say yes to everything. That's why verification returns graded statuses rather than a clean yes or no.

Email verification statuses, decoded

Safe (also called valid or deliverable)

The server confirmed this exact mailbox exists and accepts mail, and the domain isn't catch-all. This is the strongest signal SMTP verification can produce. Send with confidence — safe addresses are the backbone of any outreach list, and the larger the share of your volume that goes to them, the more slack you have everywhere else. One honest caveat: a mailbox that existed at verification time can be deleted later, so statuses age. Lists more than a few months old are worth re-checking before a big send.

Invalid (undeliverable)

The server rejected the mailbox, the domain has no mail servers, or the syntax is broken. An invalid address is a guaranteed hard bounce. Never send to one — not once, not to "see what happens." Every hard bounce is logged against your sending domain, and the damage compounds (the math is below). Delete the address but keep the lead: the business is still real, and a working phone number or an Instagram DM often does what the dead inbox can't.

Risky

Risky is an umbrella for deliverable-but-unproven. The most common cause by far is a catch-all domain, which gets its own section below. Verifiers also file full mailboxes, domains with aggressive filtering, and — in some tools — disposable and role accounts under the same label. A risky email address isn't a bad address; it's an unconfirmed one. Some portion of any risky pile is perfectly good. The question is whether you can afford to find out which portion, and at what volume.

Unknown

The server wouldn't give an answer. The usual culprits are connection timeouts and greylisting — an anti-spam technique where a server temporarily rejects the first connection from an unfamiliar sender with a 4xx "try again later" response, on the theory that legitimate mail servers retry and spam scripts don't. Good verifiers wait and retry, which resolves many unknowns into safe or invalid; some tools fold whatever remains into risky. Treat unknowns exactly like risky: possible, unproven.

Catch-all email meaning: the flag behind most of your risky pile

A catch-all domain (also called accept-all) is configured to accept mail addressed to any mailbox — real or not. Companies set this up so a message to jon@ still arrives when the sender meant john@, or so mail to departed employees isn't lost; some security gateways also accept everything deliberately, precisely to defeat the kind of probing that verifiers do.

Verifiers detect it with a simple trick: alongside your address, they probe an obviously fake mailbox like x7q9zk2@ on the same domain. If the server accepts that one too, its acceptances are meaningless — it would have said yes to anything. The verifier can still confirm the domain is real and receiving mail, but no SMTP check can confirm your specific mailbox on that server. That is the honest ceiling of the technique, whatever any vendor's marketing implies.

How common is this? Estimates vary widely by data source and market. ZeroBounce reported that just over 9% of all emails it processed in 2025 came back catch-all, while B2B-focused vendors put the share of business leads sitting on catch-all domains anywhere from 15% to 40% or more, skewing higher for larger companies and certain hosted-email defaults. Whatever the true number in your niche, the practical point stands: a meaningful slice of every business list will be catch-all, so you need a policy for it rather than a delete key.

Should you send to catch-all addresses?

Yes, carefully — deleting every catch-all throws away real prospects. The rules that keep it safe:

• Segment them out. Never mix catch-alls into your main sequence; their bounces should be quarantined where they can't taint your best domain.
• Send from a secondary domain. If a batch goes bad, the reputation damage lands somewhere you can afford to rest.
• Small batches, watched closely. Start with 50–100, check the bounce rate, and pause the segment the moment it climbs past a couple of percent.
• Weight by evidence. A catch-all address matching the owner's name at a business with a live website and recent reviews is a far better bet than a pattern-guessed address at a dormant one.
• Provenance beats status. If the address came from the business's own website or a form fill, the catch-all flag mostly reflects their server configuration, not the address's quality.

Email bounce rate math: why one bad send costs more than one bad row

Mailbox providers grade senders continuously, and since February 2024 the grading has been explicit: Google and Yahoo's bulk-sender requirements demand SPF, DKIM, and DMARC authentication, one-click unsubscribe, and a spam-complaint rate below 0.3% — with Google recommending you stay under 0.1%. Bounce rate has no equally official ceiling, but the working consensus among deliverability teams is to keep hard bounces under 2%, ideally under 1%, because that's where inbox placement measurably starts to slip.

Run the arithmetic on an unverified list. Suppose you pull 2,000 addresses and 8% are dead — not unusual for unverified scraped data. Send to all of them and you've produced 160 hard bounces: an 8% bounce rate, four times the consensus danger line, in a single campaign. The provider's filters don't just discard the 160 failures; they downgrade your sender reputation across the whole domain, so the 1,840 legitimate emails start landing in spam too. Verify first and the same list yields the same 1,840 good sends with a bounce rate near zero.

That asymmetry is the entire argument for verification: an invalid address costs nothing sitting in a spreadsheet and quite a lot the moment you send to it. Recovery isn't symmetric either — sender reputation lost in an afternoon typically takes weeks of careful, low-volume sending to rebuild. One clarification worth making: soft bounces (full mailboxes, temporary server errors) are a different animal. They resolve on their own and don't carry the same penalty. The 2% concern is hard bounces.

When should you send to a risky email address?

A decision checklist, because "it depends" helps no one.

Send — carefully — when

• The address's provenance is good: it appeared on the business's own website or materials rather than being pattern-guessed.
• Other signals corroborate the lead — an active website, recent reviews, an address that matches the owner's name.
• You can route it through a secondary sending domain in small, monitored batches.
• Your current bounce rate has room: a few failures won't push you near the danger line.

Skip when

• The address was guessed from a name pattern with nothing to corroborate it.
• You have exactly one sending domain and no way to isolate the risk.
• Your bounce rate is already flirting with 2%.
• You have enough safe addresses to hit your volume targets anyway — confirmed volume beats speculative volume every time.

One more honest note: risky segments only pay off if someone actually watches them. If nobody on your team will check the bounce dashboard after each batch, treat risky as invalid and spend that time on phones and socials instead.

Role-based email addresses: the local-business exception

Standard cold-email advice says never contact role-based addresses — info@, office@, sales@ — because at a large company they're shared inboxes where the easiest response to a cold email is the spam button, and spam complaints are the one metric with a hard published ceiling.

That advice was written about enterprises, and local businesses break it. At a four-person plumbing company, info@ frequently is the owner — it's the address on the website, the van, and the Google listing, and it's read by the person who signs the checks. Discard every role address from a local-business list and you can end up discarding most of the list.

The workable rule: prefer a personal address when you have one; use the role address when it's what the business itself publishes; and when you write to one, open with something that proves you know this specific business — the town, the trade, a recent review. Generic openers to shared inboxes are what actually draw the complaints.

Turning statuses into a working process

Everything above compresses into three habits. They cost minutes per campaign and they're what actually protects cold email deliverability over the long run.

• Segment on status the day the list arrives: safe goes to the main sequence; risky and catch-all go to a secondary domain in small batches; invalid is suppressed from email but kept for phone and social outreach.
• Watch two numbers per segment: hard-bounce rate (keep it under 2%) and spam-complaint rate (under 0.1%, per Google's own recommendation).
• Re-verify anything older than a few months before a large send — statuses decay as mailboxes are created and deleted.

Full disclosure of our bias: LeadMarina sells lead generation with verification built in, so of course we think verification matters — but the math above holds whoever you verify with. In our case, every lead arrives with up to three emails already SMTP-checked and labeled safe, risky, or invalid, alongside up to three phones with line type and carrier, socials, and the full business profile — so the segmentation described here starts from labels you already have, not a verification project you still have to run. From there you can push leads straight into Close, GoHighLevel, or Google Sheets, and the free plan's 100 leads are enough to test these statuses against your own sending data. The quick-start guide covers the whole flow.

Quick answers

What does a risky email address mean?

Deliverable but unconfirmed. The mail server accepted the address, but something — usually a catch-all configuration — prevents the verifier from proving the specific mailbox exists. A portion of risky addresses are perfectly good; send to them only in isolated, monitored batches from a secondary domain.

What is the catch-all email meaning in verification results?

The domain accepts mail for every address, real or fake, so an SMTP check can confirm the domain but not your specific mailbox. It's a property of the server, not a judgment of the address — which is why provenance and corroborating signals, not the flag alone, should drive the send decision.

Can SMTP email verification be 100% accurate?

No — and be wary of anyone claiming otherwise. Catch-all servers, greylisting, and providers that throttle verification probes put a hard ceiling on certainty. What verification does reliably is remove guaranteed bounces and grade everything else, and that's what protects the bounce rate that actually governs deliverability.