保险公司的经纪人网络不是一个发送系统。经纪人可以从自己的域进行撰写、使用经批准的保险公司品牌服务或转发保单通知。活动供应商和政策管理平台添加了更多路线。在配置身份验证之前，确定每个关系有权使用哪个身份。
经纪人关系精准分类
记录经纪人是否在其自己的域或保险公司控制的发件人域下进行通信。使用自己身份的代理应该管理该域的身份验证；它的消息不会仅仅因为提及保险公司而成为保险公司域消息。如果保险公司域已获得授权，请记录具体应用、租户、目的和负责的保险公司所有者。
不要仅仅因为某些消息需要修复而为整个代理网络添加广泛的发件人权限。每个授权都应该有商业理由和已知的技术实现。转发也不同于作为保险公司发送：在决定哪个控制失败之前检查实际消息身份和可信接收者结果。
让竞选活动远离政策服务假设
外包活动可以使用策略通知中的不同应用程序、选择退出流程、模板和收件人。分别记录活动所有者和策略服务所有者。认证并不建立市场许可、政策语言的有效性或披露义务的履行。通过适用的业务和法律审查来验证这些问题。
对于活动供应商，确定客户特定的域配置、选择器、凭证所有者和退出流程。用于保单管理、测试续订、认可和其他对客户重要的不常见通知。时事通讯测试不会验证续订处理器。供应商提供定制服务的声明 DKIM 并不能证明它已为保险公司的租户启用。
设定授权期限
记录经纪人或供应商关系何时开始和结束、谁可以批准范围变更以及退出时必须删除哪些签名权限。规划顺序，以便退休的供应商不能继续按照旧的权限发送，同时合法的排队通知也不会意外滞留。不要仅仅因为合同结束日期已过而删除DNS记录，而没有协调主动迁移和批准的回滚需求。
使用批准的综合策略记录进行测试。检查可见的发件人地址、实际签名域和回复目的地。如果回复包含投保人数据，请将其路由到批准的操作系统，而不是供应商的附带测试邮箱。根据组织的政策尽量减少存储的样本并限制访问。
解释异常记录中的边界
该假设地图使用保险公司品牌的经纪人身份、活动身份和保单通知身份。这并不意味着每个经纪人都应该使用保险公司的域名。假设保单通知具有 From policy.insurer.example和有效的 DKIM签名 与d=provider.example.net.该签名未通过严格的DKIM 结盟;假设有效性，此处未验证。
例外情况应注明受影响的通知类型、所有者、原因、补偿流程和下次审核日期。在经纪商入职、供应商更换和政策系统发布后审查例外情况。使清单与监管合规性评估或保单合同内容区分开来；这些假设的身份并没有做出这样的决定。
协调经纪人退出与待续订
假设经纪人的发送委托即将结束，而批准的续订通知仍在策略系统中排队。确定哪个服务拥有该通知以及其权限是否独立于即将退休的经纪人。不要无限期地保持所有代理权限处于活动状态，也不要仅仅为了完成清单而删除每个相关的DNS记录。让责任所有者批准范围转换并验证剩余的策略工作流程。这些是假设条件，而不是实际的保险公司或合同决定。
路由清单可以单独记录用于经批准的保险公司品牌经纪人邮件的brokers.insurer.example 、用于营销的campaign.insurer.example以及用于保单服务的policy.insurer.example 。这些是说明性的身份和角色，不提供签名样本或真正的赠款。在自己的领域内发言的经纪人仍然是一个单独的身份模型。未执行密码测试、通知传送或撤销。
在其限制范围内解释身份验证
RFC 9989第 4.4 节和 5.3.5 节 区分签名的有效性、对齐和完整 DMARC 判决。单个假设的未对齐签名并不能证明不存在其他对齐的DKIM或传递对齐的签名 SPF 路径。为了 p=reject 部署时，第 7.4 节和第 8 节需要有效的DKIM而不是仅依赖SPF 。第 5.4 节将处理留给接收者策略，并且不验证消息的业务内容。这些协议边界不会取代授权的工作流程、访问、计时或收件人检查。