Verification that explains itself

The problem with a single valid/invalid label

Most verification tools collapse everything they observe about an address into one word: valid or invalid. That label hides the difference between a mailbox that clearly exists, a catch-all domain that accepts anything, and a role address like support@ that technically works but behaves differently in a campaign. Treating all three the same way is how clean-looking lists still produce bounces, spam complaints, and skewed engagement metrics.

Email Verification is built around a different unit of output: a confidence level plus the reason codes that produced it, rolled up into a Pre-Send Decision your team or your policy engine can act on.

How verification works

1. Syntax and format. The address is checked against RFC-shaped rules before anything else. Malformed input is rejected immediately.
2. Domain and MX posture. We resolve the domain’s mail exchangers and note whether the domain is configured to accept mail at all.
3. Mailbox signals. Where the mail server allows it, we check whether the specific mailbox appears to exist, without exposing raw SMTP transcripts on this page.
4. Confidence and reason codes. Every observation from the steps above is attached to the result as a reason code (catch_all_domain, role_based_address, disposable_domain, mx_missing, and others) and rolled into a confidence level.
5. Pre-Send Decision. Confidence, reason codes, and your account’s policy combine into a recommendation: send, review, or suppress.

The API and the dashboard use the same underlying result shape, so a decision made by a teammate reviewing a list in the UI matches what your integration receives from the endpoint.

Confidence, not a coin flip

A binary checker has to force every address into one of two buckets, even the ones it genuinely cannot resolve. We treat “we don’t know” as a legitimate outcome. When mailbox-level signals are unavailable or ambiguous, the result reflects that with a lower confidence level and the reason codes that explain why, rather than guessing and calling it valid.

Honest about catch-all and major webmail domains

Catch-all domains and large webmail providers are two of the most common sources of false confidence in verification tooling. A catch-all domain will accept a lookup for almost any local part, which means a naive checker can report “valid” for an address that was never actually confirmed to exist. We flag these cases explicitly with reason codes instead of implying certainty we don’t have. The goal is an accurate signal, not a reassuring one.

Built for pre-send workflows

Whether you verify one address before a transactional send or run a Pre-Send Decision as a gate ahead of a campaign export, the contract stays the same across the API and the dashboard: confidence, reason codes, and a recommendation, not a bare status you have to interpret on your own.