☰

为不符合 RFC5322.From 域的邮件中继添加 SPF 记录有什么好处？

tag-icon • tag-icon email spf
为不符合 RFC5322.From 域的邮件中继添加 SPF 记录有什么好处？

使用邮件传递服务（例如 AWS SES 或 SendGrid）时，将域的 SPF 记录包含在 RFC5322.From（header-from）标头中是否有好处？

按照它们的默认操作方式，它们使用自己的 RFC5321.MailFrom（信封发件人），根据标准，SPF 应该对此进行检查。

但是，我想知道是否还有好处，比如损坏的邮件服务器或可能无论如何都会检查 RFC5322.From 是否符合 SPF 的邮件服务器，以进行垃圾邮件检查。或者干脆就不用管了，因为它从未被检查过。想知道是否有人在这方面有现场经验。

例如，AWS SES 在 RFC5321.MailFrom 中使用 amazonses.com 的子域。此问题假设自定义“MAIL FROM”设置未更改。

答案1

SPF 检查的典型实现是在之后立即完成的MAIL FROM（拒绝可能在之后触发，RCPT TO以便在日志中保留更多调试信息）。这是在有任何内容（DATA）之前，包括邮件头。RFC 7208, 2.2MailFrom描述了如何根据 RFC5321和进行检查HELO/EHLO。它还明确不鼓励根据 SPF 记录检查任何其他身份（如 RFC5322.From）。

未经发布 ADMD 的明确批准，不建议根据 SPF 版本 1 记录检查其他身份，因为已知有些情况会产生错误结果。例如，几乎所有邮件列表都会重写身份MAIL FROM（请参阅第 10.3 节)，但有些不会更改消息中的任何其他身份。定义其他身份的文档必须定义明确批准的方法。

DMARC 策略（RFC 7489）提供了这样的“明确批准”，进一步告诉接收者域所有者希望消息如何两个都未对齐的 SPF 和未对齐的 DKIM（RFC 6376) 签名进行处理。DMARC 保护 RFC5322.From，而 SPF 和 DKIM 本身根本不识别这种对齐。如果某些垃圾邮件保护系统在没有明确批准的情况下惩罚未对齐的邮件，那么这是他们这边的问题，不应像你建议的那样尝试使用非标准 SPF 记录来解决问题。

引文中描述的挑战仍然存在于 DMARC 中，因为如果消息被转发……

  • 与原件一样MAIL FROM，它无法通过 SPF 检查。
  • 如果重写MAIL FROM，它将无法通过 DMARC 校准。

因此，建议使用 DKIM 和 DMARC，因为这样转发时更安全。此外，想要发布邮件p=reject（甚至p=quarantine）的人应该首先努力配置所有可能的合法发件人，使其与 DKIM 或 SPF 保持一致——最好两者兼而有之。

例如，对于 Amazon SES，这意味着设置自定义MAIL FROM域：添加子域名及其MXSPF 记录。这还需要轻松DMARC 策略允许对齐，如果组织域匹配，定义在RFC 7489 3.1。

相关内容