即使消息仍然可重试，临时故障也可能需要立即修复。即使最初的失败尝试不应该不做任何更改，在进行合法的配置更正后，永久性故障也可能会消失。将SMTP类视为处理指令，将诊断文本视为调查证据。
阅读失败阶段的课程
RFC 5321区分肯定完成、中间回复、瞬时否定完成和永久否定完成。 4xx 响应允许正常的稍后重试处理。 5xx 响应意味着未执行所请求的操作，并且不应以不变的方式重复相同的请求。确切的阶段很重要：拒绝的接收者、拒绝的 DATA 命令以及消息内容后的拒绝具有不同的事务边界。 RFC 5321第 4.2 和 4.5.4 节.
DATA 将接受消息的责任转移给该SMTP接收者后，最终的肯定响应。它不会在收件箱中建立放置位置。相反，在客户端传输最终终止符之后但在看到回复之前发生连接失败可能会导致结果不确定。如果第一个副本被接受，盲目手动重新提交可能会产生重复。
建立队列时间线
记录第一次尝试、每次相关响应、最后一次尝试、下一次计划尝试、队列期限、收件人状态和到期决定。包括消息的业务用途：过期的登录链接和发票不具有相同的使用寿命。保留发送系统的实际重试策略，而不是发明通用的提供者延迟。
RFC 5321提供排队指导，包括延迟重试而不是连续尝试。应用当前平台支持的队列控制和组织的交付要求。不要使用紧密的重试循环来测试远程限制是否已清除。评估负载和恢复时，将新的生产流量与排队重试分开。
比较三个假设结果
这些是发明的诊断案例，而不是捕获的邮件交易。案例 A 在 RCPT TO 收到 451，因此收件人未被接受。在调查所述情况时，使该项目遵守发送服务的重试政策。如果稍后的尝试达到最终数据接受，记录其覆盖的收件人和消息；该单一结果并不能解决每个排队的项目。
情况 B 因收件人无效而收到 550 5.1.1。停止不变的例行重试，并通过可信联系人确认地址。情况 C 发送 DATA 终止符，但在看到最终回复之前就失去了连接。与 A 或 B 不同，它的接受程度是未知的。在创建另一个副本之前查找接收者和队列证据；相同的 Message-ID 并不能保证重复数据删除。
将补救措施与原因相匹配
对于临时DNS 、网络或服务故障，请在队列保持有限状态时调查失败的依赖项。对于与身份验证相关的延迟，请修复指定的身份验证问题，而不是简单地等待。对于永久无效收件人响应，请在创建更正的消息之前通过现有合法通道验证地址。
当不确定是否接受时，请在重新提交关键业务邮件之前协调队列和接收日志。保留原始 Message-ID 和交易证据以供调查，同时避免有关重复数据删除的不受支持的假设。仅当队列增长停止、代表性预期消息完成且过期或失败消息具有显式处置时才关闭事件。恢复一条测试消息并不能证明整个积压消息已送达。
选择重试、修复或协调
- 4xx 已知不接受：将项目保留在支持的队列策略下并调查依赖性。
- 5xx：停止未更改的例行尝试并确认合法的更正。
- 缺少最终数据回复：将接受视为未知；在手动重新提交之前协调接收者证据。
- 关闭：记录每个受影响收件人的结果，包括过期消息和可能的重复消息。