一位家长 DMARC 策略可以确定收件人应如何处理某些身份验证失败的子域邮件。它无法告诉您哪个应用程序发送了该邮件、谁批准了该邮件，或者关键通知服务是否仍然有效。这些问题需要与收到的消息证据相关联的发件人清单。
这种区别在执行过程中很重要。 DNS检查可能会显示组织主域的保护策略，而旧的活动平台使用显式子策略，子公司控制自己的命名空间，或者密码重置服务使用不相关的供应商身份进行身份验证。记录和清单回答了不同的问题。
从收件人看到的域开始
对于每个业务工作流，捕获消息的发件人地址中的域。请勿替换网站域名、帐户的登录域名或邮件提供商的品牌名称。然后确定适用的策略、SPF 评估的身份和 DKIM 签署一个或多个域。
在当前的DMARC发现下，专门为作者域找到的适用记录优先于回退到 组织域 或公共后缀。当前规范使用 DNS树遍历。直系父级并不自动成为适用的组织边界。看 RFC 9989 §4.10.1.
因此，您的清单应该记录发现的策略域，而不仅仅是标记为“由父级覆盖”的复选框。还要记录所使用的接收器或评估器以及测试日期。较旧的实现可能使用遗留发现行为，因此记录计算无法建立通用部署。
比较三个子域案例
以下是综合说明，并非观察到的客户配置。认为 example.com 是组织域，当不存在子记录时，发现选择其记录，其记录包含 p=reject; sp=quarantine; np=reject。这句话中省略版本标签只是为了便于阅读；真正的政策记录必须始于 v=DMARC1.
- 作者域案例：现有
billing.example.com，没有明确的 DMARC记录;本例中适用的策略：Parentsp=quarantine邮件失败；库存还必须建立什么：哪个计费工作流程发送、其所有者以及接收到的消息的一致身份验证结果 - 作者域案例：不存在
unused.example.com，没有明确的政策；本例中适用的策略：Parentnp=reject邮件失败；清单还必须确定的内容：它是否确实不存在于DNS中以及是否有任何合法工作流程意外使用它 - 作者域案例：现有
news.example.com，有自己的v=DMARC1; p=none记录;本例中适用的策略：显式子项p=none政策;清单还必须确定什么：谁拥有该例外、为什么存在以及何时重新评估
在所有三种情况下，传递对齐身份都可以产生DMARC通行证。策略列描述了请求的失败处理，而不是拒绝来自域的每条消息的命令。接管人的决定仍然是独立的 RFC 9989 §5.4。这 sp 和 NP 选择规则指定于 RFC 9989 ，第 4.10.1 节.
委派的DNS区域是另一个清单项目，而不是显式DMARC策略的证明。记录谁控制它并测试从其实际作者域的发现。不要从公司图表中推断组织边界。
将每个发件人与企业主连接起来
每个有意义的发送工作流程构建一行。如果活动、事务通知和员工触发的消息使用不同的身份或路由，单个应用程序可能需要单独的行。
至少，保留工作流程、责任所有者、作者域、信封域、签名域和 选择器、发送服务、适用政策、最后一次测试和退役条件。添加证据位置和任何未解决的问题。没有确定客户帐户或企业主的指定提供商仍然是调查线索，而不是批准的发送机构。
使用 汇总报告 找到观察到的流量并将其与该寄存器进行比较。在下面 RFC 9990 §3.1 和 RFC 9989 §5.3.8，报告描述了参与接收者看到的流量；没有报告并不能证明每月或很少使用的工作流程不存在。要求应用程序所有者故意执行密码重置、收据、警报和预定作业。
更改库存政策
在更改父策略之前，请确定将继承更改的行以及具有独立子策略的行。将测试分配给其所有者。安全审查会询问合法邮件是否保持经过身份验证和一致、例外情况是否合理以及是否可以将恢复限制在受影响的工作流程中。
避免仅仅因为一个应用程序的配置不完整而削弱父策略。首先确定服务是否可以使用受支持的对齐签名域。如果需要例外，请记录其范围、批准者、有效期和验证计划。将其视为明确的风险决策，而不是悄悄地将发件人隐藏在库存中。
更改后，将新消息结果和报告与更改前的行进行比较。将政策差异和证据放在一起。仅当受影响的企业主确认其真实工作流程并且未解决的发件人有指定的下一步操作时，才关闭更改。
将保单覆盖范围和发件人覆盖范围分开
有用的仪表板有两个衡量标准：具有经过验证的适用策略的域，以及具有当前所有者和经过测试的一致路由的业务发送工作流。改进一个并不会自动改进另一个。使用 发件人库存指南 对于操作寄存器和 子域政策指南 了解发现详情。
明确下一步的决定
对于三域固定装置，在继承的 sp 策略下分组计费，在假定适用的 np 策略下未使用，在其显式 p 策略下新闻。父 sp 更改不应被描述为更改显式新闻策略。将每个工作流所有者和证据差距分开。这是所陈述的发现假设的结果，而不是实时树木行走或批准改变政策。