10. 其他主题

本节讨论与 DMARC 部署和运行相关的若干主题.

10.1. SPF 特有问题

SPF 与 DMARC 一起使用时会带来一些问题, 域所有者和邮件接收方应对此有所了解:

1. 仅 SPF 认证: 如果域所有者只发布 SPF 策略而不发布 DKIM 策略, 则所有电子邮件转发 (RFC5321.MailFrom 域发生变化的情形) 都会导致标识符对齐失败.

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

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

10.2. DNS 负载与缓存

DMARC 实现者应了解以下与 DNS 相关的考虑:

1. 查询量: 邮件接收方会为每一封经过 DMARC 评估的消息查询 DNS 中的 DMARC 记录. 高流量接收方应实现适当的缓存策略.

2. 缓存: DMARC 策略的 DNS 记录应按照其 TTL (Time To Live) 值缓存. 域所有者应设置适当的 TTL 值:

   • 在策略推出或变更期间使用较短 TTL (例如 300 秒)
   • 对稳定策略使用较长 TTL (例如 86400 秒)

3. 否定缓存: 缺少 DMARC 记录的结果也应按照 SOA 记录的否定缓存 TTL 进行缓存.

10.3. 拒绝消息

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

1. SMTP 拒绝与 Post-SMTP 拒绝:

   • SMTP rejection (在 SMTP 事务期间) 更可取, 因为它向发送 MTA 提供即时反馈, 且不需要生成退信消息.
   • Post-SMTP rejection (接受消息之后) 应避免使用, 因为它可能导致 backscatter.

2. 拒绝代码: 在 SMTP 期间拒绝时, 使用适当的 5xx SMTP 回复代码. 合适的消息可以是:

   550 5.7.1 Message rejected per DMARC policy for example.com

3. 用户通知: 如果合法用户的消息因 DMARC 失败而被拒绝, 应考虑是否通知他们.

10.4. 标识符对齐考虑

有若干考虑适用于标识符对齐:

1. 子域对齐: 在宽松模式下, 子域被视为对齐. 域所有者应注意, 这意味着只要 SPF 或 DKIM 对组织域通过, 来自任意子域的邮件都会被视为对齐.

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

   • 第三方能够发送 DKIM 签名消息, 且 "d=" 标签中包含域所有者的域, OR
   • 第三方的发送 IP 地址包含在域所有者的 SPF 记录中, 且 RFC5321.MailFrom 域可以设置为对齐

3. 多个发送来源: 拥有多个发送来源 (内部邮件服务器, 电子邮件营销服务, CRM 系统等) 的域所有者必须确保所有来源都能产生对齐的消息.

10.5. 互操作性问题

DMARC 部署可能与某些电子邮件实践产生互操作性问题:

1. 邮件列表:

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

2. 转发:

   • 问题: 转发会破坏 SPF (转发服务器的 IP 未获授权)
   • 解决方案:
     • 依赖 DKIM (如果内容未改变, DKIM 可以经受转发)
     • 转发器可以实现 SRS (Sender Rewriting Scheme)

3. 间接电子邮件流: 任何消息被修改或通过中介转发的电子邮件流都可能出现 DMARC 问题. 详见 [DMARC-INDIRECT].

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

---