Skip to main content

10. Effects on Infrastructure (对基础设施的影响)

10. Effects on Infrastructure (对基础设施的影响)​

本节讨论 SPF 对各种邮件基础设施组件的影响。

10.1 Sending Domains (发送域)​

10.1.1 DNS Resource Considerations (DNS 资源考虑)​

发布 SPF 记录的域应该注意 DNS 资源的使用。每个 SPF 检查都会对 DNS 系统产生负载。域应该尽量保持其 SPF 记录简洁, 以减少 DNS 查询的数量。

建议：

  • 使用 ip4 和 ip6 机制直接指定 IP 地址, 而不是使用 a 或 mx 机制
  • 限制 include 机制的使用
  • 避免深层嵌套的 include 链
  • 考虑使用 SPF 扁平化工具来减少 DNS 查询

10.1.2 Administrator's Considerations (管理员考虑)​

域管理员在部署 SPF 时应该考虑以下因素:

  • 邮件流映射: 确定所有授权发送邮件的服务器
  • 第三方服务: 考虑使用第三方邮件服务（如邮件列表, 营销服务）
  • 测试: 在使用严格策略（-all）之前使用软失败（~all）进行测试
  • 监控: 监控 SPF 检查结果以识别潜在问题

10.1.3 Bounces (退信)​

退信消息（即未送达通知或 NDN）会带来特殊挑战。当 MAIL FROM 为空（<>）时, SPF 检查使用 HELO 标识。

注意事项：

  • 生成退信的服务器必须有适当的 SPF 记录
  • 退信应该从授权的邮件服务器发送
  • 避免生成对伪造地址的退信（退信垃圾邮件）

10.2 Receivers (接收方)​

接收方 MTA 应该:

  • 实现 SPF 检查: 在 SMTP 事务期间执行 SPF 检查
  • 记录结果: 使用 Received-SPF 或 Authentication-Results 标头
  • 制定策略: 根据本地策略处理不同的 SPF 结果
  • 提供反馈: 向发送域提供关于 SPF 失败的反馈

10.3 Mediators (中介)​

邮件列表和转发服务等中介会对 SPF 产生影响:

邮件列表的挑战：

邮件列表通常会重写 MAIL FROM 地址, 这可能导致原始发件人的 SPF 检查失败。

解决方案：

  1. 使用列表地址: 将 MAIL FROM 重写为列表地址
  2. 使用 SRS: 发件人重写方案（Sender Rewriting Scheme）
  3. 不修改 MAIL FROM: 依赖其他认证方法（如 DKIM）

转发的挑战：

简单的邮件转发会保留原始 MAIL FROM, 但从不同的 IP 地址发送, 导致 SPF 失败。

建议：

  • 使用 SRS 重写 MAIL FROM
  • 或者不依赖 SPF 作为唯一的认证方法
  • 结合使用 DKIM 和 DMARC
Last updated on