将复合身份验证读取为 Microsoft 结果
Microsoft 的 compauth 字段不是另一个拼写 DMARC。它是使用身份验证和其他消息信号的综合评估，其解释属于 Microsoft 的记录处理。因此，消息可以包含外观不同的DMARC和复合结果，而标头不会存在本质上的矛盾。正确的任务是在决定结果建立之前读取每个字段、其身份上下文和关联的原因代码。
本文使用 2026 年 11 月 8 日保留的 Microsoft 主要文档。反垃圾邮件标题页标识了 2026 年 7 月 27 日的更新。未提供原始消息或租户跟踪，并且下面的示例明显是虚构的，而不是经过编辑的标头。该目录需要真实的原始消息示例才能发布操作结论。
保持身份可见
Microsoft 将 header.from 定义为可见的发件人域，将 smtp.mailfrom 定义为信封 邮件来自 域和 header.d 作为 DKIM 签名域（如果存在）。这些字段可能不同。阅读结果时保持他们的关系： SPF 一个域的通行证不会自动建立 结盟 与可见的发件人，并且DKIM通行证必须与其描述的签名和域相关联。 Microsoft 身份验证标头字段
DMARC的协议决策涉及与其规则下的可见 From 域的对齐。 Microsoft 复合身份验证以 From 域为基础，同时结合SPF 、 DKIM 、 DMARC等信息。请勿在合规性声明或DNS故障排除结论中将单独的DMARC结果替换为 compauth。他们回答相关但不相同的问题。 RFC 9989 Microsoft 复合字段
一起解读结果和原因
Microsoft 记录了 compauth 值通过、失败、软通过和无，并带有三位数的原因。保留完整的一对。原因代码不是SMTP回复代码，即使其数字类似于另一个诊断也是如此。请勿使用通用SMTP表对reason=130进行解码，也不要从一条消息的值推断租户范围内的条件。使用当前的 Microsoft 表来获取观察到的上下文。 Microsoft 复合身份验证
标头引用将原因 000 描述为具有DMARC失败和隔离或拒绝策略的显式身份验证失败，而 001 涉及已记录的弱或缺少策略情况下的隐式身份验证失败。它将 109 描述为没有 DMARC记录 存在，但消息否则会传递。这些是范围内的供应商定义，而不是制造标头的说明或此处观察到此类消息的证据。 微软原因代码
了解 bestguesspass，无需声明已发布的政策
微软的dmarc=bestguesspass标签表示没有DMARC TXT记录 存在，但如果该域有一个消息就会传递。不得将其报告为域发布了有效DMARC策略或实际标准DMARC评估返回通过的证据。逐字保留供应商标签并解释其有限含义。 Microsoft DMARC字段值
查看此类结果的发件人仍应验证实际的公共策略和预期的身份验证配置。不要假设复合成功消除了对明确域策略的需要或保证其他接收者将做出相同的评估。特定于接收者的启发式或推理不是域已发布控件的便携式替代品。
ARC和隐式信号不会重写底层事实
Microsoft 将原因 130 记录为值得信赖的 ARC sealer 的结果覆盖DMARC失败。这可以解释转发或中介路径中的复合结果，但这并不意味着应从证据记录中删除潜在的DMARC故障。保持原始结果、 ARC上下文、原因和最终处理可区分。不要声称任何任意ARC标头就足够了；记录的案例涉及一个值得信赖的密封者。 微软原因130
同样，微软描述了其他隐式信号，并指出复合故障不会直接导致阻塞。尽管出现故障，总体评估仍然可以允许邮件发送，而其他保护技术可以识别经过身份验证的邮件中的风险。因此， compauth=pass 并不能保证收件箱放置或内容安全，并且 compauth=fail 本身也不能证明拒绝。 微软处理说明
建立标头信任边界
从相关接收者处获取经过授权的原始消息，并确定哪个受信任的系统产生了结果。 RFC 8601解释了原因 Authentication-Results 断言需要信任边界。消息路径中可以出现多个标头，不受信任的发件人可以插入看起来权威的文本。在没有追踪出处的情况下，不要选择最符合所需结论的事件。 RFC 8601
保留一份未动过的原件以供内部验证，并保留一份单独的经过编辑的解释性副本。更改地址或签名内容可能会阻止独立的加密重新验证，因此请相应地标记副本。注释可以保留身份关系以供讨论，但它不是新近可验证的原始消息。如果接收者需要更有力的证据，请使用经过批准的安全传输流程，而不是默默扩大披露范围。
原始综合结果工作表
以下建议的工作表使现场解释可重复。它没有填充真实的消息，因此不应将其视为完整的身份验证分析。
- 证据来源：接收消息参考、接收者、时间戳和可信验证者。
- 可见身份： header.from 及其与业务发送者的关系。
- SPF ：准确的结果、smtp.mailfrom 和观察到的源上下文。
- DKIM ：每个相关签名和相应 header.d 的结果。
- DMARC ：准确的供应商字段值和单独验证的策略上下文。
- Composite：compauth 值、三位数原因并引用 Microsoft 定义。
- 中介：转发、可信ARC或其他实际可用的路由证据。
- 结果：观察到的处理、无支持的结论和需要的下一个证据。
不要组合不同消息的结果来创建综合全通记录。成功的直接传递样本和转发的失败样本可以揭示路由差异，但每个样本都需要自己的身份和时间戳。当字段或原始消息不可用时保留未知数。
虚构示例：推断的成功被误认为是政策部署
虚构的 Seabright Desk 看到一份假设报告，其中包含dmarc=bestguesspass和 compauth=pass reason=109.拟议的审查解释说，记录的含义并未建立已发布的DMARC记录。邮件所有者仍会检查实际策略并确认预期部署，而不是仅根据复合结果将域标记为完整。
此工作中不存在 Seabright Desk 标头、 DNS应答或租户结果。这些值仅用于说明 Microsoft 记录的解释，而不是作为捏造的验证证据。真正的分析需要原始消息和可信源上下文。
该目录需要当前的 Microsoft 字段定义和经过编辑的原始消息示例。这些定义是基于来源的，但缺乏原始消息证据。原始证据、人类 SME、来源适用性、生产路线、视觉可达性和所有者发布仍然开放。本草案是一份解释指南，而非经过验证的租户评估。