一封邮件可能先出现临时失败，之后才被成功投递。灰名单是可能的原因之一。限流和其他临时问题也会产生相同的状态码类别。
灰名单是如何工作的？
收件方临时拒绝一个陌生的发送客户端，并检查后续尝试是否符合重试条件。
RFC 6647 描述了这种反滥用技术。从不重试的软件无法通过该检查完成投递。
收件方返回一个临时 SMTP 失败，由发送系统负责保留并重试该消息。通过重试测试即可消除该障碍。收件方的其他过滤规则仍然适用。
收件方如何识别重试？
收件方将新尝试中的信息与先前尝试的记录进行比对。
RFC 6647 建议跟踪发送 IP、信封发件人和第一个收件人。信封发件人是用于投递失败通知的地址。
这些标识符的变化会使重试看起来像一封新邮件。因此，从多台服务器发送可能会使匹配变得复杂，具体取决于收件方的策略。
RFC 建议在成功重试后允许来自该 IP 的后续流量。它还建议过期不活跃的记录，以免许可无限期存在。
为什么灰名单能阻止部分垃圾邮件？
它能阻止只尝试一次就放弃临时失败的发送软件。
该技术测试的是重试行为，不能判定邮件内容是否安全或被期望。会重试的滥发软件同样可以通过检查。
因此收件方需要其他过滤信号。通过灰名单并不能证明身份验证、用户同意或良好的发送信誉。
延迟会持续多久？
延迟取决于发件方何时重试，以及收件方认为哪些尝试在有效时间内。
RFC 6647 建议默认重试窗口为 1 分钟到 24 小时，以适应常见的重试计划。这是收件方用于识别重试的范围，并不承诺在该时段内完成投递。
例如，30 秒后的重试对该默认窗口而言过早。30 小时后的重试可能被视为一次新的尝试。符合条件的重试仍需通过收件方的其他检查。
一个在一小时后才重试的发件方无法更快地通过该检查完成投递。对于 10 分钟后过期的验证码，投递到达时验证码已不可用。
如何区分灰名单和其他失败？
使用回复详情和重试历史。仅凭临时状态码不能证明原因是灰名单。
| 观察结果 | 能确定的内容 |
|---|---|
4xx，随后成功投递 | 临时失败已消除。灰名单是可能的原因之一 |
重复的 4xx 回复直至过期 | 投递始终未完成。回复文本和重试模式有助于确定原因 |
5xx 回复 | 针对该 SMTP 请求的永久失败 |
RFC 6647 讨论了终止连接时使用 421 以及其他情况下使用 450 的做法。它未规定回复措辞，因此文本不一定会明确提及灰名单。
发送方运维人员应排查什么？
确认消息已被重试，并且其标识信息仍然适合收件方的匹配策略。
检查重试时信封发件人是否发生变化或是否在不同发送 IP 之间切换。还要检查不同的接收 MX 服务器是否能识别相同的重试历史。
RFC 6647 建议接收服务器共享灰名单数据库，因为重试可能到达不同的目标服务器。匹配失败会导致合法邮件反复延迟。
当延迟持续存在时，向收件方运维人员提供尝试时间、IP 和回复文本。RFC 支持收件方为与灰名单不兼容的合法发件方设置例外。
收件方应该对已认证的提交进行灰名单检查吗？
RFC 6647 建议运维人员将其自身提交服务的已认证客户端排除在灰名单之外。这些客户端已通过认证来提交邮件，再测试陌生发件方是否重试只会增加不必要的延迟。在控制该规则的接收或提交服务处配置即可。
对于使用发送平台的应用，请查看消息的投递结果。再次发送并不能修复第一次尝试的灰名单匹配。这样做可能产生重复邮件。
简而言之
灰名单测试重试行为。
临时失败要求发送服务器再次尝试，并不构成永久拒绝。
重试不保证被接受。
该尝试必须满足收件方的时间和身份检查，以及其他邮件策略。
时间取决于双方服务器。
收件方的重试窗口和发件方的重试计划共同决定延迟时长。
反复延迟需要排查。
在断定原因是灰名单之前，先检查回复详情、重试记录和变化的发件方标识符。