Separate the evidence layers
An address can be syntactically well formed while its mailbox does not exist. A domain can publish an MX record while rejecting a particular recipient. A server can accept a recipient during SMTP and reject later, or accept mail for every local part. None of those observations proves permission to send marketing messages. Keep syntax, routing, recipient response, delivery and consent in separate fields.
Authentication concerns another question: whether a message is authorized by or signed for particular domains and whether those identities align with the visible author domain. A recipient-address validation result does not establish SPF, DKIM or DMARC success for a message. Likewise, a DMARC pass says nothing about whether the recipient wanted that message.
Interpret SMTP responses in context
RFC 5321 distinguishes temporary negative replies, permanent negative replies and successful replies at defined stages of the SMTP transaction. Record the stage, response and timestamp. A temporary response invites a retry strategy, not an immediate invalid-address label. Acceptance of RCPT TO alone is not acceptance of complete message content or proof of delivery into an inbox.
Catch-all behavior creates an important uncertainty. If two invented local parts and a known address all receive similar recipient-stage acceptance, that is evidence of the server's response pattern, not proof that each mailbox exists. Some systems intentionally avoid disclosing recipient validity. Others queue accepted messages and later produce a delivery failure. Do not promise a complete mailbox directory from these observations.
Use the validation evidence table
Consider five hypothetical observations: syntax rejection by a specified parser; a 550 response at RCPT TO; a 450 response at RCPT TO; similar recipient-stage acceptance for several invented local parts; and complete-message acceptance followed by a delivery failure. Label them respectively as parser rejection, a permanent refusal for that transaction, temporary refusal, observed acceptance with mailbox existence unknown, and later delivery failure. A 550 can reflect policy rather than nonexistent mailbox. None establishes consent or sender authentication. These are teaching inputs, not supplied test results or executed probes.
In an authorized production workflow, retain only the minimum address information and response detail necessary for the stated purpose. Avoid invasive or unsolicited probing. Agree how unknown outcomes affect downstream work: hold for review, request confirmation through an existing relationship, or stop the operation. A permissive unknown-to-valid mapping creates false confidence; unknown-to-invalid can discard legitimate contacts. Make that trade-off explicit rather than hiding it inside a green tick.
Preserve the exact boundary
RFC 5321 Sections 3.3, 4.2.1, 4.2.5 and 6.1 distinguish transaction stages, response classes and acceptance responsibility. A returned MX is not a mailbox list; absence of MX alone also does not prove no mail route because Section 5.1 defines implicit MX handling. RFC 9989 Sections 4.4 and 5.3.5 evaluate authenticated domain alignment for a message, not recipient existence. No live probing, sending or mailbox enumeration was performed.