SMTP扫描程序可能会报告服务器的横幅不匹配 反向DNS。这一发现值得解释，而不是自动得出服务器是 欺骗 邮件。确定测试了哪个地址、扫描器期望的名称以及它是否观察到入站服务或用于真实消息的出站路由。
说出正在比较的身份的名称
服务器的初始SMTP问候语标识客户端访问的服务。客户的 EHLO 参数标识该SMTP会话的连接客户端。 PTR记录将 IP 地址映射到反向 DNS 名称。转发DNS将名称映射到地址。这些是单独的观察结果，可能涉及不同的机器或管理所有者。 RFC 5321第4.1.1.1和 4.2 节.
入站网关的问候语不一定描述用于出站传送的主机。负载平衡、网络地址转换和单独的发送池使这种比较变得复杂。在要求DNS管理员进行名称匹配之前，记录准确的测试地址和角色。否则，外观修复可能会针对与原始交付投诉无关的系统。
检查协议实际需要什么
RFC 5321描述了问候语和EHLO中的首选域名标识，并且它允许在指定情况下使用地址文字。它还表示接收者不得仅仅因为EHLO参数的验证与客户端 IP 地址不匹配而拒绝消息。这并不能消除接收者的其他安全或运营策略决策，也不能保证每个提供商都会接受。
不要将提供商记录的DNS期望转变为通用协议规则。某些接收服务对发送方应用明确的正向和反向 DNS 要求。应根据该提供商当前的第一方指南和实际连接 IP 来调查特定于提供商的拒绝。本文并未断言所有接收方都实施相同的PTR检查。
建立比较记录
捕获 UTC 时间、连接 IP、面向收件人的MX或服务角色、原始问候语、 EHLO值、 PTR答案以及PTR名称的正向查找。保持遗漏的答案、多个名称和解析器错误清晰可见。如果出站地址由托管提供商提供，请确定谁控制其PTR委托；编辑不相关的区域可能不会更改反向DNS 。
将真实被拒绝的交易与接受的受控交易（如果可用）进行比较。完整的拒绝文本比一般的扫描仪警告更重要。如果邮件已经正常流动并且扫描仪没有提供适用的规则，请将发现结果归类为身份卫生问题，而不是声称已证明投递中断。
绘制假设的拆分邮件架构
假设扫描仪连接到inbound.example并记录其服务器问候语。然而，真正的出站事务通过send.example与EHLO send.example离开。它的连接地址有一个指向send.example PTR和一个返回该地址的正向查找。扫描仪的入站横幅和出站客户端名称描述不同的系统，因此它们的差异本身并不能证明存在缺陷。
带有d=brand.example签名将是另一个独立的身份。其有效性需要实际 DKIM 确认; PTR协议无法提供该结果。同样地， DMARC 需要自己一致的认证证据。这些是假设值，不是查询的DNS 、捕获的SMTP或执行的加密验证。
对于实际拒绝，请收集真实连接 IP 和相关提供商要求的一条记录。如果提供商投诉指定反向DNS ，请与地址空间所有者解决预期的PTR 。不要仅仅因为它是扫描仪显示的第一个名称而编辑入站横幅。
在正确的所有权下进行修复
如果存在真正的配置不一致，请与各自的所有者协调服务身份以及转发和反向DNS 。保留旧值、TTL 和受影响的发送池。变更批准后，再次查询实际地址，重复原来失败的受控交易。
保持 SPF、 DKIM和DMARC检查是分开的。匹配的PTR名称不会确定其通过结果或 结盟 与可见的 From 域。仅关闭经过验证的命名或交付缺陷，并保留未解决的提供商策略问题，而不是提供装饰性横幅匹配作为全面身份验证。
将名称与正确的角色进行比较
- 服务器问候语：标识实际测试的入站端点。
- 客户端EHLO和连接 IP：识别有问题的出站事务。
- PTR和转发答案：保留时间戳和地址空间所有者。
- 提供商拒绝：获取其准确的诊断和当前的要求。
- 关闭：验证受影响的命名或交付问题，而无需从PTR索取DKIM或DMARC 。