Catch-all is uncertain. We say so.

Catch-all detection is the clearest example of a broader principle behind Bounceless: when a signal is genuinely uncertain, we say so instead of forcing it into a clean valid or invalid label.

Why catch-all breaks the usual check

Standard email verification leans on the SMTP conversation with a domain’s mail server: ask whether a specific mailbox exists, and get back an accept or a reject. A catch-all domain is configured to accept mail for any local part at that domain, real mailbox or not. The handshake that normally separates jane@company.com from zzzz-typo@company.com returns the same “accepted” response for both, because the server was never asked to distinguish them in the first place.

That is not a bug in the verification engine. It is a property of how the receiving server is set up, and no amount of retrying the same check changes the answer.

What we do instead of guessing

When a domain answers as catch-all, Bounceless does not fall back to a coin flip dressed up as a result. The address is marked with reduced confidence and a dedicated reason code, so it is visibly different from a domain that gave a definitive accept or reject. Two categories:

• Confirmed deliverable. The mail server distinguished a real mailbox from an invalid one. Confidence is high because the signal itself is direct.
• Catch-all domain. The mail server accepts everything. Confidence is capped, and the reason code explains why: not “unknown,” but specifically “this domain’s configuration prevents a direct check.”

Honest uncertainty, not a hidden penalty

Catch-all is common on legitimate setups: small businesses on shared hosting, custom domains with permissive mail routing, and plenty of real B2B contacts who never see the difference in their day-to-day inbox. Treating every catch-all result as automatically bad would punish real prospects; treating it as automatically good would hide genuine risk. Bounceless does neither: the result feeds into your Pre-Send Decision as a review signal, with the reasoning attached, so a human or a policy rule makes the call with full context instead of a rounded-up label.

Where this shows up in your workflow

Catch-all results come back through the same upload or API call as every other verification, tagged with their own reason code and confidence band. Nothing about the integration changes. What changes is that a catch-all contact reads honestly as “review before you rely on this,” instead of quietly inflating a valid count that was never fully earned.

This is also why comparing raw “percent valid” numbers across verification providers can mislead: a provider that folds catch-all into valid will always report a higher score than one that flags it. The higher number is not more accurate, just less honest about what it does not know.