Address-checking tools sometimes turn a single SMTP response into a definitive “mailbox exists” verdict. That label conceals several different observations: whether a route exists, whether a server accepted a recipient command and whether a message ultimately reached a mailbox. Keep those observations separate when deciding whether to correct an address or contact a customer.
Record the transaction stage
In SMTP, RCPT TO identifies a recipient for the current transaction. A successful response at that stage does not mean the server has accepted the message body. Final acceptance normally follows the completion of DATA. The receiver might be an intermediate relay rather than the final mailbox system. RFC 5321 sections 3.3 and 4.1.1.3.
Record the exact reply, timestamp, connecting route, envelope sender and receiving server. A temporary refusal is not the same as a permanent recipient error. A generic policy rejection can reflect the client or transaction rather than absence of the destination. Do not reduce every 550 to “this person does not exist,” and do not interpret a timeout as a negative directory answer.
Compare three hypothetical recipient policies
Suppose a selective receiver returns 250 for known@example.test and 550 for unknown@example.test. A different accept-all policy could return 250 for both, while a temporary failure could return 451 for both. Those assumed responses alone cannot establish delivery to a separate mailbox for either address.
These are invented policy cases, not executed recipient checks or a description of any public domain. The point is that one visible response can fit several underlying configurations. Authorized directory and routing evidence can distinguish them; a repeated probe does not automatically resolve the uncertainty.
Use a legitimate verification path
For an address in a system you administer, consult the authorized directory or mailbox owner, including aliases, groups and routing rules. For an external contact, prefer an established communication channel or a consent-based confirmation workflow. Successful confirmation of a purpose-specific message is stronger evidence of access than a speculative SMTP probe, but it still does not prove a person's legal identity or general consent to marketing.
Do not enumerate third-party addresses or repeatedly probe recipients merely because a tool makes it possible. Respect the service's rules and avoid turning a contact-quality check into abusive traffic. Test only within an authorized scope, with defined rate and stopping conditions.
Report a bounded verdict
Use labels such as “recipient command accepted,” “temporary refusal,” “permanent refusal with diagnostic” and “not established.” Preserve the underlying evidence so a later reviewer can reinterpret it. If delivery matters, follow an authorized real message through final acceptance and the recipient's confirmation rather than presenting RCPT success as an inbox guarantee. Authentication checks remain a different task: recipient acceptance does not prove SPF, DKIM or DMARC passed.
Recognize a later rejection within the same transaction
In another hypothetical exchange, RCPT TO receives 250, DATA receives 354, and the final response after message content is 554 5.7.1. The recipient command succeeded, but the server did not finally accept the message. This is an in-transaction refusal, not a later bounce after acceptance. A 354 reply is permission to transmit content, not a delivery result.
The example supports a precise label: recipient command accepted; message rejected after DATA. It does not establish whether the recipient mailbox exists, why a public provider applies a policy, or whether sender authentication passed. No SMTP connection or mailbox probe was performed for this example.
Use an evidence ladder
- Syntax or DNS route found: neither establishes a mailbox.
- RCPT accepted: report only the recipient-command outcome.
- Final DATA accepted: identify the accepting system; later delivery remains separate.
- Authorized recipient confirmation: record the specific address, purpose and time.
- Unresolved: retain the uncertainty instead of forcing valid or invalid.