Understand what catch-all email means, why it creates uncertainty, and how to handle risky addresses without pretending they are verified mailboxes.
Some mail servers accept recipients broadly instead of rejecting unknown mailbox names during an SMTP check. This is called catch-all or accept-all behavior. Acceptance at the domain level cannot establish that the specific recipient exists. A verifier must retain that uncertainty rather than promise delivery.
A risky status is a reason to apply a policy. Inspect the reason and accept-all signal in your actual response; other risk signals may also produce risky outcomes. Do not assume that every risky address is catch-all, and do not turn a nonzero score into a delivery guarantee.
Illustrative policy
valid -> eligible under your normal consent/sending policy
risky -> separate review segment; inspect reason and signals
invalid -> suppress from this send; request a correction
unknown -> inconclusive queue; preserve the original recordFor a new account, ask the user to confirm ownership through your normal confirmation flow. For an existing marketing list, separate catch-all rows and assess relationship, consent, recency, and observed bounce history before sending. A confirmation message establishes access only when the user completes the flow; it is not something a verifier can infer from SMTP acceptance.
To test catch-all behavior, use a domain you control with one known mailbox and one deliberately nonexistent local part. Record the server configuration, test time, and returned evidence. Keep both outcomes in the denominator. Do not label an accepted nonexistent recipient a successful mailbox verification.