Skip to main content

10. Other Topics (其他主题)

本节讨论与 DMARC 部署和操作相关的各种主题。

10.1. Issues Specific to SPF (SPF 特定问题)

SPF 在与 DMARC 一起使用时会出现一些域所有者和邮件接收方应该注意的问题:

  1. 仅 SPF 认证: 如果域所有者仅发布 SPF 策略而不发布 DKIM 策略,所有电子邮件转发 (其中 RFC5321.MailFrom 域发生更改) 都将导致标识符对齐失败。

  2. 邮件列表: 许多邮件列表在 RFC5322.From 字段中使用原始作者的域,但将 RFC5321.MailFrom 域更改为它们自己的域。这会破坏 SPF 标识符对齐。

  3. 转发器: 简单转发 (用户将邮件转发到另一个地址) 不会更改 RFC5321.MailFrom 域,但可能导致 SPF 失败,因为转发服务器的 IP 地址未列在原始域的 SPF 记录中。

10.2. DNS Load and Caching (DNS 负载和缓存)

DMARC 实施者应该注意以下与 DNS 相关的考虑:

  1. 查询量: 邮件接收方将为每条接受 DMARC 评估的消息查询 DNS 以获取 DMARC 记录。高容量接收方应实施适当的缓存策略。

  2. 缓存: DMARC 策略的 DNS 记录应根据其 TTL (生存时间) 值进行缓存。域所有者应设置适当的 TTL 值:

    • 策略推出或更改期间的短 TTL (例如 300 秒)
    • 稳定策略的较长 TTL (例如 86400 秒)
  3. 负缓存: DMARC 记录的缺失也应根据 SOA 记录的负缓存 TTL 进行缓存。

10.3. Rejecting Messages (拒绝消息)

当 DMARC 策略指示应拒绝消息时,邮件接收方应考虑以下事项:

  1. SMTP vs. SMTP 后拒绝:

    • SMTP 拒绝 (在 SMTP 事务期间) 是首选,因为它向发送 MTA 提供即时反馈,并且不需要生成退回消息。
    • 应避免 SMTP 后拒绝 (在接受消息后),因为它可能导致反向散射。
  2. 拒绝代码: 在 SMTP 期间拒绝时,使用适当的 5xx SMTP 回复代码。合适的消息可能是:

    550 5.7.1 Message rejected per DMARC policy for example.com
  3. 用户通知: 考虑是否在合法用户的消息因 DMARC 失败而被拒绝时通知他们。

10.4. Identifier Alignment Considerations (标识符对齐考虑)

标识符对齐适用以下几个考虑:

  1. 子域对齐: 在宽松模式下,子域被视为对齐。域所有者应该意识到,这意味着如果 SPF 或 DKIM 对组织域通过,来自任何子域的邮件将被视为对齐。

  2. 第三方发件人: 使用第三方电子邮件服务时,域所有者必须确保:

    • 第三方可以使用域所有者的域在"d="标签中发送 DKIM 签名的消息,或者
    • 第三方的发送 IP 地址包含在域所有者的 SPF 记录中,并且可以设置 RFC5321.MailFrom 域以对齐
  3. 多个发送源: 具有多个发送源 (内部邮件服务器、电子邮件营销服务、CRM 系统等) 的域所有者必须确保所有源都可以生成对齐的消息。

10.5. Interoperability Issues (互操作性问题)

DMARC 部署可能会导致某些电子邮件实践的互操作性问题:

  1. 邮件列表:

    • 问题: 列表通常修改消息 (添加页脚、主题标签等),这会破坏 DKIM 签名
    • 解决方案:
      • 列表可以使用自己的 DKIM 签名重新签名消息
      • 列表可以重写 RFC5322.From 地址 (但这会更改表面发件人)
      • 域所有者可以对邮件列表上使用的域使用更宽松的策略
  2. 转发:

    • 问题: 转发破坏 SPF (转发服务器的 IP 未授权)
    • 解决方案:
      • 依赖 DKIM (如果内容未更改,则在转发后仍然有效)
      • 转发器可以实施 SRS (发件人重写方案)
  3. 间接电子邮件流: 任何消息通过中介修改或中继的电子邮件流都可能存在 DMARC 问题。有关详细讨论,请参阅 [DMARC-INDIRECT]。

  4. 通知消息: 应将自动通知系统配置为使用对齐的标识符,或者可能需要使用"p=none"策略域。