> ## 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 recovery compared

> How GTMAPIs catch-all recovery compares with common catch-all recovery approaches on method, explainability, calibration, and economics

# Catch-all recovery: how GTMAPIs compares

Catch-all (accept-all) domains accept mail for any address, so a standard SMTP
check cannot confirm whether a specific mailbox exists. GTMAPIs catch-all
recovery scores those risky results with non-intrusive confidence signals and
recommends whether each one is send-worthy, worth manual review, or best
suppressed. For the underlying validation semantics, see
[Catch-all detection vs recovery](/concepts/catch-all-detection-vs-recovery).

This page compares the categories teams usually evaluate for that job. It is a
practical comparison of **method and economics**, not a vendor ranking. Where a
claim would depend on measured accuracy, this page intentionally says nothing —
those comparisons wait on published in-product evidence.

Recovery recommendations do not prove mailbox existence deterministically and do
not convert the canonical validation result to a normal `valid` status.

## Comparison

| Dimension             | GTMAPIs                                                                                                                                          | Enrichment-oriented recovery         | Catch-all recovery service            | Managed verification tier                                  |
| --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------ | ------------------------------------- | ---------------------------------------------------------- |
| **Method**            | Non-intrusive scoring — no SMTP send, no probe to the target mailbox                                                                             | Enrichment or delivery-data oriented | Catch-all and hard-to-verify recovery | Subscription list-cleaning with a catch-all credit tier    |
| **Explainability**    | Per-signal `reason` on every result (API field + `catchall_recovery_reason` CSV column)                                                          | Often verdict-oriented               | Often verdict-oriented                | Often tier-oriented                                        |
| **Calibration**       | Per-tenant — scoring tunes to the customer's own outbound-outcome feedback loop                                                                  | Usually vendor-wide delivery data    | Usually vendor-specific method        | Usually managed-service process                            |
| **Economics**         | Only pay for recovered — send-worthy results consume credits; `manual_review`, `suppress`, `insufficient_signal`, and `provider_error` cost zero | Often per-vendor pricing             | Often per-check pricing               | Often dual-credit subscription (standard + catch-all tier) |
| **Reputation safety** | No mail is sent to the address being scored                                                                                                      | —                                    | —                                     | —                                                          |

## Why method matters

Some recovery tools resolve uncertainty by sending or probing. GTMAPIs is
non-intrusive by design: it never sends mail to the address it is scoring, so the
recovery step itself cannot affect your sending reputation or tip off the
recipient. That is a property of the method, not a tuning option.

## Why explainability matters

When a tool returns a catch-all verdict, your team still has to decide whether to
act on it. GTMAPIs returns a per-signal `reason` with every result — in the API
response and as a `catchall_recovery_reason` column in CSV output — so an operator
can see *why* a result is recommended for send, review, or suppression instead of
trusting a single black-box label.

## Why per-tenant calibration matters

GTMAPIs scoring is calibrated from each customer's own outbound-outcome feedback
loop, so it adapts to the domains and patterns *you* actually send to, rather than
a vendor's generic pool. Accuracy compounds with your own sending volume. The
calibrated accuracy bands are published in-product from your feedback data as it
accumulates.

## Why "only pay for recovered" matters

GTMAPIs charges credits for send-worthy results only. Outcomes that are not
send-worthy — `manual_review`, `suppress`, `insufficient_signal`, `provider_error`
— cost zero. The unit that matters is **cost per recovered lead**, not cost per
check including the unknowns. That is a different economic shape from per-check
pricing or a subscription that pre-pays for a catch-all tier whether or not the
volume materializes.

## Compliance posture

GTMAPIs operates a documented controller/processor model with transparent data
handling. Recovery runs on the same compliance footing as the rest of the
platform — no separate opaque pipeline.

## What this page does not claim

This comparison deliberately makes **no claim** of superior accuracy, lower
failure rate, or better security-gateway (SEG) recovery than any vendor named
here. Those are measured comparisons, and they wait on the accuracy evidence
published in-product from live feedback. The edges above — non-intrusive method,
per-signal explainability, per-tenant calibration, outcome-based economics, and
compliance posture — are properties of how the product works today.

## Related

* [Catch-all recovery in a Clay waterfall](/guides/integrations/clay-catch-all-recovery)
* [Catch-all recovery in n8n](/guides/integrations/n8n-catch-all-recovery)