发件人归属将观察到的邮件路径连接到负责任的服务。这与识别 IP 所有者或查找熟悉的提供商名称不同。在依赖其发件人库存或允许其推荐新授权之前，根据故意模糊的示例评估代理。
定义您需要的标签
独立的基础设施提供商、客户服务实例、企业所有者和审批状态。共享提供商地址可能支持第一个标签，而其余三个标签则未知。一个 DKIM 域标识协议内的签名责任；它本身并不识别采购部门或当前的批准。 RFC 6376描述了签名身份和验证语义。
使用受控样本、特定于帐户的提供商配置和服务所有者决策构建黄金集。将分歧保留为未解决的标签。不要使用代理的早期猜测作为基本事实，并且不要将正确的提供商识别作为正确的业务服务归因进行奖励。
包括强制弃权的案例
考虑五个假设的案例描述：具有两个看似合理的服务的共享基础设施；无需原始账户验证的转发路径；仅提供者的线索；由帐户配置、匹配的受控样本和可接受的所有者支持的服务；和冲突的所有者记录。根据提议的保守规则，需要唯一的服务实例和佐证，只有第四个支持归因。其他四个需要指定缺失的证据或冲突解决方案。
这是一个说明性规则，而不是发件人识别引擎或执行的分类器。真实的架构可能需要额外的路由、网关和帐户证据。当连接 IP 发生变化时， DKIM身份验证可以在某些转发中幸存；它不一定能在消息修改后幸存下来。仅地址相关性无法解释每条间接路径。
测量重要的误差
将错误归因与弃权分开计算。错误的归因可能会授权错误的发件人或隐藏受损的集成。弃权会增加调查工作，但会保留不确定性。报告已回答案例的正确归属以及整套案例的覆盖范围；一个只回答一种简单情况的系统不应该显得普遍准确。
如果想象的系统仅正确回答了已证实的案例，而对其他四个案例弃权，则回答案例的正确性将为 1/1，而答案覆盖率为 1/5，即 20%。这些假设的计数并不能确定生产精度或未来是否存在错误。单个简单回答的案例无法支持广泛的准确性主张。对于实际评估，保留具体的输入、预期的标签和观察到的输出，以便审阅者可以质疑答案和标签的基本原理。
将评估与运营联系起来
将未解决的案例发送给服务所有者或邮件管理员，并列出缺失的证据。请勿添加 SPF 权限，委托 DKIM选择器 或放松 DMARC 仅仅因为提供者看起来合理。 RFC 9989's 结盟 结果回答身份验证问题，而不是业务授权问题。
更改代理、源丰富、解析器或提供程序映射后重新测试。在授权时包括真实调查中的反面例子，并尽量减少个人数据。保留版本化的标签基本原理，这样分数的提高就不能仅仅通过重新定义已知的不明确案例来实现。此测试设计未暗示EmailAuth归因功能。