> ## Documentation Index > Fetch the complete documentation index at: https://gtmapis.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. # Catch-all detection vs recovery > Understand mailbox validation, catch-all domain detection, and opt-in catch-all recovery semantics # Catch-all Detection vs Recovery Catch-all domains create a specific kind of validation uncertainty: the domain can accept mail broadly, but standard SMTP checks cannot prove whether one specific address belongs to a real person. GTMAPIs separates that into three different concepts: | Concept | What it answers | GTMAPIs result semantics | | ------------------- | --------------------------------------------------------------------------------------- | ------------------------------------------------------------- | | Mailbox validation | Can this specific address be validated from syntax, DNS, and SMTP signals? | `valid`, `valid_role_based`, `invalid`, or `unknown` | | Catch-all detection | Does the domain accept arbitrary recipients too broadly to verify the specific mailbox? | `risky` with `is_catchall: true` | | Catch-all recovery | Is this `risky` catch-all address worth sending to anyway? | Additive recovery fields beside the original canonical result | ## What Catch-all Domains Are A catch-all, or accept-all, mail server accepts recipient checks for many or all addresses at the domain, even when those addresses may not correspond to real inboxes. For example, a normal non-catch-all domain may reject an obviously fake recipient: ```text theme={null} RCPT TO: 550 5.1.1 User unknown ``` A catch-all domain may accept that same fake recipient: ```text theme={null} RCPT TO: 250 OK ``` That `250 OK` is useful evidence that the domain accepts recipients broadly. It is not proof that `jane.doe@example.com` is a real mailbox. ## Why Catch-all Detection Returns `risky` SMTP can provide strong signals when a server definitively accepts or rejects a specific recipient. Catch-all behavior changes the meaning of acceptance because the server may return a technically successful response for both real and fake local parts. When GTMAPIs detects catch-all behavior, the validation response stays conservative: ```json theme={null} { "email": "jane.doe@catchall-example.com", "result": "risky", "is_catchall": true, "catchall_confidence": "high", "b2b_outbound_quality": "none", "credits_charged": 0, "charge_reason": "Catch-all domain - cannot verify individual mailbox" } ``` The important distinction is that `risky` means the domain may receive mail, but the specific mailbox remains unverifiable through standard validation. ## Billing Semantics Standard catch-all outcomes are not High-Value Validations. A High-Value Validation costs one credit only when the result is a `valid` personal email that is not role-based, catch-all, invalid, risky, or unknown. Catch-all results are classified as `risky`, so they consume 0 standard validation credits. This keeps standard validation economics aligned with usable certainty: | Result | Why it appears | Standard validation credits | | ------------------ | ---------------------------------------------------------- | --------------------------- | | `valid` | Personal mailbox validated and not catch-all or role-based | 1 | | `valid_role_based` | Generic business inbox | 0 | | `risky` | Catch-all behavior detected | 0 | | `invalid` | Syntax, DNS, or definitive mailbox rejection | 0 | | `unknown` | SMTP was blocked, temporary, timed out, or inconclusive | 0 | ## How Premium Catch-all Recovery Differs Premium Catch-All Recovery is a separate opt-in workflow for addresses that standard validation already marked `risky` with `is_catchall: true`. Recovery does not relabel catch-all addresses as normal `valid` results. It adds recovery-specific fields such as confidence, method, reason, recommended action, and recovery credit consumption beside the original canonical validation result. Recovery may recommend actions such as: | Recovery action | Meaning | | ------------------- | -------------------------------------------------------------------- | | `safe_to_send` | Strong enough recovery signals to send with normal campaign controls | | `send_with_caution` | Potentially usable, but route with reputation care | | `manual_review` | Not enough signal for automation | | `suppress` | Do not send | Those are recovery recommendations, not deterministic proof of mailbox existence. A recovered catch-all address remains a catch-all-derived decision, not the same thing as a standard `valid` mailbox validation. ## What GTMAPIs Does Not Claim GTMAPIs does not claim that catch-all recovery proves mailbox existence deterministically. It also does not claim superior catch-all accuracy, deliverability, or security-gateway recovery without published measurement evidence. The product distinction is narrower and more important: standard validation detects catch-all uncertainty transparently as `risky` and does not charge standard validation credits for it; Premium Catch-All Recovery is a separate opt-in scoring workflow with separate recovery economics. ## Related Docs See where SMTP and catch-all checks fit in the validation flow. Review canonical statuses: `valid`, `valid_role_based`, `risky`, `invalid`, and `unknown`. Understand High-Value Validation credit charging. Learn how opt-in recovery scoring is positioned separately from standard validation.