ZeroBounce catch-all, accept_all, and do_not_mail: HubSpot & Clay Routing Guide
By Aria Pramesi, founder of InboxPolicy · Updated November 9, 2026
Filtering ZeroBounce exports on status == "valid" alone misses two schema distinctions: ZeroBounce returns accept_all (and role_based_accept_all) as a sub-status inside valid while using standalone catch-all for catch-all domains not on its allow-list, and its do_not_mail status groups role_based position/group addresses alongside toxic, disposable, and possible_trap classifications.
Editorial routing summary: Branch on both status and sub_status. Suppress invalid (except temporary mailbox_quota_exceeded), spamtrap, abuse, and five of the seven do_not_mail sub-statuses (avoid). Hold standalone catch-all in review, throttle valid / accept_all and do_not_mail / role_based (send_with_caution), and re-validate unknown after a backoff window (retry_later).
1. Why catch-all and accept_all are NOT the same field in ZeroBounce
ZeroBounce's API v2 Status Codes reference and Validate Emails reference document seven top-level statuses — valid, invalid, catch-all (hyphenated), spamtrap, abuse, do_not_mail, and unknown — paired with a separate sub_status string (not every invalid or unknown result includes a sub-status).
Catch-all behavior appears in three distinct places across that schema:
- Top-level
status: "catch-all": ZeroBounce describes this as a catch-all domain not in its allow-list where it cannot confirm the individual mailbox over ordinary SMTP, stating actual deliverability "cannot be confirmed" and recommending segmentation if you choose to send (ai_agent_mailboxcan also appear as a sub-status here). status: "valid"+sub_status: "accept_all"(or"role_based_accept_all"): ZeroBounce documentsaccept_allas a sub-status undervalidfor domains on ZeroBounce's vetted accept-all list ("Domain vetted by ZeroBounce, historically delivers, returned as valid"; othervalidsub-statuses includealias_address,leading_period_removed,alternate,gold, andai_agent_mailbox). Treat historical delivery as ZeroBounce's vendor claim rather than independent proof of a particular mailbox: for example, if a contact recently left a company, an accept-all gateway may still accept the SMTP recipient even though the intended person is gone.status: "do_not_mail"+sub_status: "role_based_catch_all": A role-based address (such asinfo@orsupport@) on a catch-all domain — combining a group/position prefix with unconfirmed mailbox existence.
2. All 7 ZeroBounce do_not_mail sub-statuses — and how to split them
ZeroBounce advises examining do_not_mail sub-statuses rather than assuming every flagged address is nonexistent. Below are all seven documented sub-statuses and our editorial outbound routing recommendation for each:
do_not_mail sub-status | What ZeroBounce documents | Editorial routing recommendation |
|---|---|---|
role_based |
Position or group mailbox (such as sales@ or support@; ZeroBounce notes these are valid position addresses and leaves risk assessment to your use case — see role-based email routing). |
send_with_caution (or review under strict cold-outreach policy) |
role_based_catch_all |
Role-based address on a catch-all domain (distinct from role_based_accept_all under valid). |
review (hold out of cold blasts) |
disposable |
Temporary throwaway address; ZeroBounce recommends avoiding list additions. | avoid (suppress) |
toxic |
Associated with abuse, spam, or potential bot creation; ZeroBounce advises not emailing. | avoid (suppress) |
global_suppression |
Matched against global suppression lists (examples include known complainers and purchased addresses; live validation may be skipped due to risk). | avoid (suppress) |
mx_forward |
Domain configured to forward MX records into another domain, which ZeroBounce compares to disposable domain patterns. | avoid (or manual review for known SMB aliases) |
possible_trap |
Contains keywords that might correlate with spam traps (distinct from the top-level spamtrap classification, which ZeroBounce defines as addresses it believes are spam traps); ZeroBounce recommends examining before sending. |
avoid on cold lists |
3. Top-level statuses & transient edge cases (unknown and mailbox_quota_exceeded)
spamtrapandabuse(top-level): ZeroBounce advises against emailing both; as an outbound policy recommendation, suppress them (avoid). ZeroBounce offers top-levelspamtrap(addresses ZeroBounce believes are spam traps, noting in its docs that it knows many, though not all, trap addresses) andabuseclassifications. Per InboxPolicy's pricing page, ZeroBounce maintains a dedicated spam-trap and abuse database that InboxPolicy does not offer (and /docs separately notes primary unknown verdicts may escalate to a wholesale fallback verifier; see InboxPolicy vs. ZeroBounce).invalid(top-level): Documented sub-statuses includedoes_not_accept_mail,failed_syntax_check,possible_typo,mailbox_not_found,no_dns_entries,unroutable_ip_address, andmailbox_quota_exceeded(not every invalid result carries a sub-status). Suppress the first six (avoid), except prompt users to fixpossible_typoon signup forms; ZeroBounce describesmailbox_quota_exceededas temporarily unable to accept mail (retry_later).unknown(top-level): ZeroBounce states unknown results are not charged and credits will be credited back. Documented sub-statuses areantispam_system,exception_occurred,failed_smtp_connection,Forcible_disconnect,greylisted,mail_server_did_not_respond,mail_server_temporary_error, andtimeout_exceeded(not all unknowns carry a sub-status). ZeroBounce recommends re-validating if you see a large number of unknowns; as an editorial recommendation, wait for a retry backoff window (retry_later) before re-checking rather than deleting them.
4. Routing ZeroBounce statuses in HubSpot (Integration exports vs. V4 Forms)
Two documented distinctions matter when wiring ZeroBounce into HubSpot:
- Integration exports write properties — ZeroBounce's docs do not establish automatic campaign suppression: Per ZeroBounce's HubSpot integration documentation, validation and scoring results are exported to the originating HubSpot integration as
ZB_Status,ZB_SubStatus, timestamps, score, and last-known activity tags. Because that documentation establishes property export rather than automatic campaign suppression, one practical safeguard is building active HubSpot exclusion lists fromZB_StatusandZB_SubStatusand applying those exclusion lists directly to each marketing email send. - Separate V4 Form rules from outbound sends — and distinguish replies from delivery/open events: ZeroBounce's HubSpot V4 embedded forms integration includes a configurable "Email will pass on status" setting that recommends
Valid,Catch-All, andUnknown(alongside optional controls such as free-email blocking) — a form-entry rule, not an outbound bulk-send rule. Similarly, when reviewing CRM engagement onZB_Status = catch-allcontacts, distinguish event types carefully: a genuine two-way human reply is stronger historical evidence of human access (though still bounded by forwarding, shared mailboxes, and turnover, and never proof of marketing consent), whereas a delivery event only reflects SMTP acceptance (a catch-all server can accept recipients and later quarantine, route elsewhere, or drop mail) and a scanner open only shows a tracking resource was requested.
5. Routing ZeroBounce statuses in Clay tables
In Clay (ZeroBounce Clay guide and Clay's ZeroBounce integration overview), ZeroBounce notes that running validation creates a results column and users choose whether to expose status and sub_status as selected appended-data columns, while Clay documents a Safe to Send option:
- Clay's ZeroBounce integration overview states that catch-all is marked valid with a catch-all sub-status by default — wording that differs from ZeroBounce's native API taxonomy — while Clay's email waterfall lesson describes its "Only mark 'Safe to Send' emails as valid" toggle differently.
- Because the documentation describes these behaviors differently, verify your specific Clay workflow, select both
statusandsub_statusas appended columns, and configure an explicit user-defined Only run if condition on Clay's table-based campaign sync column (Clay Sequencer docs) before syncing rows.
When to use ZeroBounce vs. InboxPolicy (including MCP & x402)
Both providers offer official MCP servers for AI agents: ZeroBounce publishes the ZeroBounce MCP server (using a ZeroBounce API key and account credits, including eligible free monthly credits advertised on ZeroBounce's pricing page) for single/batch validation and bulk CSV operations, and offers spamtrap and abuse classifications.
InboxPolicy is designed for workflows where you want to verify an email address and receive one of five send actions (send, send_with_caution, review, retry_later, avoid) directly — note that InboxPolicy verifies the email address itself rather than ingesting exported ZeroBounce status/sub_status fields. In packages/core/src/policy.ts:17–50, the returned action comes from one ordered rule list 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).
- API-key REST & 7-tool MCP server: Authenticate with
x-api-keyagainstPOST /v1/decideor InboxPolicy's hosted MCP server over Streamable HTTP (exposing seven tools:decide_send,verify_email,estimate_credits,create_verify_batch,get_batch_status,get_batch_items, andget_usage; MCP requires an API key in both remote and stdio modes), backed by non-expiring credit packs ($5 Starter for 1,000 credits, $19 Builder for 5,000, $79 Growth for 25,000). - Keyless HTTP x402 & 72-hour cache: Direct HTTP calls to
/v1/decide,/v1/verify, and/v1/batches/verifyalso accept keyless x402 payments in USDC on Base ($0.01 standard single-call quote; wallet-bound rolling 30-day discounts of 20% — $0.008 on a $0.01 single call — after 1,000 settled units and 40% — $0.006 — after 10,000 viaX-InboxPolicy-Payer, with the earned percentage also applied to the current batch base quote). Eligible cache hits for the same normalized address and strictness within 72 hours (whenforce_refreshisfalse) can cost 0 credits.
Sourcing (verified November 9, 2026): ZeroBounce status/sub-status definitions, credit rules, MCP server tools, and HubSpot/Clay integration docs are sourced from ZeroBounce v2 Status Codes, v2 Validate Emails, HubSpot Integration, HubSpot Forms Integration, Clay Integration, ZeroBounce MCP Server, and Clay University (omp/vendor-facts.md §3). InboxPolicy specs match /docs and /pricing.
Frequently asked questions
Are 'catch-all' and 'accept_all' the same status in the ZeroBounce API?
No. In ZeroBounce's API v2, catch-all (with a hyphen) is a top-level status for a catch-all domain not on ZeroBounce's allow-list, where ZeroBounce states actual deliverability cannot be confirmed. By contrast, accept_all (with an underscore) is a sub_status under top-level status: "valid" for domains on ZeroBounce's vetted accept-all list (which ZeroBounce claims historically deliver). Filter on both status and sub_status so valid / accept_all rows are segmented intentionally.
What are all 7 sub-statuses under ZeroBounce 'do_not_mail'?
ZeroBounce's API v2 documents seven do_not_mail sub-statuses: disposable, toxic, role_based, role_based_catch_all, global_suppression, mx_forward, and possible_trap (traits correlated with spam traps, distinct from the top-level spamtrap classification). As an outbound policy recommendation, suppress disposable, toxic, global_suppression, mx_forward, and possible_trap from cold outreach, and evaluate role_based and role_based_catch_all according to whether your workflow targets shared team inboxes.
Does ZeroBounce's HubSpot integration suppress catch-all or do_not_mail contacts automatically?
ZeroBounce's HubSpot integration exports ZB_Status and ZB_SubStatus (plus timestamps, score, and last-known activity tags) to the originating HubSpot integration; ZeroBounce's documentation does not establish automatic campaign suppression. One practical safeguard is creating active HubSpot exclusion lists from ZB_Status and ZB_SubStatus and applying those exclusion lists directly to your marketing email sends. Separately, ZeroBounce's HubSpot V4 embedded forms integration recommends passing Valid, Catch-All, and Unknown at form submission — a form-entry rule, not an outbound bulk-send rule.
How does Clay map ZeroBounce catch-all results and the Safe to Send toggle?
In Clay, ZeroBounce's guide notes a results column is created and users choose whether to expose status and sub_status as selected appended-data columns, while Clay's ZeroBounce integration overview documents a Safe to Send option and states catch-all is marked valid with a catch-all sub-status by default (differing from ZeroBounce's native API taxonomy and from how Clay's waterfall lesson describes "Only mark 'Safe to Send' emails as valid"). Because the documentation describes these behaviors differently, verify your specific Clay workflow and configure an explicit Only run if condition on Clay's table-based campaign sync column.
Can prior HubSpot email activity prove a ZeroBounce catch-all contact is safe to email?
Use caution. A genuine two-way human reply is stronger historical evidence of human mailbox access than delivery or open events, though forwarding, shared mailboxes, and job turnover still limit what it proves (and it does not establish current control or marketing consent). By contrast, a delivery event only reflects SMTP acceptance, and a security-scanner open indicates a tracking resource was requested — not necessarily by the intended recipient.