[ DMARC和政策 ]

如何向发件人请求足够的证据来诊断DMARC

要求提供安全的代表消息、相关身份、可信接收者结果和实际路线,而无需收集不必要的客户数据或凭据。

由EmailAuth研究团队提供

[ 要点 ]

  • 首选通过受影响的工作流程进行非敏感复制。
  • 保留相关身份、可信结果和准确时间。
  • 将分类摘录与未经修改的签名证据分开。
在此页面上

最快有用 DMARC 证据请求要求提供一条代表性消息、产生该消息的路由以及接收系统的结果。截图显示“SPF 通过”或“域已验证”通常会省略解释失败所需的身份。

请求能够区分身份验证问题的最小证据集, 结盟 问题、 DNS问题和传送问题。仅当存在特定不确定性时才扩展请求。这减少了不必要的客户内容暴露,并为发送者提供了他们实际上可以完成的任务。

首先要求安全繁殖

在可行的情况下,让应用程序所有者通过受影响的生产工作流程向授权测试接收者发送非敏感测试消息。工作流程很重要:提供商控制台中的测试按钮可能会使用与发票、密码重置或计划通知不同的发件人或路由。

记录内部使用的应用程序、客户帐户或租户参考、触发操作、UTC 发送时间、预期接收系统以及是否涉及转发或网关。消息标识符可以帮助关联日志,但只能通过商定的支持渠道共享。请勿请求密码、私人签名密钥、API 凭据或不相关的邮箱导出。

将最初的请求集中在技术问题上。如果故障涉及真实客户的消息,请在与另一方共享其内容之前使用批准的处理和访问控制。

保存区分身份的证据

要求提供在受影响的目标处收到的原始消息,或保留相关标头的收件人端诊断导出。有用的字段包括可见的发件人域、可用的信封标识、相关的 DKIM 签名和接收系统的 Authentication-Results.

接收操作员必须确定哪个结果是可信的。仅标题文本就可以被伪造或从不受信任的来源携带; RFC 8601 §1.2 和 RFC 8601 §7.1 解释信任边界要求。如果存在多个Authentication-Results字段,请不要假设最上面的 pass 是自动权威的。

对于初始分类,管理员可以提取相关的身份和结果字段,同时安全地保留原始字段。这与以加密方式重新验证DKIM不同。编辑签名标头或正文可能会使签名无效,因此经过编辑的副本不一定能重现原始验证。如果需要独立重新验证,请安排对未修改样本的受控访问或生成安全的新测试。签名敏感的处理如下 RFC 6376 §3.4 和 RFC 6376 §3.7.

您可以调整的最低要求

使用以下内容作为操作模板,而不是作为披露凭据的请求:

“请通过受影响的工作流程发送非敏感测试并提供:

  • 应用程序和确切的工作流程、UTC 格式的发送时间以及路由是否包括转发或网关。
  • 通过我们批准的支持渠道收到的原始邮件,或收件人管理员从域中提取的、SPF 评估的身份和结果、每个相关的DKIM d= 和 s= 值和结果,以及可信的DMARC结果。
  • 交付失败时的确切拒绝响应,包括哪个系统返回了它。如果不存在收件人消息,请提供发件人端跟踪详细信息。
  • 此特定工作流程使用的身份验证设置以及提供商对其支持的客户域配置的当前说明。
  • 任何最近的DNS 、密钥、网关或发件人地址更改及其时间戳。

请勿包含帐户密码、API 密钥、 DKIM私钥或不相关的客户记录。如果可能需要签名验证,请保留原始样本不变。”

此请求创建一个公共参考点。它并不假设供应商的共享基础设施或熟悉的源 IP 证明您的组织已授权发件人。

将每个答案与诊断问题相匹配

在提出更改建议之前先建立一个小型证据工作表。

  • 证据:来自领域;问题回答: DMARC正在评估哪个作者域?
  • 证据: SPF结果和评估范围;它回答的问题是: SPF是否通过了与该路由相关的身份?
  • 证据: DKIM结果, d= 和 s=;询问它的答案:验证了哪些签名身份以及使用了哪些密钥?
  • 证据:适用的政策和调整模式;它回答的问题是:传递的身份是否符合相关规则?
  • 证据: SMTP响应或最终处置;问题回答:交付到底发生了什么?
  • 证据:更改时间戳和当前DNS观察结果;它回答的问题是:配置时序可以解释不同的观察结果吗?

身份和对齐检查如下 RFC 9989 §5.3.3, RFC 9989 §5.3.4 和 RFC 9989 §5.3.5。工作表和请求格式是实用的建议。

明确处理缺失的证据

如果发送者仅提供其控制台状态,则要求从实际工作流程中获取收到的样本。如果收件人在接受邮件之前拒绝,请确认可能不存在最终的邮箱副本。使用发件人的出站跟踪、拒绝响应和接收操作员的可用日志。

如果当前DNS与消息的时间戳不同,请勿声称它证明了先前接收者所看到的内容。要求更改历史记录或新的受控再现。如果提供商无法提供受支持的一致身份,请记录该能力差距和受影响的工作流程,而不是发明DNS值。

通过前后身份比较、确切的变化和新的可信结果来完成调查。将该证据链接到 发件人库存。这 对准失败指南 有助于解释它,同时 报告隐私指南 支持有关保留证据的决定。

明确下一步的决定

如果仅存在控制台屏幕截图,请将评估的SPF域、对齐的DKIM身份和接收者信任边界标记为缺失。请求这些字段而不是声明DNS修复。如果拒绝阻止了邮箱传送,请改用SMTP响应和发件人跟踪。与以后的DNS检查分开记录每个观察的时间戳;这里没有收集或验证原始消息。

[ 外卖 ]

首选通过受影响的工作流程进行非敏感复制。保留相关身份、可信结果和准确时间。将分类摘录与未经修改的签名证据分开。

[ 按角色 ]

这对您意味着什么

选择您的角色以执行后续实际步骤。

IT/邮件管理员

保留区分身份所需的内容。

收集原始接收上下文、发件人、 SPF身份、 DKIM域和选择器、可信结果和时间。决定提取的字段是否足够或需要未修改的字节进行验证。

后续步骤

  1. 记录接收者信任边界。
  2. 将经过编辑的分类副本与原件分开。
  3. 当不存在接受的消息时使用发件人跟踪。

CISO / SecOps

对事件证据进行最少的披露。

身份验证故障排除很少需要凭据或不相关的客户邮件。为包含私人内容的样本设置批准的渠道、访问和保留。

后续步骤

  1. 更喜欢非敏感繁殖。
  2. 禁止共享私人签名密钥和帐户机密。
  3. 保持原始证据受控且可追溯。

创始人/非技术人员

让应用程序所有者轻松提出证据请求。

要求提供实际客户工作流程的安全再现以及可以解释提供商帐户的指定联系人。避免广泛的邮箱导出,这会延迟诊断并暴露不相关的信息。

后续步骤

  1. 列出损坏的工作流程及其业务影响。
  2. 提供授权的测试接收者。
  3. 将请求仅限于相关证据。

[ 常见问题解答 ]

常见问题

显示SPF通过的屏幕截图是否足够?

通常不会。它可能会省略解释DMARC所需的评估域、From 域、 DKIM签名、对齐模式和可信接收系统。

RFC 9989 §5.3.3 RFC 9989 §5.3.4 RFC 9989 §5.3.5

我们应该请求原始消息还是新的测试?

在可行的情况下,首选通过受影响的工作流程进行非敏感复制。如果必须分析原始事件,请在批准的访问控制下保留其未经修改的证据。

我们可以在重新检查DKIM之前编辑消息吗?

密文可能会改变签名的标头或正文并使验证无效。使用提取的字段进行初始分类,并控制对未修改样本的访问或安全复制以进行重新验证。

RFC 6376 §3.4 RFC 6376 §3.7

哪些DKIM值在初始请求中很重要?

请求相关结果,签署 d= 域和 s= 选择器。签名域用于对齐;选择器找到钥匙的位置。

RFC 6376 §3.5 RFC 9989 §4.4.1

如果收件人在接受邮件之前拒绝了怎么办?

最终的邮箱副本可能不存在。请求发送者跟踪、准确的拒绝响应和可用的接收系统日志,而不是坚持不可能接收到的样本。

发送者应该提供 API 密钥还是私人签名密钥?

不可以。这些秘密对于此诊断请求来说是不必要的,并且不应共享。改为询问支持的配置详细信息和公共DNS观察。

我们如何知道应该信任哪个身份验证结果?

要求接收管理员识别验证系统和可信边界。不接受来自转发或不受信任标头的任意传递文本。

RFC 8601 §7.1

什么证实了提议的修复?

通过相同的工作流程发出新的受控消息,并将可信结果、相关身份比较和确切的配置更改记录在一起。

[ 来源 ]

来源

  1. RFC 9989

    部分 §4.4.1 · §5.3.3 · §5.3.4 · §5.3.5 · §3.2.2

  2. RFC 6376

    部分 §3.4 · §3.5 · §3.7

  3. RFC 8601

    部分 §1.2 · §7.1

[ 词汇表 ]

词汇表

DMARC
一种评估传递的经过身份验证的标识符是否与适用策略下的作者域一致的机制。

RFC 9989 §5.3.5

作者域
消息 From 标头字段中的域,用作DMARC参考标识。

RFC 9989 §3.2.2

企业出处

为什么顶级金融机构和政府 退役了他们的电子邮件安全仪表板。

传统的电子邮件身份验证平台会向您出售仪表板并要求您的工程师来完成这项工作。在高风险环境中,手动监督意味着延迟执行、配置漂移和不受监控的影子域。

EmailAuth是代理电子邮件来源平台。 我们的代理人强制执行 p=reject,保持第三方发件人一致并将您的域名移至完整状态 RFC 9989 合规性、新的DMARC标准,以及人机交互审核能力。

政府 大型企业 一级金融机构

SaaS · 专用租赁 · 气隙本地部署 · BYOK 加密

知识库