Catch-all verification

A catch-all domain accepts mail for any address, including addresses that do not correspond to real people. Traditional email verification can tell you that the domain accepts mail, but that does not always prove the specific person exists behind the mailbox.

Relentless Identity approaches catch-all verification differently. Instead of stopping at "this domain accepts mail," it correlates identity and routing evidence to determine whether the target work identity appears real.

Why catch-all domains are hard

Catch-all behavior defeats most SMTP-based verification techniques. When a server accepts mail for every address, a standard probe cannot distinguish real mailboxes from empty ones. That means:

• Deliverability checks become ambiguous. The server says "yes" to everything.
• Pattern matching produces false confidence. A guessed address may look plausible but not belong to a real person.
• Scoring models rely on heuristics. Accept-all detection tells you the domain accepts mail, but not whether the specific identity is valid.

For teams that cannot afford to treat catch-all results as a generic risk bucket, a different approach is needed.

How Relentless Identity handles catch-all verification

Relentless Identity does not rely solely on SMTP probing to classify catch-all domains. The verification model combines multiple signals:

Identity-provider discovery

When a company uses Microsoft Entra ID, Okta, Google Workspace, or another identity provider, Relentless Identity can detect and surface that provider context. If the provider confirms the identity exists, the result carries stronger confidence than an SMTP-only check.

Multi-domain discovery

Many organizations operate across multiple domains — regional domains, acquired brands, product-line domains, or identity-provider-managed tenants. Relentless Identity's Finder workflow discovers related email domains and verifies the identity across them, rather than assuming the public website domain is the mailbox domain.

Alias resolution

A catch-all domain may accept mail for aliases that do not correspond to primary mailboxes. Relentless Identity detects and resolves aliases to the underlying work identity, reducing false positives from generic or forwarded addresses.

MX-host and routing context

Relentless Identity returns mx_hosts and identity-provider context when available, giving your application additional evidence to classify the result. This is especially useful when the mailbox routes through a gateway or third-party provider.

Using catch-all verification with the API

Finder workflow

When you do not know the exact email address, use Finder. Finder accepts a person's full name and company domain, then performs domain discovery and identity verification across related infrastructure.

POST /client/attempt
{
  "full_name": "Jane Doe",
  "company_domain": "example.com"
}

Finder returns the same response shape as Probe: state, outcome, and address. When the identity is verified, the address field contains the resolved email. Additional context may include identity_providers and mx_hosts.

Probe workflow

When you already know the email address, use Probe. Probe verifies whether that specific work identity appears valid, even on catch-all domains.

POST /client/probe
{
  "email": "jane.doe@example.com"
}

Probe returns a compact deliverability verdict with the same top-level shape. The state field indicates deliverable or undeliverable.

Interpreting catch-all results

Relentless Identity's accuracy notes recommend treating deliverable as the strongest positive signal. When a result returns deliverable on a catch-all domain, the verification has correlated identity evidence beyond SMTP probing.

Key rules:

1. Store the returned address when Finder resolves a verified result. This is the canonical work identity.
2. Treat deliverable as production-ready. The identity has been verified against live provider and mailbox signals.
3. Treat undeliverable as a suppress signal. The identity does not appear to exist behind this address.
4. Use mx_hosts and identity_providers for additional classification when your workflow requires it.

When catch-all verification matters

Catch-all verification is most valuable when:

• Sales teams need the right person, not just an address that accepts mail.
• Fraud teams need identity confidence, not just syntactic validity.
• Underwriting teams need cleaner identity signals before approving accounts.
• SaaS teams need to distinguish valid users from generic catch-all responses.
• Recruiting and enrichment workflows need fewer false positives.
• Data pipelines need to resolve identities across multi-domain organizations.

For a broader comparison of how catch-all verification differs across tools, see the blog posts on BounceBan, Hunter, and ZeroBounce.