A DMARC 策略应反映域的作用以及组织可以对其邮件建立哪些内容。严格控制的通知域、员工通信域和不发送任何内容的域可能需要不同的决策。
从域的目的和合法路由开始。然后评估所请求政策的后果、支持该政策的可用证据以及您无法控制的接收者行为。
在选择策略之前描述域
协议参考： RFC 5321 §5.1。下面的操作清单和决定是编辑指南。
记录该域是否发送员工信件、交易消息、活动或未经授权的邮件。包括子域、在中央 IT 之外购买的系统和服务。
一个 MX记录 描述接收路由。它不会清点可以使用 From 中的域的每个系统。同样，没有邮箱并不表明没有应用程序发送通知。
为每条物料路线赋予业务目的和所有者。在调查之前，未知来源仍然未知。熟悉的提供商名称或大型云网络并不足以证明其获得批准。
说明所请求的政策的含义
协议参考： RFC 9989 §4.7, RFC 9989 §5.4。下面的操作清单和决定是编辑指南。
该策略传达所有者对未通过DMARC邮件的评估。它不配置发送者的身份验证或确定每个接收者的最终操作。
- 政策：无；决策背景：业主没有表示对失败的处理偏好
- 政策：检疫；决策背景：在所有者的评估中，使用失败被视为可疑
- 政策：拒绝；决策背景：业主认为未使用为无效
接收方仍然将身份验证和策略与其自己的处理决策结合起来。仪表板标签或已发布的DNS字符串并不能确定每条失败的邮件都被拒绝或传递的邮件已到达收件箱。
在进行更改之前，请将策略选择与合法故障发件人的修复分开。移动 一个记录 这些值之间无法创建 结盟 对于使用不相关身份的应用程序。
评估可能中断的合法路线
协议参考： RFC 9989 §7.4。下面的操作清单和决定是编辑指南。
测试关键服务，包括工资单、密码重置和续订等小批量事件。使用实际的应用程序工作流程并检查网关或中介之后收到的结果。
通用信件需要特别小心。当前的 RFC 9989 警告不要拒绝此类域，并解释了邮件列表互操作性问题。它对用户发布到列表的域的指导包括具体的观察、比较和用户策略考虑。
请阅读适用案例的指南。不要将其替换为适用于每个域的自动 7 天或 30 天进度。
比较两个不同的域目的
这是一个综合规划示例。
专用收据域有一个经批准的应用程序、一个维护的 DKIM 配置和没有人员通信。其操作员可以测试代表性收据工作流程、监控故障并定义范围变更。
员工域支持对话、角色地址和 Internet 邮件列表。直接员工邮件测试仅涵盖该活动的一部分。其政策审查还需要有关间接路线和用户影响的证据。
区别并不在于某个团队更看重安全性。当接收者对故障采取行动时，这些域具有不同的合法用途和不同的后果。
定义证据和恢复条件
准备一份决策记录，其中包含域范围、预期政策、测试的合法服务、未解决的路线、相关报告限制、审批者和验证计划。
决定什么会触发调查或恢复先前批准的状态。保留旧记录和更改历史记录。修复是业主的一项操作决策，而不是对第一个不熟悉的报告行的即兴反应。
避免隐藏人口的百分比阈值。高整体通过率可以与完全失败的关键服务共存。使用 汇总报告演练 保留分母和归因上下文。
记录原因，域名变更时查看
结果可能是策略更改、发送者更正、进一步观察、域分离或保留现有策略的决定。解释原因及其证据。
当新的应用程序、收购、网关或业务用途改变合法邮件数量时，请重新考虑该决定。这 发件人库存指南 提供操作记录，同时 检疫与拒绝 更仔细地检查处理权衡。
应用证据而不夸大其词
对于虚构的收据域，仅维护DKIM设置是不够的：需要通过对齐签名和其他参与检查的接收消息证据。对于员工领域，保留未解决的邮件列表影响作为明确的决策约束。这两种情况都不会授权DNS更改或声明已执行测试。