[ DMARC和政策 ]

DMARC和收件箱放置:了解边界

单独的身份验证、交付接受、文件夹放置和参与,因此DMARC通行证用作证据而不是收件箱保证。

由EmailAuth研究团队提供 · 6 分钟阅读

[ 要点 ]

  • 单独的身份验证、 SMTP接受、放置和参与。
  • 隐私和自动化活动可能会扭曲打开和点击指标。
  • 在将更改归因于DNS之前,请使用可比较的接收者证据。
在此页面上

在下面 RFC 9989 §5.4, a DMARC pass 不保证收件箱的放置。它为消息建立对齐的域身份验证结果。接收服务仍然可以出于其他原因拒绝该消息、将其接受为垃圾邮件、将其放入收件箱或稍后应用特定于用户的处理。

这个界限很重要,因为错误的诊断会导致错误的改变。 DNS无法修复不同意、持续投诉或不需要的内容。相反,声誉工作并不能修复未对齐的身份验证路径。

分离交付阶段

使用四种不同的测量值:

  • 阶段:认证;问题: 做了吗 SPF 或者 DKIM 通过,并且至少有一个通过的身份与 From 一致吗?
  • 阶段:验收;问题:接收服务器在SMTP期间是否接受了邮件?
  • 阶段:安置;问:接受后,接收者将消息放置或暴露在哪里?
  • 阶段:订婚;问题:接收者做了什么?该测量的可靠性如何?

数据结束后的肯定SMTP完成在中指定 RFC 5321 §4.2.5。消息可以通过身份验证,也可以失败接受。它可以被接受并放入垃圾邮件中。它可以到达收件箱,但不会收到任何有用的参与。不要将所有四种结果都描述为可交付性。

阅读虚构的诊断表

以下情况是综合的。它们说明了如何在不声称观察到的表现的情况下选择下一个调查。

  • 观察: DMARC ;情况A:通过;情况B:通过;案例C:失败
  • 观察: SMTP ;案例A:接受;案例B:接受;情况 C:拒绝与身份验证相关的响应
  • 观察:安置;情况A:垃圾邮件;情况B:收件箱;情况 C:没有可用的交付副本
  • 观察:投诉或接收者信号;案例A:投诉增多;情况 B:对于定义的队列来说正常;情况 C:不适用于被拒绝的消息
  • 观察:下一个焦点;案例A:同意、期望、声誉、内容和发送模式;案例B:继续监控可比流量;案例 C:身份链、签名、 SPF路径和提供商响应

在情况 A 中,将DMARC从无更改为拒绝并不能解决不需要经过身份验证的邮件的原因。调查列表来源、禁止、频率、内容和提供商反馈。在情况 C 中,在了解与身份验证相关的拒绝之前,收件箱测试无法开始。

使用身份验证作为先决条件,而不是声誉捷径

邮箱提供商向发件人发布要求和建议,例如 Google 针对个人Gmail收件人的指南。这些要求可以包括SPF 、 DKIM 、 DMARC 、有效的DNS 、传输实践、投诉控制和轻松取消订阅适用的流量。满足一项要求并不意味着放弃其他要求。

身份验证很有价值,因为它可以创建稳定的域身份并帮助收件人确定邮件的归属。它不购买声誉、证明接受者同意或保证优惠待遇。声誉和分类决策是特定于接收者的,并且可能因流量、接收者和时间而异。

请勿从同时发生的DNS更改和位置更改推断因果关系。发送程序可以同时改变音量、受众、内容和基础设施。在得出结论之前记录干预措施并比较同类群组。

根据相关接收者的证据进行诊断

从指定边界内的实际SMTP响应和可信身份验证结果开始 RFC 8601 §7.1。如果消息被拒绝,代码和随附文本可以识别类别,但代码本身并不能提供完整的诊断。需要提供者文档和发送日志来解释它。

如果消息被接受,请使用可用的提供商遥测、具有规定限制的种子测试、收件人报告和受控活动数据。测试邮箱是有关该邮箱和邮件的证据,而不是对每个收件人的通用预测。

对于身份验证,记录 From、评估的SPF身份、每个DKIM d= 域、 结盟 以及适用的政策。对于程序的健康状况,记录流量、数量、投诉信息、抑制行为、列表来源、内容更改和时间安排。

谨慎对待参与度指标

打开率并不是收件箱放置或人工注意力的可靠独立指标。 Apple 的邮件隐私保护 无论参与程度如何,都会在后台下载远程内容。 Mailchimp的开放式跟踪指南 还记录了被阻止的跟踪图像和客户端格式限制。单击还可以包括自动安全扫描,如中所述 Mailchimp的机器人活动指南.

定义人口和测量方法。结合交付响应、投诉、取消订阅行为、提供商证据和业务成果。避免在没有可比基线和对混杂变化的解释的情况下声称一项指标有所改进。

避免针对错误问题的DNS更改

请勿添加其他SPF包含内容,因为经过身份验证的营销活动会进入垃圾邮件。不要削弱对齐以追逐放置。请勿重复发布 SPF记录。不要仅仅因为测试邮件到达收件箱就拒绝。

DNS更改应该解决已证明的身份或策略问题。发送实践的改变应该解决同意、频率、内容、分段或声誉问题。有时两个工作流都是需要的,但它们应该保留单独的所有者和证据。

建立联合诊断记录

有用的案例记录包含:

  1. 确切的发件人,来自域和流量;
  2. 具有代表性的消息和可信的身份验证结果;
  3. SMTP响应和时间戳;
  4. 观察安置的方法和限制;
  5. 该群体的投诉、压制和接受者证据;
  6. 最近的技术和计划变更;
  7. 假设、所有者、干预和审查日期。

这种格式提出了“ DMARC是否修复了送达能力?”的问题。转化为可测试的问题。身份验证是否有所改善?接受度有变化吗?类似邮件的放置位置是否发生变化?在不改变受众的情况下,收件人的反应是否有所改善?

对于身份证明,请使用 电子邮件身份链指南。对于监控基线,请继续 DMARC监控策略指南.

将结论保留在证据范围内

对于案例 A,保留经过验证但属于垃圾邮件的观察结果并调查所述投诉证据;对于案例 C,在调查收件箱放置之前保留实际拒绝。比较相同的测量方法和不同变化的队列。自动打开或点击并不能证明是人类行为。这些案例都是虚构的,并非竞选衡量结果或改进承诺。

[ 外卖 ]

单独的身份验证、 SMTP接受、放置和参与。隐私和自动化活动可能会扭曲打开和点击指标。在将更改归因于DNS之前,请使用可比较的接收者证据。

[ 按角色 ]

这对您意味着什么

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

IT/邮件管理员

首先诊断分娩阶段。

标头、 SMTP响应和提供商证据指向不同的所有者和补救措施。

后续步骤

  1. 捕获可信的身份验证结果。
  2. 保留完整的SMTP文本和时间戳。
  3. 将DNS和声誉假设分开。

CISO / SecOps

保持身份保证和通信质量不同。

两者都会影响风险,但合并它们的指标会隐藏控制故障并鼓励不安全的DNS更改。

后续步骤

  1. 按流量设置认证标准。
  2. 分配投诉和同意的所有权。
  3. 使用可比较的证据审查变更。

创始人/非技术人员

不要购买收件箱保证。

身份验证是基础,但可持续的放置还取决于通缉邮件和严格的发送。

后续步骤

  1. 要求团队将接受与安置分开。
  2. 保护同意和接受者的期望。
  3. 要求提供证据来证明所声称的改进。

[ 常见问题解答 ]

常见问题

为什么DMARC可以通过,而邮件却进入垃圾邮件?

DMARC建立一致的域身份验证。提供商还评估声誉、内容、接收者信号、投诉和自己的政策。

RFC 9989 §5.4 Google Gmail发件人指南

通过DMARC能否保证SMTP被接受?

不可以。收件人可以出于其他政策、声誉、内容、技术或安全原因拒绝邮件。

RFC 9989 §5.4

DNS更改可以解决购买列表投诉问题吗?

不可以DNS无法创建同意或接收者兴趣。地址列表来源、期望、抑制和发送实践。

Google Gmail发件人指南

打开率是收件箱放置的可靠衡量标准吗?

不是靠它自己。隐私功能、自动获取、阻止和客户端行为可能会扭曲打开。

Apple 邮件隐私保护 Mailchimp开放跟踪 Mailchimp机器人活动

接受和安置有什么区别?

接受发生在SMTP期间。放置是收件人在接受后执行的操作,例如在收件箱或垃圾邮件文件夹中显示邮件。

RFC 5321 §4.2.5

是否应该削弱DMARC政策以改善安置?

并非没有身份验证或策略缺陷的证据。与域对齐分开诊断放置和发件人实践。

p=none是否要求收件人将邮件放入收件箱?

不需要。它不会请求针对策略失败的 DMARC 特定处理更改,并且可以请求报告。接收者仍然应用自己的过滤。

RFC 9989 §4.7 RFC 9989 §5.4

身份验证更改后应该比较什么?

比较同类流量并记录身份验证、 SMTP接受、放置证据、投诉和其他计划更改。不要将每个动作都归因于DNS 。

[ 来源 ]

来源

  1. RFC 9989

    部分 §4.7 · §5.3.5 · §5.4 · §3.2.2

  2. RFC 5321

    部分 §4.2.5

  3. RFC 8601

    部分 §7.1

  4. Google Gmail发件人指南

    部分 发件人要求和指南

  5. Apple 邮件隐私保护

    部分 无论参与程度如何,后台远程内容下载

  6. Mailchimp开放跟踪

    部分 解决开放跟踪问题:阻止图像和纯文本限制

  7. Mailchimp机器人活动

    部分 工作原理:安全服务膨胀打开并点击

[ 词汇表 ]

词汇表

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

RFC 9989 §3.2.2

SMTP接受
数据传输结束后积极完成交付责任;它不是收件箱放置或阅读的证明。

RFC 5321 §4.2.5

企业出处

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

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

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

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

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

知识库