防止您看起来像垃圾邮件发送者的最佳实践

Question

我希望在为我的客户设置邮件时更加自信地避免误报。这是我所知道的：

1. SPF 记录很好，但并非每个垃圾邮件过滤服务/软件 (SFSS) 都使用它们。

2. 反向 DNS (PTR) 记录几乎是必需的。

3. 开路继电器不好。

   （这是我读过的“其他提示”）：

4. 邮件服务器 IP 地址的反向查找应该解析为您发送邮件的域。

5. 在与其他邮件服务器通话时，您的服务器应该说 HELO FQDN.of.your.mail.server.com。

6. MX 记录中的 A 主机记录应该是（或解析为 IP 地址）您的 FQDN.of.your.mail.server.com

对 1 和 3 感觉很好。这是我想澄清/建议的地方：

2 和 4：我做了很多挖掘，这似乎是不正确的，因为大多数垃圾邮件过滤器都在寻找一般的 PTR，而且不是由 ISP 分配的；您发送邮件的域似乎与此无关（即，如果您拥有两个用于邮件的域，则需要从两个 IP 地址分别发送带有 PTR 的域？）

5. 这是有道理的，但它是否关心 FQDN 解析为什么？它是否应该解析为当前发送所述 HELO 的 IP 地址？

6. 再次，来自各种谷歌搜索的另一个；如果您使用 Postini 作为网关服务（或与此相关的任何其他智能主机），则看不出这将如何工作。

代表另一个您没有权威的域发送怎么样？我有一些客户端 (some.branchdomain.tld) 需要以@some.corporatedomain.tld 的身份发送邮件，尽管上述公司总部不会设置中继/智能主机供他们使用。corporatedomain.tld 可以创建 SPF 记录以显示 some.branchdomain.tld 被允许发送邮件，但这是否仍会考虑“欺骗”，尤其是如果说 SFSS 不检查 SPF 记录？我应该担心这个吗？

Answer 1

我可以保证#2（反向PTR）很重要，但不是#4（邮件服务器域匹配“from”）。我们一直在设置邮件服务器，大多数邮件主机甚至都不关心#2。

主要问题始终是 AOL，它们列出了您可以核对的标准。

Answer 2

除了你提到的 HELO 字符串和 DNS PTR 记录之外，大部分有用的东西都将与内容相关，而不是与发送服务器相关。

• 如果可以避免，请不要发送 HTML 电子邮件。
• 不要包含可疑的短语（“点击取消订阅”、“隐私很重要”等）
• 不要使用“回复”标题，从您希望回复的地址发送
• ...和更多。阅读 SpamAssassin 规则集以获取更多好的示例。

至于您的“它是否关心 FQDN 解析为什么？”的问题，这完全取决于接收邮件服务器的作用，当然它可能会有所不同，但您通常不会发现太多邮件服务器依赖于FQDN 查找是一项硬性规定，因为可以在循环设置中配置多台机器。