发布域名的邮件记录并不会配置发送邮件的服务器的反向 DNS。该记录属于发送 IP 的地址区域。
谁控制 PTR 记录？
负责该 IP 地址的运营方控制其反向 DNS，或将该控制权委派给他人。
反向 DNS 区域保存与地址块关联的名称。你的域名 DNS 区域是一个独立的权限区域。拥有编辑 example.com 的权限并不意味着你有权更改发送 IP 的 PTR 记录。
托管服务商可能提供控制面板或接受配置请求。发送平台通常会管理其提供的地址的反向区域。即使你的域名记录托管在其他地方，也应通过负责该地址的运营方进行操作。
正向和反向查询应当显示什么？
发送 IP 必须解析到一个主机名，该主机名能反向解析回同一个 IP。当这些查询结果不一致时，Gmail 可能会临时限制或阻止邮件。
Google 的发件方要求要求双向匹配。在 PTR 主机名上发布一条包含发送 IPv4 地址的 A 记录。对于 IPv6，发布一条 AAAA 记录。
如果 PTR 记录指向 mail.example.com，该主机名必须拥有包含发送 IP 的地址记录。不再解析的主机名无法通过此检查。仅解析到其他 IP 的主机名同样无法通过。
RFC 1912 建议为拥有多个 IP 的主机的每个地址配置匹配的反向记录。只检查一个地址可能导致来自其他地址的流量缺少有效的反向查询。
将 PTR 记录直接指向持有发送 IP 地址记录的主机名，以避免额外的查询。CNAME 别名会增加这一间接层，RFC 1912 不建议这样做。
Gmail 是否要求低发送量的发件方提供 PTR 记录？
是的，Gmail 要求每个发件方都有匹配的正向和反向 DNS。
该要求不取决于是否达到大批量发件方的门槛。一个发送密码重置邮件的低流量应用程序仍然需要正确配置的发送 IP。
Google 的 Postmaster Tools 仪表板包含一项 PTR 记录错误或缺失的投递错误。如果出现该错误，请先检查发送 IP 的反向查询，而不要急于更改无关的域名身份验证记录。
邮件服务器通过包含其主机名的 HELO 问候语来标识自身。按照 Spamhaus 的建议，将该问候语中的主机名与服务器的主机名及反向 DNS 保持一致。即使接收方未使用 Spamhaus 列表，配置错误的服务器也可能遇到投递问题。
您应该为发送环境做什么？
通过发送 IP 的运营方配置反向 DNS，或要求该运营方修正不匹配的记录。
| 发送方式 | 谁可以配置反向记录 |
|---|---|
| 平台的共享发送 IP | 平台或其地址提供商 |
| 平台的专用发送 IP | 平台或其地址提供商 |
| 您自己的邮件服务器 | 您的托管提供商，或在反向区域控制已委派的情况下由您自行管理 |
专用 IP 并不会自动赋予您对其反向区域的控制权。托管服务仍可能存在不匹配的情况。在排查新地址问题时，请确认配置是否正确。
对于平台发送，请将失败的 IP 和投递错误提交给支持团队。对于您自行管理的服务器，请检查 DNS 的正向和反向两个方向以及问候主机名。封禁列表检查针对的是另一种可能的拒信原因。
简而言之
PTR 记录属于地址区域。
负责某个 IP 地址的运营方控制其反向 DNS，或将该控制权委派给他人。
正向和反向查询必须一致。
发送 IP 必须映射到一个主机名，该主机名能反向解析回同一个 IP。
Gmail 要求每个发件方都有反向 DNS。
匹配的正向和反向 DNS 是基本要求，与发送量无关。
发送方的运营方负责修复。
当你无法编辑反向区域时，请联系负责该 IP 的平台或托管服务商。