NeverBounce Unknown and Accept All (Unverifiable): What Each Code Means & How to Route It

Q: Is 'Unverifiable' a separate result code in NeverBounce?

No. NeverBounce documents five result codes: valid (0), invalid (1), disposable (2), catchall (3), and unknown (4). 'Accept all (Unverifiable)' is NeverBounce's dashboard and help-center label for catchall (numeric code 3), indicating a domain-wide setting rather than a verdict on the individual mailbox.

Q: What does NeverBounce 'unknown' (code 4) mean, and should I delete those contacts?

NeverBounce defines unknown (code 4) as a check where the receiving mail server did not give a definitive answer in time — with examples in NeverBounce's docs including greylisting, security gateways, or timeouts on single checks. NeverBounce states that unknown is not a negative result and claims in its help guide that re-verifying later typically produces a definitive answer. As an editorial safeguard, hold unknown contacts out of immediate ESP sends and re-verify later rather than deleting CRM records.

Q: Why does NeverBounce suggest allowing catchall and unknown at signup, while cautioning against them on ESP lists?

At a signup form, blocking catchall or unknown can reject legitimate users whose corporate mail server accepts all addresses or whose check hit the recommended ~10-second HTTP client timeout, so NeverBounce's point-of-entry guide suggests allowing valid, catchall, and unknown while blocking invalid and disposable. For campaigns sent through a third-party provider requiring a bounce rate below 4%, NeverBounce's result-codes help page instead advises 'PROCEED WITH CAUTION' on Accept all (Unverifiable) — recommending trusted sources, small segmented sends, bounce monitoring, and re-verifying unknowns before sending.

Q: Does NeverBounce charge credits when I re-verify unknown or duplicate addresses?

On NeverBounce's single-check endpoints, the vendor states every verification performed consumes 1 credit, including duplicate requests and bad-syntax data. Bulk list jobs count unique syntactically valid emails within the same submitted job (not across separate jobs). By contrast, InboxPolicy caches fresh decisions for 72 hours so eligible repeat lookups for the same normalized address and strictness (with force_refresh: false) can cost 0 credits.

Q: How should I filter NeverBounce result codes in Marketo, HubSpot, Zapier, or Apollo?

As an editorial routing pattern, store the raw result string (valid, invalid, disposable, catchall, unknown), documented result flags, and verification timestamp on the CRM record rather than deleting uncertain leads. Suppress invalid and disposable from sends, allow valid into normal sequences, hold NeverBounce unknown in a delayed re-verification queue before sending, and isolate catchall into a review or throttled low-volume segment.

By Aria Pramesi, founder of InboxPolicy · Updated November 9, 2026

NeverBounce returns five result codes — valid (0), invalid (1), disposable (2), catchall (3, labeled Accept all (Unverifiable) in the UI), and unknown (4). Neither catchall nor unknown proves a mailbox is dead or guarantees delivery: NeverBounce's documentation gives different conditional guidance for signup forms versus campaigns sent through bounce-limited ESPs.

Editorial routing summary: Suppress invalid and disposable (avoid). Allow valid (send). Hold NeverBounce unknown in a delayed re-verification queue (retry_later workflow) before bounce-limited ESP sends, and isolate catchall / Accept all (Unverifiable) into review or small, source-vetted batches (send_with_caution) rather than deleting CRM records solely because a check returned 3 or 4.

All 5 NeverBounce result codes (API string vs. dashboard label)

A common confusion in Marketo, HubSpot, and Zapier filters is looking for six categories because the NeverBounce dashboard displays Accept all (Unverifiable). Per NeverBounce's Single Check API reference and Result Codes help guide, Unverifiable is part of the label for code 3 (catchall), not a sixth status.

API string & code	Dashboard label & vendor definition	NeverBounce's documented guidance	Editorial routing
`valid` (`0`)	Valid — NeverBounce defines this as "Verified as real address" (vendor assessment, not an independent guarantee of inbox placement or future acceptance).	Vendor labels it safe to send for list cleaning and suggests allowing at form entry.	send
`invalid` (`1`)	Invalid — NeverBounce defines this as "Verified as not valid" (diagnostic flags on `single-check` can also report syntax or DNS/MX details).	Suggests blocking at form entry; list-cleaning guide says DON'T SEND.	avoid (suppress)
`disposable` (`2`)	Disposable — NeverBounce defines this as "A temporary, disposable address" on a short-lived mail service.	Suggests blocking at form entry; list-cleaning guide says DON'T SEND.	avoid (suppress)
`catchall` (`3`)	Accept all (Unverifiable) — A "domain wide-setting" where the mail server accepts any address; "not a verdict on the individual address."	Form entry: suggests allowing to proceed. ESP (<4% bounce limit): PROCEED WITH CAUTION (trusted sources, small segmented sends, bounce monitoring).	review by default (send_with_caution only on throttled, vetted segments)
`unknown` (`4`)	Unknown — "The mail server didn't give a definitive answer in time" (examples in vendor docs include greylisting, security gateways, or timeouts). Not a negative verdict.	Form entry: suggests allowing (~10s HTTP client timeout -> treat as `unknown`). ESP (<4% bounce limit): re-verify later; treat remaining unknowns like accept-all.	Hold in re-verify queue (retry_later workflow), then review if still unresolved

Why NeverBounce documents different guidance for signup forms vs. bounce-limited ESPs

If you reuse NeverBounce's point-of-entry form rule directly inside an outbound CRM or sequencer workflow, unconfirmed catchall and unknown addresses can enter campaigns sent through bounce-limited providers — whereas applying strict bulk-list rules to a registration form can reject real prospects at signup.

1. Point-of-entry (registration & lead-capture forms)

In Verifying an Email, NeverBounce suggests "allowing valid, catchall (accept all / unverifiable), and unknown emails to proceed" while blocking invalid and disposable. It also recommends an approximately 10-second timeout for your HTTP client, treating a client timeout as unknown (and keeping your standard API key server-side or using NeverBounce's JavaScript widget in browsers). NeverBounce's API returns the result alongside flags and metadata while offering implementation advice — your form code decides what passes. At signup, letting catchall and unknown submit the form avoids turning away a legitimate user whose corporate mail server accepts all addresses or whose check did not finish within the client timeout; you can still confirm mailbox ownership via a double-opt-in link (see routing review and avoid in a signup workflow).

2. Bulk CRM lists & outbound sends via third-party providers

When you send campaigns through a third-party email provider or sequencer that enforces bounce limits (policies and opt-in toggles vary by platform and workflow — for example, HubSpot documents marketing-email suspension criteria while Smartlead's auto-pause is conditional on enabled settings; check your sender's rules), NeverBounce's result-codes documentation gives conditional advice specifically for third-party providers requiring a bounce rate below 4%:

For catchall / Accept all (Unverifiable): NeverBounce states these addresses may be safe on a dedicated server with your own IPs depending on overall list health, but for third-party providers requiring a bounce rate below 4% it advises PROCEED WITH CAUTION — restrict sends to trusted acquisition sources, split into small segmented sends, and monitor bounces closely.
For unknown: Because unknown indicates the check did not get a definitive answer in time rather than confirming a bad mailbox, NeverBounce claims in its help guide that re-verifying later typically yields a definitive answer, and recommends re-verifying before sending through a provider requiring <4% bounces (treating any address that remains unknown with the same source-trust, segmentation, and bounce monitoring as accept-all).

How to filter NeverBounce codes in Marketo, HubSpot, and Zapier without losing CRM context

Deleting every non-valid contact can remove associated CRM history (depending on your CRM's deletion and retention settings) and can discard genuine prospects on catch-all domains. Consider this non-destructive 4-bucket editorial routing pattern instead:

Persist three fields on every contact: store the raw result string (valid, invalid, disposable, catchall, unknown), documented result flags (such as role_account or free_email_host), and last_verified_at.
Route invalid (1) and disposable (2) to a validation-suppression list rather than deleting: Flag them in a custom non-sendable property or outbound exclusion list (kept distinct from recipient opt-out/unsubscribe status, according to how your CRM models marketing eligibility) so historical deals and activity remain intact while preventing sequence enrollment.
Queue NeverBounce unknown (4) for delayed re-verification: Wait before re-checking transient timeouts or deferrals. Watch credit rules here: on NeverBounce's single-check endpoints, the vendor states 1 credit is consumed per verification performed, including duplicates and bad-syntax data, whereas bulk list jobs bill unique syntactically valid emails within the same submitted job (not free repeats across separate jobs). (Note: we use retry_later above as a proposed workflow queue name for NeverBounce unknown; in InboxPolicy's own API table below, rules are evaluated in order where the first match wins — temporary_unavailable with no Rule 1 match returns retry_later at Rule 2, while unknown with no higher-priority Rule 1–3 match such as disposable returns review at Rule 4.)
Segment catchall (3) by acquisition trust: Recent inbound demo requests or contacts with prior two-way human replies can go into a monitored low-volume sequence; cold unvetted catch-alls belong in a manual or secondary review queue unless other signals justify the bounce budget.

When you want the API to return the routing action directly

If you maintain custom Zapier Paths, webhook routers, or AI SDR agents, translating five status codes plus flags into separate form vs. outbound rules in every workflow adds glue code. That is the gap InboxPolicy vs. NeverBounce addresses. For a schema-valid request body, POST /v1/decide runs a local syntax precheck, checks the 72-hour cache unless force_refresh is true, and otherwise evaluates verification signals (including MX/SMTP evidence when supplied by the configured verifier) against one ordered rule list in packages/core/src/policy.ts:17–50 where the first matching rule wins:

Order	Condition (first match wins)	Returned action	Policy note (usual `reason`)
`1`	`status === "invalid"` or `status === "syntax_error"`	avoid	Mailbox is invalid or malformed.
`2`	`status === "temporary_unavailable"`	retry_later	Temporary verification issue. Retry later.
`3`	`signals.disposable === true`	avoid	Disposable email detected.
`4`	`status === "unknown"`	review	Mailbox could not be verified confidently.
`5`	`signals.catch_all === true`	send_with_caution if `strictness === "aggressive"`; else review	Catch-all mailbox detected. (or: Review before sending.)
`6`	`signals.role_account === true` and `strictness === "strict"`	review	Role-based address detected under strict policy.
`7`	`confidence < 70`	send_with_caution	Mailbox verified with moderate confidence.
`8`	Otherwise (remaining `valid` results with `confidence >= 70`)	send	Verified mailbox with acceptable risk.

The API's reason field normally carries this policy note. A verification provider's own note, or the syntax pre-check's note, can appear instead (packages/core/src/provider.ts, packages/core/src/syntax.ts).

Precedence in practice: An unknown result with no higher-priority condition (Rules 1–3) returns review at Rule 4, and a catch_all result with no higher-priority condition (Rules 1–4) returns send_with_caution if strictness is aggressive or review otherwise at Rule 5 — neither reaches Rule 8 (send).
72-hour cache & local syntax precheck: Eligible cache hits for the same normalized address and strictness within 72 hours (force_refresh: false) return from_cache: true at 0 credits, and syntactically invalid email strings in schema-valid /v1/decide requests are caught by a local syntax pre-check before the policy runs, returning status: "syntax_error" and avoid at 0 credits.
Agent-native MCP or keyless HTTP x402: Call via the hosted MCP server (7 tools over Streamable HTTP with an x-api-key from prepaid packs: $5/1k Starter, $19/5k Builder, $79/25k Growth) or keylessly per HTTP request to /v1/decide or /v1/verify via x402 in USDC on Base ($0.01 standard quote per fresh check; $0.008 after 1,000 settled units in the prior rolling 30 days and $0.006 after 10,000 with X-InboxPolicy-Payer).

Sourcing (verified November 9, 2026): NeverBounce result strings, numeric codes, HTTP client timeout recommendations, single vs. bulk billing rules, and point-of-entry vs. <4%-bounce ESP guidance are sourced from NeverBounce Single Check Reference, Verifying an Email, v4 Single API, v4 Jobs API, and NeverBounce Result Codes (omp/vendor-facts.md §2). InboxPolicy behavior and pricing match /docs and /pricing.

Frequently asked questions

Is 'Unverifiable' a separate result code in NeverBounce?

No. NeverBounce documents five result codes: valid (0), invalid (1), disposable (2), catchall (3), and unknown (4). Accept all (Unverifiable) is NeverBounce's dashboard and help-center label for catchall (code 3), indicating a domain-wide mail-server setting rather than a verdict on the individual mailbox.

What does NeverBounce 'unknown' (code 4) mean, and should I delete those contacts?

NeverBounce defines unknown (code 4) as a check where the receiving mail server did not give a definitive answer in time — with examples in NeverBounce's docs including greylisting, security gateways, or timeouts on single checks. NeverBounce states that unknown is not a negative result and claims in its help guide that re-verifying later typically produces a definitive answer. As an editorial safeguard, hold unknown contacts out of immediate ESP sends and re-verify later rather than deleting CRM records.

Why does NeverBounce suggest allowing catchall and unknown at signup, while cautioning against them on ESP lists?

At a signup form, blocking catchall or unknown can reject legitimate users whose corporate mail server accepts all addresses or whose check hit the recommended ~10-second HTTP client timeout, so NeverBounce's point-of-entry guide suggests allowing valid, catchall, and unknown while blocking invalid and disposable. For campaigns sent through a third-party provider requiring a bounce rate below 4%, NeverBounce's result-codes help page instead advises PROCEED WITH CAUTION on Accept all (Unverifiable) — recommending trusted sources, small segmented sends, bounce monitoring, and re-verifying unknowns before sending.

Does NeverBounce charge credits when I re-verify unknown or duplicate addresses?

On NeverBounce's single-check endpoints, the vendor states every verification performed consumes 1 credit, including duplicate requests and bad-syntax data. Bulk list jobs count unique syntactically valid emails within the same submitted job (not across separate jobs). By contrast, InboxPolicy caches fresh decisions for 72 hours so eligible repeat lookups for the same normalized address and strictness (force_refresh: false) can cost 0 credits.

How should I filter NeverBounce result codes in Marketo, HubSpot, Zapier, or Apollo?

As an editorial routing pattern, store the raw result string (valid, invalid, disposable, catchall, unknown), documented result flags, and verification timestamp on the CRM record rather than deleting uncertain leads. Suppress invalid and disposable from sends, allow valid into normal sequences, hold NeverBounce unknown in a delayed re-verification queue before sending, and isolate catchall into a review or throttled low-volume segment.