区分转发客户消息和发送工单更新
支持平台可以接收客户的电子邮件，将原始消息转发给代理，或生成包含引用的客户文本的新通知。这些操作在收件箱中可能看起来相似，但会创建不同的身份验证问题。在更改域策略之前，请确定正在验证哪封邮件以及其可见的“发件人”字段中显示的域。
分别绘制摄取路径和通知路径。识别客户发件人、支持地址、票务平台、任何安全网关和代理的目的地。记录平台是否保留原始消息、修改它、将其附加到新消息或创建新摘要。不要从供应商的一般功能名称推断租户的行为。
通过摄取追踪客户身份
客户消息可以直接到达票务平台，也可以通过公司邮箱的转发规则到达票务平台。每次切换时，连接服务器和信封都可能发生变化。 RFC 7208第 10.3 节 解释了为什么转发会发生变化 SPF 评估。重写的支持平台信封的通行证会验证该域在交易中的使用，而不是自动验证客户的原始可见域。
这 DMARC 比较仍然涉及有效的对齐标识符和作者域 RFC 9989第 4.4 节。嵌入在引用文本、票证字段或信封本地部分中的地址不能替代该域比较。将原始客户身份保留在证据记录中可见，而不要仅仅因为平台接受了票据就声称其已通过身份验证。
运营支持系统的机构还需要决定在摄取时保留哪些原始认证证据。从消息的不受信任部分复制的标题行不足以提供来源。记录执行检查的接收系统以及接受该结果的可信边界；当平台不公开数据时，将未知数显式保留。
在通知之前确定平台发生的变化
支持工作流程通常需要票证标识符、注释、附件处理和模板。这些需求并不能证明修改原始消息对其签名无害。在下面 RFC 6376第 3.4 和 5.4 节，效果取决于覆盖的标头、主体材料和 规范化。为已签名的主题添加标签可能很重要；添加不相关的未签名标头并不一定会使签名无效。
新的平台通知是不同的消息。根据自己的优点评估其选择的作者域、实际信封和签名配置。如果它使用公司的支持身份，则公司和提供商需要针对该路由进行授权的一致发送设置。如果它将客户的域显示为新消息作者，则平台不能假设其自己的无关签名授予代表该域的权限。
仅更改显示名称或将客户地址放入回复中并不能确定DMARC 结盟。这些字段可能有助于人工工作流程，但身份验证评估仍然遵循协议定义的消息身份。对发件人演示文稿的任何更改都应进行审查，以确保用户清晰度和回复路由，而不仅仅是为了通过测试。
将接收器异常排除在默认设计之外
如果消息通过支持 ARC 的中介， RFC 8617第 7.2.1 节 允许早期评估以告知接收者当地的决定。它不会使转换后的客户消息获得普通的对齐通行证。当前的 微软指导 描述了受管理组织的特定可信密封器机制，并非所有帮助台平台的普遍接受。
截至本次审核， RFC 8617仍处于实验阶段，并且 重新分类ARC的提案 工作正在进行中。避免围绕假设的未来采用或删除来设计工单工作流程。如果需要，例外情况需要记录的接收者环境、准确的中介身份、安全批准和删除标准。由于邮件包含票号而广泛绕过过滤并不是以证据为主导的补救措施。
首选调查从受支持的、经过身份验证的通知路径开始，并为授权代理保留原始证据。它不应该要求削弱客户的域策略、删除签名或从他们的邮箱收集机密。
票证包装的虚构示例
在这个虚构的案例中， example.org的客户写信至support@example.com 。该公司将消息转发到票务平台，该平台为代理创建新的通知。该通知引用客户的消息，但以support@example.com作为其作者域发送。它的信封和 DKIM 配置必须作为公司通知路由进行评估，与客户消息的早期身份验证分开。
假设替代模板重复使用客户的可见地址，同时仅使用平台的不相关域进行签名。这种发明的配置暴露了一个对齐问题；引用的文本和成功创建票证并不能解决问题。拟议的审查将比较支持的模板和身份设置，获得所有者批准，并在更改生产之前测试代表新通知。
此示例未获取客户消息、平台设置或接收者结果。该场景展示了决策边界，而不是针对指定供应商的经过测试的建议或特定模板失败的证据。
将摄取和代理交付验证为单独的结果
收集经批准的非敏感样品用于原始直接传递、间接摄入和生成通知。保留每条不同消息的路由标识符、时间戳、信封观察、签名和可信结果。仅在有助于关联路径且不会不必要地暴露客户内容的情况下添加票证标识符。
独立记录摄取成功、代理邮件传送和正确的回复路由。当代理通知被拒绝时，票证可能存在；当响应发送到错误的邮箱时，代理通知可能会到达。该目录的确切原始证据要求仍然开放：直接和间接交付样本以及路线、信封、签名和可信结果的比较。本手稿不提供租户执行、客户数据收集或经过验证的支持工作流程。