我注意到从我的SMTP服务器发送的电子邮件由于缺less反向DNS而最终在垃圾邮件文件夹中。 服务器托pipe在AWS上，其域和DNS（Route53）也是如此。
在反向DNSconfiguration官方指南中 ，亚马逊解释如下：
如果您的SMTP服务器使用您自己的公共IP地址，并且您希望Amazon Route 53响应该IP地址的反向DNS查询查询，请创build一个公共托pipe区域并将PTRlogging放在该处。 在接下来的步骤中，我们使用示例IP地址192.168.1.2。
步骤1：在Amazon Route 53控制台中，创build名称为1.168.192.in-addr.arpa的新托pipe区域
问题：
我想我不是唯一一个发现公众向导混淆的人。 谢谢！
这是您正在阅读的文档的误用或误解。
如果您的SMTP服务器使用您自己的公共IP地址
这是关于使用您自己的公共IP地址的服务器。 AWS IP不符合该标准。
您遵循的说明是针对您控制的IP地址空间，或由您的ISP委托给您的IP地址空间。 它们不适用于弹性IP地址。 在这种情况下，“不需要使用Route 53”（在这种情况下，如下面的引用所示）将会被更准确地写入，因为在这种情况下不能使用Route 53。
大部分文档不适用于AWS拥有/控制的IP地址。 使用自定义反向DNSconfiguration的唯一AWS分配的公有IP地址是弹性IP地址，不同的过程适用于同一文档。
如果您要为您的服务器使用弹性IP地址，则可以通过提交请求以删除电子邮件发送限制 （需要root帐户凭据）来configuration弹性IP地址的反向DNSlogging，并且不需要使用Amazon路由53。
分配弹性IP并configurationAlogging，例如使用Elastic IP的smtp.example.com …然后您可以使用请求表单，AWS支持将为您configuration反向logging，匹配Alogging。
示例IP（192.168.1.2）看起来像一个内部IP地址，是否正确，或者我应该使用SMTP公用IP？
这个例子不适用于你，但你总是使用Internet上的公共IP地址。 私人地址在您的networking之外是不相关的。
为什么亚马逊从托pipe区域的IP中删除最后两位数？
当你控制整个我们随便称为“C类”（CIDR / 24，掩码255.255.255.0,256地址）的块时，这就是如何实现反向DNS。 203.113.0.1的反向logging是1.0.113.203.in-addr.arpa，它是“0.113.203.in-addr.arpa”区域中的主机名“1”。 但不适用，在这里。
我在Stack Overflow上回答了一个类似的问题 。
示例IP是私人的，请使用您的公开地址。
该区域始终是“父域”，因此该区域以反向地址减去最后一个八位字节（示例中为2）开始。 在区域中，然后声明具有完全颠倒的地址作为名称的PTRlogging和作为值的域名。