不熟悉的发件人并不一定是恶意的，熟悉的提供商名称也不会建立客户所有权。身份验证代理应该解释证据支持什么、不能证实什么以及谁可以解决差距。安全的结果可能是在不更改配置的情况下进行精确升级。
将观察结果与归因分开
记录源IP、观察到的经过身份验证的身份、作者域、结果、报告时间范围和相关计数。保留报告的来源和局限性。然后将建议的业务归因放在单独的字段中。这可以防止提供商查找悄悄地成为客户批准特定帐户的声明。
DMARC 评估身份验证和 结盟，而不是发送服务的内部业务所有权。聚合报告描述了接收者的观察结果，并有其自己的格式和安全考虑。 RFC 9989 和 RFC 9990。使用这些观察结果作为调查证据而不是授权清单。
建立歧视性证据请求
询问应用程序所有者、客户帐户或服务配置、预期发送时间表以及安全保留的测试消息参考。最好有证据能够将该客户的服务与共享基础设施上的另一个帐户区分开来。避免仅仅为了解决一个来源而收集整个邮箱或机密。
将发件人与批准的服务注册和更改历史记录进行比较。旧记录可以解释一项服务是如何引入的，但并不能证明当前流量属于同一个账户。陈述相互竞争的解释以及将它们分开的证据，例如通过可疑路线进行的已知应用测试。
使用明确的升级条件
当所有权未经确认、身份冲突、证据陈旧或拟议的变更会影响关键流程时，就会升级。通过授权工作流程将问题发送给客户服务负责人或安全联系人。起草升级并不意味着允许将其发送到报告中找到的任意地址。
给收件人一个他们可以回答的决定：确认帐户和所有者、提供已知的消息样本或授权受控测试。包括确切的范围和截止日期，并说明调查悬而未决期间保持不变的内容。不要仅仅因为置信度分数超过无法解释的阈值而将发件人标记为已批准。
明确不改变的建议
假设源有共享提供者提示，但没有客户帐户证据或接受的所有者。拟议的变更和批准仍然缺席。向经过验证的客户联系人推荐证据请求，并确定区分候选人所需的确切帐户配置或受控样本。不要仅仅因为方便而将请求发送到从报告文章中复制的地址。
这是假设的无更改建议，而不是测量的零写入结果、执行的参考工作流程或发送的升级。在实际评估中，检查工具痕迹和有效状态，以验证是否发生任何尝试或突变。仅凭谨慎的书面答复并不能证明这些工具尊重边界。新提供的不同服务的批准不能解决原始身份歧义；首先重新评估实际目标和证据。
负责任地消除不确定性
当新证据出现时，保留其来源并重新评估归因。如果服务合法，请准备最小的必要补救措施作为单独批准的更改。如果未经授权，请遵循既定的事件流程。如果证据仍然不确定，请让该项目向所有者开放并审查触发因素。
不自动加宽 SPF， 降低 DMARC执行 或阻止商业邮件以使分类消失。记录归因决策和技术结果，以便未来的审核者可以区分需要修复的授权服务和从未获得批准的未知来源。