摘要

  • Internet Society Pulse 于 9 月 1 日介绍 Palisade 的调查：在 99,300 个受观察域名中，58.1% 发布了有效 DMARC 记录。
  • 在已发布 DMARC 的域名中，20.7% 未列出聚合报告地址。这既不能直接证明失职，也不能说明邮箱供应商已经承接全部域名策略工作。

邮箱上线之后，发件系统往往还会增加。财务部门换了开票工具，市场部门接入新的邮件平台，客服系统也可能以同一个域名发信。谁把这些合法来源纳入清单，谁检查认证配置，谁决定何时调整策略，并不会因为邮箱账单已经有人支付就自动明确。

Internet Society Pulse 在 9 月 1 日刊出的客座文章，为这一分工问题提供了新闻切口。作者 Samuel Chenard 是 Palisade 的 CEO 及联合创始人，介绍的是该公司的研究。Internet Society 明确说明，客座观点不一定代表自身立场；这不是该机构发布的新政策。

数据看到的是配置，不是合同

与文章对应的 Palisade 供应商基准，来自 8 月 14 日一次持续八分钟的扫描。99,300 个观察域名中，有 57,732 个发布有效 DMARC 记录，占 58.1%。在这些发布者中，36,938 个要求隔离或拒收认证失败的邮件，占 64%；11,959 个没有列出聚合报告地址，占 20.7%。

后两项的分母是 DMARC 发布者，不能当成全部域名的比例。上述结果来自研究方的公开统计，本文没有复现扫描。样本取自排名靠前的网站域名，也不是所有企业邮箱域名的普查。

供应商归类还有一层限制：MX 记录显示可见的入站邮件设施，前置网关可能遮住实际邮箱平台。研究虽按网站排名区间调整比较，仍只是观察性分析，不能证明选择某家供应商造成了某种策略结果，更不能据此判断客户合同是否履行。

外包可以承接工作，但需要说清承接了什么

现行 DMARC 规范 RFC 9989，把域名策略与对齐认证、反馈观察以及合法发件问题的修复联系起来。它对域名所有者的定义包括代表客户行事的服务商。因此，这些任务可以委托，并不存在由该规范规定的、不得外包的法律责任。

真正需要明确的是服务范围。邮箱托管、DNS 操作、报告分析和策略批准，可能属于不同团队，也可能由一家托管服务商统一完成。后者的价值，恰恰可以在于把持续协调纳入服务，而不只是交付一个邮箱账号。

同样，p=none 不应被直接判为疏忽。RFC 9989 建议从这种监测策略起步，找出遗漏的合法发送源，修复认证问题，再考虑更严格的请求。有些业务发送频率低，观察时间自然不同。值得问的是谁在跟进、下一步依据是什么，而不是设置是否最严。

报告地址也只是配置线索。缺少地址，不能证明没有任何监测；存在地址，也不能证明报告已送达并被阅读。RFC 9990 对外部接收地址的授权及报告交付设有条件。公开 DNS 没有展示企业内部究竟如何分工。

共同协议之外，仍需具体安排

Lu Heng 关于最小共同规范与本地决策的论述，可用来理解这项区别：协议让各方以相同语义协作，却不替每份采购合同分配工作。这是本文的编辑分析，不是 IETF 新增的要求。

因此，结论并非把邮件系统全部收回自建。需要写清的是：合法发送源清单、报告检查、DNS 变更和策略批准，哪些已包含在服务中，哪些由客户保留，哪些另行委托。外包能够减少负担；把持续任务一并约定，才能知道减少的是哪一部分。

来源