Every verification result explained — and what to do with each

Here's the whole thing in one line: deliverable → accept, undeliverable → block, risky/role/disposable → flag or challenge, catch-all → flag (can't confirm), unknown → retry, then flag. The sections below define each status precisely, give the safe default action, and then show how to assemble those actions into two policies — one strict enough for a real-time sign-up form, one pragmatic enough for a bulk list you already own. If you want the mechanics behind these labels, see how verification works.

Deliverable → accept

The receiving server confirmed the mailbox exists and would accept mail: syntax passed, the domain has valid MX records, and the SMTP RCPT TO probe returned a clean 250 on a domain that is not catch-all. This is the one unambiguous "yes". Action: accept and send. These addresses are safe for your primary sends and are exactly what you want the bulk of a cleaned list to be.

Undeliverable → block

A definite no. The address failed at a stage that can't be recovered: invalid syntax, a domain with no mail servers (or a Null MX), or an SMTP 550-class rejection meaning the mailbox doesn't exist. Sending here produces a hard bounce, and hard bounces are the single biggest driver of a wrecked sender reputation. Action: block and suppress permanently. Never send, and add the address to a suppression list so it can't be re-imported on your next sync. (Why bounces matter this much: reduce your bounce rate.)

Risky → flag (and often challenge)

"Risky" is a bucket, not a single condition — it means the address is technically deliverable but carries a quality or reputation concern. The common members:

• Role-based (info@, support@, sales@): routes to a shared inbox, higher complaint and unsubscribe risk. Detect with the Role-Based Checker.
• Disposable / temporary: deliverable today, gone next week — junk data by design. Catch with the Disposable Checker.
• Other low-quality signals: spam-trap-like patterns, or full mailboxes returning soft-full responses.

Action: flag, and challenge at the point of entry. On a sign-up form, that means rejecting disposables and asking for a real address; in bulk, it means segmenting these into a lower-priority stream rather than blasting them alongside your best contacts. The disposable & role-based guide gets into block-vs-flag-vs-allow per type.

Catch-all → flag (you genuinely can't confirm)

A catch-all (accept-all) domain returns 250 for every address, so the SMTP probe can't distinguish a real mailbox from a typo — both get accepted. The verifier is being honest, not lazy, when it declines to call this deliverable. Action: flag; treat with measured caution, don't auto-delete. Many perfectly good business domains on Google Workspace and Microsoft 365 are catch-all, so blanket-blocking them throws away real customers. Identify them with the Catch-All Checker, segment them out of your riskiest sends, and lean on engagement history to decide. The catch-all decision framework covers when it's safe to mail them.

Unknown → retry, then flag

The verifier couldn't get a definitive answer — usually greylisting (a deliberate temporary 4xx), tarpitting/timeouts, or a server that accepts everything and bounces later. Unknown is not the same as bad; it's "ask again." Action: retry with backoff, and if it stays unknown, treat it as risky — flag, don't block outright. A good verifier already retries transient failures for you; what's left after retries is a small residue you handle by policy, typically by holding it out of high-stakes sends and watching whether it engages.

Turn statuses into a policy: sign-up forms vs bulk lists

Same statuses, different tolerances — because the cost of a wrong call differs. At a sign-up form you're protecting data quality at the source and you can ask the user to fix it in real time, so you can afford to be strict. On an existing bulk list you're protecting reputation without a chance to re-prompt anyone, so you segment rather than delete.

• Sign-up form (strict, real-time): block undeliverable and disposable outright and prompt for a correct address; allow deliverable; for role, catch-all and unknown, accept but tag the record so downstream sending can treat it carefully. Keep the check fast — verify a single address with the Email Verifier at submission.
• Bulk list (pragmatic, segmented): suppress undeliverable permanently; send confidently to deliverable; move risky, catch-all and unknown into a separate, lower-volume re-engagement segment and let engagement decide their fate. Score the whole file first with the Email List Health Report so you know the mix before you plan the send.

Verify it on your own data

Run a mixed sample through the Email Verifier and map what comes back to the actions above — you'll quickly see which of your contacts are safe, which to suppress, and which need a policy decision. For a whole list, the List Health Report gives you the status breakdown at a glance. Fold the result into the list-cleaning workflow, and set a cadence with how often to re-verify so today's clean statuses don't quietly rot.

Common mistakes reading results

• Deleting catch-all and unknown as if they were undeliverable. They're unconfirmed, not dead — deleting them discards real customers.
• Sending to risky the same as deliverable. Role and disposable addresses drive complaints; segment them, don't merge them.
• Never suppressing undeliverables. If a hard bounce can be re-imported, you'll keep re-mailing it and keep hurting your reputation.
• Expecting zero unknowns. A residual unknown rate is normal and honest — the SMTP protocol can't confirm every address, and a verifier claiming otherwise is guessing.