邮件服务器的 PTR 反向解析已经返回 mail.example.com，邮件却仍进入垃圾箱，并不矛盾。PTR 只是发信身份链中的一项基础信息，收件系统还会综合 HELO/EHLO、正向 DNS、SPF、DKIM、DMARC、IP 与域名信誉、投诉、退信、发送节奏和内容特征。排查时应从投递证据逐层核对，不要因为一条记录正确就假定其他条件也正确。
先确认 PTR 和正向记录一致
连接到收件服务器的是实际发信公网 IP。对该 IP 做反向查询，应返回一个有效主机名；再查询这个主机名的 A 或 AAAA 记录，应能合理指回发信地址，这通常称为正反向一致。HELO/EHLO 使用的主机名也应可解析，不要填写 localhost 或无效内部名称。
PTR 通常由持有公网 IP 的云厂商或运营商配置，不是在普通域名 DNS 面板里随意增加一条 PTR 就能生效。共享出口、动态住宅网络和频繁变化的代理地址通常不适合承载可控的邮件服务器。
SPF 要授权真实出站地址
SPF 记录声明哪些服务器可以代表发件域发送邮件。最常见的问题是只写了实例公网 IP，但邮件实际经过云邮件网关、NAT 或第三方投递平台。应查看收件方邮件头和自家发信日志，确认最终连接来源，并按照所用服务的官方说明维护 SPF。
同一域名只能形成一套有效的 SPF 策略，多个片段应正确合并。过多 DNS 查询、错误 include、测试环境遗漏或使用过宽授权都会带来问题。修改后等待 DNS 生效，并用实际邮件头中的认证结果验证，不只依赖在线“全绿”评分。
DKIM 与 DMARC 检查的是另一条链
- DKIM：发信系统用私钥对邮件签名，DNS 公布公钥。检查选择器、签名域、密钥状态和邮件中途是否被改写。
- DMARC：要求 SPF 或 DKIM 的认证域与用户看到的 From 域满足对齐，并定义失败邮件的处理策略。
- 报告：DMARC 聚合报告可以帮助发现未经授权的发信源和配置遗漏，但报告本身也应受控保存。
SPF 通过但域名不对齐，或 DKIM 签名有效但使用了另一个不相关域，都可能无法满足 DMARC。刚开始部署时可先观察报告，再按风险逐步调整策略，避免未经验证就影响正常邮件。
用退信代码和邮件头定位，而不是猜
| 证据 | 能回答的问题 |
|---|---|
| SMTP 返回码与增强状态码 | 临时延迟、永久拒绝、策略或地址问题 |
| Authentication-Results | SPF、DKIM、DMARC 实际是否通过及对齐 |
| Received 链 | 邮件经过哪些服务器、最终出站 IP 是什么 |
| 投递平台日志 | 队列、重试、退信、投诉和连接状态 |
| 收件方管理工具 | 域名或 IP 的趋势、错误与信誉提示 |
不同收件服务商有各自策略，不能保证配置完整后每封邮件都进入收件箱。目标应是建立合法、稳定、可解释的发信行为，而不是寻找绕过垃圾邮件过滤的方法。
新 IP 为什么需要逐步建立信誉
全新的发信 IP 没有历史信誉。如果第一天突然发送大量邮件，收件系统很难判断来源是否可靠。应从真实订阅、活跃收件人和稳定的小规模发送开始，根据退信与投诉逐步调整。所谓“预热”不是机械地每天翻倍，更不能向未经同意的地址发送邮件制造历史。
发送量应平稳，避免长时间沉寂后突然暴增。硬退信地址及时停止，临时失败按 SMTP 规则有限重试；投诉和退订应尽快进入抑制列表。
内容和订阅机制同样影响投递
合法营销或通知邮件应让收件人清楚知道为何收到，发件名称和域名保持一致，并提供可用的退订或偏好设置。避免误导主题、隐藏链接、过度跟踪和大量无关附件。网页内容相同不代表投递结果相同，域名信誉、名单质量和用户互动也会改变判断。
不要通过轮换代理 IP 规避信誉
邮件信誉与 IP、域名、内容和发送行为共同关联。使用代理池频繁更换出口，不仅无法修复 SPF、DKIM 或投诉问题，还会让身份更难稳定，甚至违反服务条款。需要高可靠投递时，应使用明确授权、PTR 可控、日志完整的固定基础设施或合规邮件服务商。
DNS、PTR 和公开信誉检查工具可从极跃圈网址导航查找，用于交叉验证；是否接收最终由收件系统按实时策略决定，不应把任何单一评分当作保证。
排查记录至少保留这些字段
记录测试时间、收件域、Message-ID、实际出站 IP、PTR/A/AAAA、HELO、SPF/DKIM/DMARC 结果、SMTP 返回码、发送量、硬退信、投诉和退订。分享记录时遮挡收件地址和令牌。按这一组证据逐项修复，比反复修改邮件内容或更换出口更容易找到根因。
