550 5.1.1 响应将注意力引向目标邮箱地址。这不是添加一个请求 SPF 包括。保留准确的响应并确定地址是否输入错误、更改、删除或接收系统以不同方式解释。
区分地址和身份验证
RFC 3463将 X.1.1 定义为错误的目标邮箱地址。增强的主题涉及寻址，而安全和策略则使用另一个主题类别。前导 5 表示永久故障。仍然保留诊断散文，因为实施和网关可以提供对实际事件重要的附加上下文。 RFC 3463第 3.2 节.
SPF, DKIM 和 DMARC 地址发件人身份验证和策略。它们不会创建目标邮箱或修复拼写错误的本地部分。在没有证据的情况下进行身份验证更改可能会损坏其他邮件，同时使原始收件人故障保持不变。适当时将调查转给地址所有者或接收管理员。
验证预期目的地
将失败的信封收件人与目标人员通过现有可信渠道提供的地址进行比较。检查是否存在拼写错误、过时的自动完成条目、旧别名以及最近的域或帐户更改。不要假设可见的“收件人”标头等于信封收件人；转发和应用程序路由可以使它们有所不同。
如果组织控制接收系统，请检查邮箱或别名配置以及相关接收日志。如果没有，请要求授权联系人确认地址，而不是探究大量可能的替代方案。除非调查需要，否则不要将个人地址纳入广泛的事件报告中。
了解SMTP观察证明了什么
RFC 5321允许系统以防止简单探测证明单个邮箱存在的方式处理收件人验证和后续传送。成功的 RCPT TO 响应之后可能会出现失败。 -all处理和保护行为也限制了单一观察所建立的内容。接受并不表示同意发送营销邮件。 RFC 5321第 3.3、3.5 和 6.1 节.
避免将地址验证分数视为实际收件人确认的替代品。语法有效性、域路由、 SMTP接受和成功传递是不同的事实。在决定是否更正、禁止或调查某个地址时，请保留这些区别。
比较两个假设的收件人政策
在情况 A 中，组织确认只有staff@example.test是配置的目标，并且其日志以 550 5.1.1 拒绝missing@example.test 。配置加上实际诊断支持寻址调查。仅凭代码并不能证明原因是否是拼写错误、删除或过时的别名。
在情况 B 中，catch -all路由接受不匹配的本地部分进行处理。成功的 RCPT TO 不会为该确切名称建立单独配置的邮箱。这些是假设的案例，而不是执行的调查。在真实事件中，使用授权接收证据和预期联系人的确认；不要枚举公共地址来复制它们。
正确并仔细关闭
永久拒绝后停止例程不变重试。当预期收件人确认更正的地址时，创建授权的更正尝试并比较其结果。对于列表操作，根据组织的政策抑制已确认的无效地址，并保留足够的证据以避免重复导入。
关闭已确认的原因和收件人处置。如果无法收到证据，则可以说响应表明存在解决问题，但确切原因尚未得到验证。不要将这种不确定性转化为发明的邮箱删除或削弱域身份验证的建议。
选择地址修正路径
- 未确认的拼写：通过既定渠道询问预期联系人。
- 受控邮箱或别名：让其所有者检查配置和接收日志。
- 仅作为探测结果：不推断个人存在或营销许可。
- 确认无效地址：应用批准的抑制政策并防止重新导入。
- 更正的尝试：保留其与失败接收者的关系并验证新结果。