TL;DR
- Scope: the verified email status meaning covered here is the label a verifier or finder puts on a prospect's address, not a sign-up confirmation email.
- What a status is: one tool's word for what a mail server said about one address at one moment. Every label falls into one of five families.
- Where names clash: ZeroBounce returns
accept_allas valid andcatch-allas no verdict. Kickbox, Bouncer and Emailable put accept-all inside risky. LeadMagic folds it into unknown. - What you pay for: nine of the 12 vendor pages say an unknown result is free or refunded. DeBounce's and NeverBounce's pages state no exception, and catch-all billing splits.
- What to do: send valid, suppress invalid, split catch-all and risky by reason, retry unknown, and put any address two tools disagree on in a small last batch.
A verified email status is one tool's label for what a mail server said about one address at one check. Valid and invalid are verdicts. Catch-all, unknown and risky say why the tool has no verdict. Across 12 tools we found five families of label and three actions: send, suppress or re-check. In our 1,000-address test, 212 addresses sat on catch-all domains by WizLeads' count.
Search for this phrase and you meet two crowds. One wants to know whether a sign-up email went through. You are the other: you hold a list or an Apollo export, and the labels differ from tool to tool.
This guide maps the labels at ZeroBounce, NeverBounce, MillionVerifier, DeBounce, Bouncer, Emailable, Kickbox, Hunter, Clearout, LeadMagic, Reoon and Apollo, each from that vendor's own pages. We cover what each means, which you pay for and what to do with each.
What "verified" means, and how long it lasts
A verified status describes one moment. MillionVerifier's results page says an invalid verdict means a hard bounce "at the time of the verification". The address may have existed before or later. Clearout's docs put a number on it: its Yes in Safe to Send holds if you send within 24 hours of the check. Hunter's help centre says a domain can shift from Valid to Accept-all or Invalid as mail servers change. It advises re-verifying before large sends.
Of those three, only Clearout gives a window. Verify close to the send, and re-verify any list that sat in a CRM for a quarter.
Apollo's Verified is a different kind of label. It is Apollo's own confirmation, and its email status overview lists six statuses: Verified, Unverified, Update required, Unavailable, User-managed and Catch-all. A verified email costs 1 credit, and Apollo refunds it if the address bounces within 30 days of purchase. Its article on how it verifies emails says many third-party tools "flag valid, Apollo-verified emails as unverifiable" because they sit on catch-all domains. The same article claims Apollo's process can tell valid from invalid on those domains, and it shows no data for the claim. So an Apollo Verified and a verifier's catch-all can describe the same address.
Email verification results meaning: five families
Strip away the vendor names and every email verification status falls into one of five families. Only the first two are verdicts.
| Family | What the server did | Typical labels | What to do |
|---|---|---|---|
| Confirmed | Accepted this recipient | valid, ok, safe, deliverable | Send soon. Re-verify old lists first. |
| Absent | Rejected the recipient, or the domain or syntax is broken | invalid, undeliverable, disabled, syntax | Suppress, and keep it suppressed across re-imports. |
| Domain accepts everything | Accepts every recipient, so a yes carries no information | catch-all, accept-all, accept_all | Resolve it, or send to it as a small segment and watch bounces. |
| No answer | Timed out, deferred or blocked the check | unknown, greylisted | Retry later. Drop it if it stays unknown. |
| Exists, but a poor bet | May accept mail, but the address is disposable, a trap, a role inbox or a complainer | risky, do_not_mail, spamtrap, abuse, disposable, role | Split by reason. Delete traps and complainers. |
The last three rows explain why a verdict is missing, and the vendors name them differently.
The 12-tool decoder: one status, twelve vocabularies
Each row comes from that vendor's own documentation.
| Tool | Good | Bad | Domain accepts everything | No answer | Other labels |
|---|---|---|---|---|---|
| ZeroBounce | valid | invalid | catch-all (accept_all is a valid sub-status) | unknown | spamtrap, abuse, do_not_mail |
| NeverBounce | Valid (0) | Invalid (1) | Accept all (Unverifiable) (3) | Unknown (4) | Disposable (2) |
| MillionVerifier | ok | invalid | catch_all | unknown | disposable |
| DeBounce | Deliverable (5) | Invalid (6), Syntax (1) | Accept-All (4) | Unknown (7) | Spam Trap (2), Disposable (3), Role (8) |
| Bouncer | deliverable | undeliverable | risky, reason low_deliverability | unknown | risky, reason low_quality |
| Emailable | Deliverable | Undeliverable | Risky, with an Accept-All attribute | Unknown | Duplicate |
| Kickbox | deliverable | undeliverable | risky (Accept All) | unknown | risky also covers Disposable and Role |
| Hunter | valid | invalid | accept_all | unknown | disposable, webmail |
| Clearout | Valid | Invalid | Catch All | Unknown | a separate Safe to Send field |
| LeadMagic | valid | invalid | none, folded into unknown | unknown | none |
| Reoon (Power mode) | safe | invalid, disabled | catch_all | unknown | disposable, inbox_full, role_account, spamtrap |
| Apollo | Verified | none (Unavailable means no email found or verified) | Catch-all | Unverified | Update required, User-managed |
The pages behind the rows: ZeroBounce's status codes, NeverBounce's result codes, MillionVerifier's results help page, DeBounce's result-code page, Bouncer's terminology docs, Emailable's states page, Kickbox's terminology docs, Hunter's API docs, Clearout's verifier overview, LeadMagic's validation reference, Reoon's API docs and Apollo's status overview.
Most tools return a status and a reason. ZeroBounce's status codes page pairs each status with sub-statuses such as greylisted or mailbox_quota_exceeded. Kickbox, Bouncer and Emailable pair a result with a reason code, and Clearout adds a Safe to Send value of Yes, Risky, No or Unknown. Map on the pair. A Bouncer risky with reason low_deliverability is in most cases a catch-all or a full mailbox. With reason low_quality it is in most cases a disposable address. You would handle the two differently.
Two vendors number their results. NeverBounce's result codes run from 0 to 4 and DeBounce's from 1 to 8. Check whether an export holds the label or the number.
Some vendors disagree with themselves. Hunter's API docs list six status values, including webmail and disposable. Its FAQ lists five statuses, and a help article names a Blocked status that the API treats as a separate block flag. DeBounce documents a Role code 8, then says it will not show up in the API response, so you read a separate role parameter. Reoon's docs say that in Quick mode every address on a good domain, nonexistent ones included, is marked valid. Power mode returns safe. A Reoon valid from Quick mode is a domain check, not a mailbox check.
WizLeads statuses, outside the table
WizLeads is not one of the 12 tools. Its email verifier returns a status of valid, invalid, unknown or error. A separate catchall flag reads YES, NO or UNKNOWN, according to the WizLeads API reference. The same reference says Verify Email also performs catch-all validation. It charges 0.5 credits for every email processed, whatever the result, so an unknown costs the same as a valid.
Accept-all, catch-all, risky: one idea, many names
A catch-all domain accepts mail for any local part, so the check says yes to everything. Hunter's help centre says the domain "has a policy to report any email on the domain as valid". Vendors then handle it in three ways.
- Its own label. ZeroBounce, NeverBounce, MillionVerifier, DeBounce, Hunter, Clearout, Reoon and Apollo return a catch-all or accept-all status. NeverBounce calls it a server setting, not a verdict on the address, and, for senders whose provider requires a bounce rate below 4%, says to send to these addresses selectively rather than exclude them.
- Inside risky. Kickbox, Bouncer and Emailable return risky with an accept-all reason or attribute. Emailable adds that it may sometimes return Deliverable or Undeliverable for an accept-all address.
- Inside unknown. LeadMagic's docs say that when it cannot verify the mailbox, the result is unknown, and "There is no separate catch-all status or flag".
The labels also change with the mode you pick. Clearout says Deep Verify mode classifies catch-all and unknown results as valid or invalid. MillionVerifier runs a catch-all verifier and still returns catch-all when an address stays uncertain. ZeroBounce describes its Verify+ step two ways. Its Verify+ page says it sends an email to check for bounces, at no additional cost. Its catch-all validation page says the step applies deeper models and additional signals. It takes up to 12 hours and runs only when a list has at least 10 catch-alls.
ZeroBounce also uses two words for two outcomes. Its accept_all sub-status sits under valid, for domains ZeroBounce has vetted. Its catch-all status means deliverability cannot be confirmed. Filter an export on the string "accept" and you pull valid addresses into your risky segment.
This matters on B2B lists. In our test of 1,000 real-estate decision-maker emails from Apollo, WizLeads' classifier put 212 (21.2%) on catch-all domains. Our catch-all verification guide covers which tools resolve them and what that costs. The decision here is shorter. A catch-all label means no verdict, so resolve it or send to it as a small segment.
Unknown: the server never answered
Unknown means the check got no usable reply. ZeroBounce's unknown sub-statuses list the usual reasons, among them greylisted, antispam_system, timeout_exceeded and forcible_disconnect. NeverBounce names greylisting and security gateways.
Two large vendors read the same status in opposite directions. NeverBounce says unknown is "not a negative result". ZeroBounce says "In most cases, 80% of unknowns are invalid/bad email addresses", and shows no data for that figure. Both pages support the same action. An unknown is unresolved, and a second try sometimes settles it.
Retry advice is specific where it exists. Kickbox's docs say that retrying after about 5 minutes will sometimes return valid or invalid. DeBounce already retries for you: it checks an unknown address up to 3 times before it returns the label.
Risky email meaning: a bucket, not a verdict
Risky has the least consistent definition of any label here. Kickbox says Accept All, Disposable and Role addresses are classified as Risky. Bouncer's terminology docs list Accept All, Full Mailbox or Disposable, while its FAQ lists only Accept All and Disposable. MillionVerifier uses Risky as a group name for catch-all and unknown.
A full mailbox shows the split. ZeroBounce files it as invalid (mailbox_quota_exceeded, described as temporary). Bouncer's docs file it under risky.
A risky address can be a real inbox on a catch-all domain, a full mailbox, a throwaway or info@. Split the bucket by reason first.
ZeroBounce avoids the word and sorts the same ground into sharper statuses. Its spamtrap status is for addresses it believes are traps, and it says not to email them. Its abuse status is for people known to report mail as spam. Its do_not_mail status has seven sub-categories, among them disposable, role_based and possible_trap.
Which statuses you pay for
Two tools can return the same status and bill it differently. The rule usually sits on a pricing page, an FAQ or a help article. The table gives what each vendor's own page says, with no prices.
| Tool | What its page says about billing |
|---|---|
| ZeroBounce | One credit per email. Unknown and duplicates are not charged. |
| NeverBounce | 1 credit is 1 email verification. The page states no exception. |
| MillionVerifier | Help page: no charge for catch-all and unknown. Terms: the credit is deducted, then added back as a promotional credit where the programme is available. |
| DeBounce | 1 credit is 1 verification. Optional catch-all validation adds 10 credits per email. |
| Bouncer | Pricing page and FAQ status list: unknown and duplicates are not charged. FAQ billing answer: "No, unless you will first send us an email". |
| Emailable | One credit per request. Unknown and duplicates are refunded when the list finishes. |
| Kickbox | Unknown does not count against your balance. The pricing page says the credit is refunded. |
| Hunter | 0.5 credit per verified email. None for unknown. |
| Clearout | 1 credit for valid, invalid and catch-all. Unknown is not charged. |
| LeadMagic | 0.25 credit for valid or invalid. Unknown is free, including accept-all it cannot verify. |
| Reoon | One credit for any result except unknown. Unknown is refunded. |
| Apollo | Verified: 1 credit, refunded if it bounces within 30 days. A catch-all Apollo verifies: 1 credit. Unavailable: none. User-managed: none unless you verify or enrich it. Verifying an amended Unverified email: 1 credit. |
The rules come from ZeroBounce's pricing FAQ, NeverBounce's billing help, MillionVerifier's results help and Terms, DeBounce's credit and catch-all help, Bouncer's pricing page and FAQ, Emailable's pricing page, Kickbox's terminology and pricing pages, Hunter's status help, Clearout's pricing guide, LeadMagic's validation docs, Reoon's verifier page and Apollo's status overview.
ZeroBounce's pricing FAQ says it will never charge for unknown results, and it names exactly two no-charge cases, unknown and duplicates. Nine of the 12 vendor pages say an unknown result is free or refunded: ZeroBounce, MillionVerifier, Bouncer, Emailable, Kickbox, Hunter, Clearout, LeadMagic and Reoon. DeBounce's and NeverBounce's pages state no exception for verification. DeBounce waives unknowns only in its lead finder. Apollo has no unknown status, and its Unavailable status costs nothing.
Two vendors contradict themselves. MillionVerifier's help page says it does not charge for catch-all and unknown. Its goodwill-credits page says it deducts one credit per email, then adds credits back for those results. Its Terms call the credit-back a promotional programme "where the programme is currently available". Bouncer's pricing page and the status list in its FAQ say unknowns are never charged, while the FAQ's billing answer adds a condition: "No, unless you will first send us an email".
Catch-all billing splits. Most pages exempt only unknowns, so a catch-all costs a credit like a valid one. Clearout and Apollo say so outright. MillionVerifier's help page and LeadMagic's docs do not bill it. Resolving one costs extra at two vendors. DeBounce's optional catch-all validation adds 10 credits per email. Clearout's verifier docs say Deep Verify takes 5 credits when it resolves an address and 1 when it stays risky. On a list where one address in five is catch-all, that split decides how much you pay for a non-answer.
One real list, label by label
To see how labels spread on real data, take our benchmark: 1,000 Apollo-sourced real-estate addresses run through six verifiers in April 2026. We mailed only the addresses at least one tool approved; the 96 that every tool rejected were never sent. So the counts below are rejection counts, not error counts. The full benchmark has bounce rates for each tool's approved list.
| Tool (fewest rejections first) | Rejected of 1,000 | Label on part of those rejections |
|---|---|---|
| ZeroBounce | 112 | no label count used here |
| WizLeads | 148 | no label count used here |
| LeadMagic | 178 | no label count used here |
| NeverBounce | 289 | 137 "catchall" and 79 "unknown" |
| MillionVerifier | 291 | 170 "catch_all" |
| DeBounce | 330 | 201 "Accept All" |
The label counts sit inside each tool's rejections, so they never add on top. DeBounce's 201 come from its standard check only, with the catch-all check not run. The same 1,000 addresses drew between 112 and 330 rejections, and how a tool treats the no-verdict statuses moves that count a long way.
In the same list, 159 addresses (15.9%) sat behind a Secure Email Gateway, by WizLeads' own classifier. Gateways can cause an unknown, but we did not measure how many of NeverBounce's 79 sat behind one.
What to do when two tools disagree
In an r/EmailProspecting thread titled "Two email verifiers disagree. What do you actually do next?", the commenters mostly treat a split as a risk tier. The poster says they work on email verification, so read the replies as operators' habits, not data.
The routine they describe has three tiers. Addresses that both tools call valid make up the main batch. A split result, where one tool says valid and the other says risky, waits in a small batch. That batch goes last, from a single inbox, and the inbox stops if bounces pass about 2%. An unknown gets another try after a few days, and one that stays unknown is dropped. The commenters say most splits come from catch-all domains or domains behind strict gateways.
That routine fits the five families. Map every tool's output into them, and keep three fields per contact: the family, the raw status with its reason, and the verification date. The date tells you when to re-verify. The raw status lets you tell a ZeroBounce accept_all from a catch-all later. Send the confirmed family first and suppress the absent one. Give the catch-all and risky families their own segment. Keep unknowns in a retry queue with a counter, not on a suppression list.
FAQ
What does it mean when an email is unverified?
It means the tool has no verdict yet. At Apollo, Unverified is an email Apollo could not verify or has low confidence in, and it also covers emails you uploaded or edited. At a verifier, the closest label is unknown: the mail server gave no usable answer at the time. NeverBounce says unknown is not a negative result and that re-verifying later typically returns a definitive one. Retry first, then decide.
What does an email verifier do?
An email verifier checks an address against the recipient's mail server and returns a status label. Valid and invalid are verdicts. Catch-all, unknown and risky say why the tool has no verdict. Most tools add a reason code, and each vendor bills some statuses differently, so map the status and the reason together before you send.