分离证据层
一个地址在语法上可能是正确的，但其邮箱不存在。一个域可以发布一个 MX记录 同时拒绝特定的收件人。服务器可以在SMTP期间接受收件人并稍后拒绝，或者接受每个本地部分的邮件。这些观察结果均不能证明允许发送营销信息。将语法、路由、收件人响应、传递和同意保留在单独的字段中。
身份验证涉及另一个问题：消息是否由特定域授权或签名，以及这些身份是否与可见的作者域一致。收件人地址验证结果未建立 SPF, DKIM 或者 DMARC 消息成功。同样， DMARC通行证也没有说明收件人是否需要该邮件。
在上下文中解释SMTP响应
RFC 5321在SMTP事务的定义阶段区分临时否定答复、永久否定答复和成功答复。记录阶段、响应和时间戳。临时响应需要重试策略，而不是立即无效地址标签。单独接受 RCPT TO 并不表示接受完整的消息内容或送达收件箱的证明。
-all行为造成了重要的不确定性。如果两个发明的本地部分和一个已知地址都收到类似的收件人阶段接受，则这是服务器响应模式的证据，而不是每个邮箱存在的证据。有些系统有意避免泄露收件人的有效性。其他人对接受的消息进行排队，然后产生传递失败。不要承诺根据这些观察结果提供完整的邮箱目录。
使用验证证据表
考虑五个假设的观察：指定解析器的语法拒绝； RCPT TO 的 550 响应； RCPT TO 的 450 响应；对几个发明的本地部件进行类似的接收阶段验收；以及完整消息接受后传送失败。将它们分别标记为解析器拒绝、对该事务的永久拒绝、临时拒绝、观察到邮箱存在未知的接受以及后来的传递失败。 550 可以反映策略而不是不存在的邮箱。没有建立同意或发件人身份验证。这些是教学输入，而不是提供的测试结果或执行的探测。
在授权生产工作流程中，仅保留规定目的所需的最少地址信息和响应详细信息。避免侵入性或未经请求的探测。商定未知结果如何影响下游工作：等待审查、通过现有关系请求确认或停止操作。宽容的未知到有效的映射会产生错误的信心；未知到无效可以丢弃合法的联系人。让这种权衡变得明确，而不是将其隐藏在绿色勾号内。
保留精确的边界
RFC 5321第 3.3、4.2.1、4.2.5 和 6.1 节 区分交易阶段、响应类别和接受责任。返回的MX不是邮箱列表；单独缺少MX也并不能证明没有邮件路由，因为第 5.1 节定义了隐式MX处理。 RFC 9989第 4.4 节和 5.3.5 节 评估已验证 域对齐 对于一条消息，而不是收件人的存在。未执行实时探测、发送或邮箱枚举。