You ran a list through a verifier and got back a column full of labels: valid, invalid, risky, catch-all, disposable. Now what?
Each of these statuses means something specific, and treating them all the same — send to “everything that isn’t invalid,” say — will still get you burned by some of them. Here’s what each one actually means, where it comes from technically, and what to do about it, plus a few less common statuses you might run into depending on which tool you’re using.
Valid
The mailbox exists and the mail server confirmed it’ll accept messages. This is the highest-confidence status a verifier gives, based on the address passing syntax, MX, and SMTP-level checks cleanly. In technical terms, this usually corresponds to the receiving mail server returning a 250 response to the RCPT TO step of the SMTP handshake, on a domain that isn’t flagged as catch-all.
What to do: Send to it. This is the group your campaign should be built around, and for most lists, it’s the largest bucket by far — if it isn’t, that’s a sign something’s off with how the list was collected in the first place.
Invalid
Something concrete failed — no MX record on the domain, or the mail server explicitly rejected the address (a 550-style SMTP response, meaning “no such user”). This isn’t a maybe. It’s a fairly confident “this will bounce.”
What to do: Don’t send. Remove it from your list, or if it’s a customer/lead record, flag it for someone to follow up on through a different channel. There’s rarely a good reason to keep sending to a confirmed-invalid address on the theory that it might come back — if a domain has genuinely gone away or a mailbox is confirmed rejected, waiting doesn’t usually change that outcome.
Risky
This is the label that confuses people most, because it sounds like a softer version of “invalid” when it’s really its own category. Risky usually means the verifier couldn’t get a clean yes or no — the mail server gave an ambiguous or temporary response, or something about the domain’s mail setup made a definitive check impossible. Technically, this often maps to a 4xx-series temporary SMTP response, or a server that responded inconsistently across retry attempts.
What to do: Depends on your risk tolerance. For a small, high-value list (like sales outreach to specific named prospects), it’s often worth sending anyway and watching for a bounce. For a bulk marketing send where sender reputation matters more than reaching every last contact, it’s often safer to exclude risky addresses or send to them in a separate, smaller batch you can watch closely. Segmenting risky addresses into their own send, rather than either fully including or fully excluding them from the main batch, is a reasonable middle path a lot of experienced senders use — it isolates the uncertainty to a smaller group instead of letting it dilute your whole campaign’s bounce rate.
Catch-all
The domain accepts mail to any address, valid or not — so the verifier genuinely cannot confirm whether this specific mailbox exists. This isn’t the tool failing. It’s a real limitation of how that domain is configured, and it applies to every verification tool checking that domain, not just this one. Technically, this status comes from a separate test: sending a deliberately fake RCPT TO to the same domain and observing whether the server accepts that too. If it does, every address at that domain gets the catch-all label rather than a confident valid or invalid.
What to do: Treat catch-all addresses as a middle-confidence group, similar to risky. Many catch-all domains are legitimate small businesses that just haven’t configured strict mailbox rejection — the address may well be real. But you can’t be certain from the check alone. If the contact matters enough, other verification signals help fill the gap — has this person replied to a previous email, do they show up in other business records, does the name match a real employee on the company’s team page.
Disposable
The domain matches a known temporary/throwaway email provider (Mailinator, Guerrilla Mail, and similar services) — commonly used by people who don’t want to give a real address, often to avoid follow-up emails or to get past a gated download without commitment.
What to do: Almost always exclude these from marketing sends. Someone using a disposable address usually isn’t a real, sustained lead. That said, context matters: if you’re validating support tickets rather than marketing prospects, a disposable address might just mean someone was cautious, not fake.
Less common statuses worth knowing
Beyond the five core statuses above, some tools surface a few additional, more specific labels. Not every verifier uses these exact terms, but it’s worth recognizing the underlying situations they describe:
Role-based. Addresses like info@, support@, sales@, or admin@ aren’t tied to a specific individual — they’re mailboxes a whole team or department might monitor. These are often technically valid and deliverable, but they behave differently for engagement purposes: no single person “owns” the address, open and click tracking gets muddier, and unsubscribe requests can come from anyone with access to the shared inbox. Some verifiers flag these separately so you can decide whether they belong in a personal outreach campaign at all.
Unknown/undetermined. Occasionally a check simply can’t complete — a timeout, a server that refused the connection outright without giving any interpretable response, a DNS resolution failure that wasn’t a clean “no MX record” but also wasn’t a successful lookup. This is different from risky in that it’s not really a signal about the address at all; it’s closer to “the check itself didn’t finish,” and usually the right move is to retry rather than treat it as meaningfully negative.
Full mailbox. Some mail servers respond with a specific code indicating the mailbox exists but is currently over its storage quota. This confirms the address is real (someone set it up and has presumably used it) while telling you delivery right now might fail. It’s a fairly rare status to see explicitly, but worth knowing it’s a distinct case from either valid or invalid — and a good candidate for a delayed retry rather than either an immediate send or an outright exclusion.
Where these statuses come from
Each one maps to a specific layer of the check — syntax, MX record, SMTP handshake, or catch-all/disposable domain matching. We walk through those layers in more depth in what an email verifier actually checks, if you want to understand why a given address landed in a given bucket rather than just what to do about it.
How to build a sending policy around these statuses
Rather than deciding case-by-case every time you get a batch of results, it helps to write down a simple policy once and apply it consistently. Something like this works for most bulk sending contexts:
Valid — always include.
Invalid — always exclude, and remove from the underlying list/CRM record so it doesn’t reappear in a future export.
Disposable — exclude from marketing; use judgment for support/transactional contexts.
Risky and catch-all — include in a separate, smaller test batch on your first send to a given list; if the bounce rate on that batch comes back low, treat future occurrences from similar domains with more confidence going forward.
Role-based (if your tool flags it) — exclude from personalized outreach sequences specifically; fine to keep for general company-wide announcements if that’s genuinely who you’re trying to reach.
Unknown/undetermined — retry once before making any sending decision; don’t treat a failed check as equivalent to invalid.
Having this written down once means every future list gets handled the same, consistent way, rather than a fresh judgment call each time that might drift depending on how much time pressure you’re under that particular week.
A quick example
A nonprofit’s development team — call the org Fieldstone Trust — runs their 8,000-contact donor list through a verifier before their year-end appeal. The results split roughly like this: 6,900 valid, 400 invalid, 500 risky, 150 catch-all, 50 disposable.
If they’d only excluded the obviously invalid ones, they’d still be sending to 700 risky and disposable addresses that were unlikely to ever open the appeal, taking on bounce risk for essentially zero return. Understanding what each status actually means let them make a real decision: send to valid, hold catch-all and risky for a smaller test batch, and drop invalid and disposable entirely.
What made the difference for Fieldstone specifically was the test-batch approach for their 650 combined risky and catch-all addresses. Rather than an all-or-nothing call, they sent the year-end appeal to that group two days after the main send, watched the bounce rate come back at a manageable level, and confirmed several of those “uncertain” addresses were, in fact, real donors who’d simply had their company’s mail server configured as catch-all. Treating that middle group as genuinely uncertain — rather than assuming it meant “probably bad” — recovered contacts that a stricter policy would have quietly dropped.
Does a “valid” status guarantee delivery?
No — and this is worth saying plainly rather than glossing over. Valid means the mailbox accepted mail at the time of the check. Mailboxes get closed, domains lose mail servers, and inbox placement (whether it lands in the primary inbox vs. spam) is a separate question from whether the mailbox exists at all. Verification reduces your bounce risk close to zero. It doesn’t reduce it to zero, and no tool that says otherwise is being straight with you.
It’s also worth separating two distinct things people sometimes conflate: whether an address is deliverable (does the mailbox exist and accept mail) and whether a message actually lands in the primary inbox versus a spam folder. Verification speaks to the first question. The second depends on a whole separate set of factors — sender reputation, authentication records like SPF and DKIM, content and engagement history — that verification alone doesn’t control.
How different tools label the same underlying result
One frustration worth naming directly: there’s no single industry-wide standard for what these statuses are called. One tool’s “risky” might be another tool’s “unknown” or “accept-all.” One tool might fold catch-all into risky rather than giving it a separate label. This isn’t necessarily a sign that one tool is better or worse than another — it’s more that the underlying technical reality (a spectrum from “confirmed real” to “confirmed dead” with a genuinely ambiguous middle) doesn’t map perfectly onto any one naming scheme, and different providers have made different choices about how to carve it up for their users.
What matters more than memorizing any specific tool’s exact label set is understanding the three real categories underneath, regardless of what a given tool calls them:
Confirmed good — whatever the tool calls it, this means the SMTP check got a clean accept and the domain isn’t catch-all.
Confirmed bad — a clean reject, or a domain with no mail server at all.
Genuinely uncertain — everything else: catch-all domains, ambiguous SMTP responses, timeouts, temporary failures.
If you’re ever unsure what a specific label from a specific tool means, this three-way framework is the right question to ask: which of these three buckets does this status actually belong to, underneath whatever word the tool chose to use for it.
Why lumping “risky” and “invalid” together is a common, costly mistake
It’s worth spending a little more time on this specific mistake because it’s so common and so avoidable. A team under time pressure — a campaign launching tomorrow, a list that needs cleaning today — will sometimes simplify their own decision-making by treating anything that isn’t a clean “valid” as unsafe to send to. This feels conservative and cautious, which is exactly why it’s an easy trap to fall into.
The actual cost shows up in two ways. First, you lose real, reachable contacts — a meaningful share of catch-all and risky addresses genuinely are live mailboxes, and excluding all of them outright means quietly shrinking your addressable audience for no good reason. Second, and less obviously, it can distort how you read your own results going forward. If you’re excluding a third of your “uncertain” bucket every time without ever testing whether they’d have converted, you never build the information you’d need to make a smarter, more nuanced decision later. Segmenting those addresses into a small test batch instead — as described in the Fieldstone Trust example above — costs a little more setup effort but actually resolves the uncertainty over time rather than perpetually avoiding it.
A second example: how status distribution can flag a bad lead source
Beyond deciding what to do with a single list, the overall distribution of statuses across a batch can tell you something useful about where the list came from in the first place. A list with a status breakdown skewing heavily toward valid, with only a small single-digit percentage split across invalid, risky, and disposable combined, generally reflects a healthy, organically-collected opt-in list.
A list with a large chunk landing in disposable specifically — well above what you’d expect from typical signup behavior — often points to a lead magnet or gated-content form that’s attracting people trying to avoid marketing follow-up rather than genuine prospects. And a list with an unusually high invalid rate, especially if the addresses were sourced from a third-party tool rather than direct opt-in, often indicates the source was guessing at email formats rather than confirming real ones. In both cases, the status breakdown itself becomes a diagnostic tool for evaluating your lead sources, not just a per-address decision aid.
Check where your list actually falls
Run a list through the bulk verifier on sfemailverifier.com and see the real breakdown — valid, invalid, risky, catch-all, disposable — instead of guessing. For a single address, the homepage checker gives you the same statuses in seconds, and for an ongoing signup flow, the developer API returns the same status set programmatically so your own system can act on each label automatically.
Questions
Frequently asked questions
What’s the difference between invalid and risky?
Invalid means the verification found a concrete reason the address is unlikely to work, such as a dead domain or an explicit mailbox rejection. Risky means the available signals are mixed or inconclusive. It isn’t a confirmed failure.
Should I ever send a risky email?
It depends on the situation. For a small number of important, individually researched contacts, sending may be reasonable if you’re prepared to monitor the result. For large campaigns where sender reputation matters, excluding risky addresses is generally the safer default.
Is a catch-all domain the same as a fake email?
No. A catch-all domain simply means its mail server accepts messages for addresses across the domain, making it impossible to definitively verify a specific mailbox. The address itself could be completely legitimate. Catch-all is an ambiguous result, not proof that an address is fake.
Why would someone use a disposable email address?
Often to access something such as a free trial, download, or signup without giving out a personal inbox that will receive future marketing messages. Disposable status therefore says more about a user’s desire to avoid ongoing email communication than whether the person or address is fake.
Can I completely trust a “valid” status?
Treat it as a high-confidence result, not an absolute guarantee. It indicates that the mailbox appeared reachable when checked. Email accounts can later be closed, deactivated, or otherwise become unavailable.
What’s a role-based email, and should I treat it differently?
A role-based address, such as info@, sales@, or support@, is typically monitored by a team rather than an individual. It can be technically deliverable, but it behaves differently for personalized outreach because there may not be a single person responsible for the inbox.
Why did some addresses come back as “unknown”?
Usually, the verification process couldn’t be completed cleanly. Possible causes include a timeout, connection refusal, or an unexpected DNS issue. An “unknown” result generally means the check should be retried rather than indicating that the address itself is invalid.
Should I remove risky and catch-all addresses from my CRM entirely?
Generally, no. It’s better to exclude them from a particular campaign rather than delete the records. Risky and catch-all statuses represent uncertainty rather than confirmed problems, and deleting those contacts could mean losing legitimate leads or customer relationships.
How often should I re-check statuses on an ongoing list?
For an actively growing list, verify new addresses as they’re added through a bulk verifier or API. For older lists that aren’t updated frequently, a full re-verification every few months can help identify mailbox and domain changes that occurred after the original check.
Is there an industry-standard set of email verification status labels?
No strict universal standard exists. Providers use different terminology for similar concepts. Instead of focusing on exact labels, it’s more useful to understand the underlying categories: confirmed good, confirmed bad, and genuinely uncertain.
Can the status breakdown of a list reveal anything about where it came from?
Yes. A high disposable rate may suggest that people are using temporary addresses to avoid follow-up marketing. A high invalid rate particularly on a third-party-sourced list can indicate that many addresses were guessed rather than directly confirmed. Looking at the overall status distribution can therefore reveal useful information about list quality.
