[ 地区要求 ]

GDPR和DMARC报告:收集、访问和保留

评估DMARC报告字段、处理角色、访问、保留和传输,不要将DNS设置误认为符合GDPR 。

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

[ 要点 ]

  • RFC 9990描述了域级聚合数据,而不是完整消息报告。
  • RFC 9991失败报告可能会暴露内容,需要进行独特的隐私评估。
  • 实际字段、处理者、合法依据、访问、传输和保留尚未得到验证。
在此页面上

在选择控制措施之前确定报告活动的范围

GDPR分析涉及处理活动,而不仅仅是存在 DMARC记录。确定相关控制者或处理者以及活动是否属于该法规的实质和领土范围。根据第 2 条和第 3 条,欧盟的建立和针对欧盟境内人员的某些活动是不同的适用路径。欧洲收件人地址或海外托管地点都不能单独解决这个问题。 GDPR自 2018 年 5 月 25 日起实施; EUR-Lex 条目及其链接的合并文本于 2026 年 11 月 8 日进行了审核。 GDPR主要文本.

描述组织为什么需要报告、谁接收报告、他们支持哪些决策以及消息级证据是否必要。将域安全调查与员工监控、客户分析或不相关的分析分开。可用的报告功能并不能证明其输出的所有可能用途都是合理的。在新的处理安排开始之前,隐私所有者应批准目的和适用的法律依据。

区分聚合字段和消息内容

RFC 9990 使用域级身份验证信息定义聚合报告。其架构包括连接邮件服务器 IP 地址、消息计数、策略评估和作者域标识符;一些信封域字段是可选的。隐私部分将此报告模型描述为排除个人用户地址、个人 IP 地址和消息内容。不要告诉读者,一个合格的 汇总报告 必须包含收件人的完整邮箱或原始邮件。 汇总报告规范.

尽管如此,操作审查必须检查实际的输入和处理。供应商可能会丰富 一个记录、添加帐户信息、保留上传的消息样本或将报告与其他日志合并。隐私问题涉及真实数据集及其可识别性,而不仅仅是标准的预期模式。记录格式错误或意外的字段,而不是默默地将它们视为授权集合。名为 source_ip 的字段应在其报告上下文中进行解释,而不是自动标记单个最终用户的地址。

故障报告 需要不同的评估。 RFC 9991 允许有关失败邮件的详细信息,并解释报告可以公开标头、地址、内容和以前隐藏的转发目的地。其隐私部分敦促控制目的地、最小化和有限的诊断使用。编辑可以减少暴露而不消除所有识别信息。接收者可以限制或拒绝此报告;发布请求并不保证收到。 故障报告规范.

分配合法目的和处理关系

在处理个人数据时,记录所选的第 6 条依据及其支持理由。安全目的不会自动建立同意或合法利益。 EDP​​B 指南描述了对真实、合法利益、必要性的需求,以及在依赖合法利益的情况下与个人权利的平衡。公共当局在执行其任务时不得使用第 6(1)(f) 条进行处理。获得适当的法律评估,而不是从软件菜单中选择基础。 EDP​​B 合法处理指南 和 GDPR第 6 条.

映射各方的实际角色:接收邮件服务、域所有者、报告处理者、支持提供商和任何下游收件人。控制者和处理者的标签取决于谁决定目的和手段以及谁按照谁的指示行事。在适用第 28 条的情况下,处理协议必须规定所需的说明和保障措施。报告邮箱的DNS授权不是数据处理协议或批准不相关的后续使用。

围绕必要性设计访问和保留

第 5 条要求最小化和存储限制,而第 25 条和第 32 条则涉及保护性设计和风险适当的安全性。将这些应用到实际的报告管道:接收邮箱、解析器、仪表板、导出、支持票证和备份。为每个授权角色提供其任务所需的最少信息。对聚合导入进行故障排除的支持工程师不会自动需要未编辑的失败消息附件。 GDPR合并文本.

没有通用的 DMARC 本文提供的保留期限。为每个数据集和目的设定合理的期限,并单独考虑任何法律要求的保存。指定何时进行删除、如何覆盖导出和副本以及由谁验证该过程。在依赖之前,使用安全装置测试批准的行为。界面中显示的保留值并不能证明每个备份或支持附件都遵循该值。

检查转移和高风险收集

记录存储和访问位置、分包商和后续披露。如果第五章适用于转移,负责的审查者必须建立适当的转移路线和保障措施。加密是一种保护,而不是传输评估的自动替代。在没有进一步证据的情况下,欧盟地区标签不会描述所有远程访问或支持处理。 GDPR转让条款.

考虑拟议的操作是否可能产生高风险,需要根据第 35 条进行数据保护影响评估。故障报告内容、规模、敏感信息以及与行为数据集的组合可能会影响该评估。不要声明每个聚合报告部署都受 DPIA 约束,或者免除每个安全工具。在实际的服务设计中,透明度、个人权利和事件处理也需要隐私所有者的关注。

在未经发明批准的情况下准备虚构的实地地图

在虚构的组织中,常规汇总报告会发送到安全仪表板,而偶尔的诊断样本会进入支持队列。拟议的地图将标准聚合字段与可能的完整消息内容分开记录,命名预期接收者,并保留合法基础批准、处理者条款、转移评估和保留接受未填写。本示例未收集任何报告或检查客户数据。

具体的调测需求是:映射实际的报表字段和处理关系,进行隐私审核。该包提供了建议的字段和关系图,而不是实际的部署证据。在提出实施或合规声明之前,所有者必须提供授权样本或架构、经过验证的接收者和合同关系、访问和删除证据以及隐私专家审查。技术中小企业、生产路线、视觉和出版大门也保持开放。没有启用、上传、传输或删除任何报告,也没有断言EmailAuth隐私功能。

[ 外卖 ]

检查实际的报告数据集和处理关系,并分别评估汇总报告和故障报告。

[ 按角色 ]

这对您意味着什么

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

隐私或数据保护专家

确定适用性和合法处理

实际数据集和目的决定分析,而不是报告产品的标签。

后续步骤

  1. 批准范围、法律依据和角色分类。
  2. 检查转移条件以及风险是否需要 DPIA。

消息传递和报告工程师

在扩展集合之前验证字段

标准描述了预期的内容,而实施和支持工作流程可能会添加更多内容。

后续步骤

  1. 与消息样本分开记录聚合字段。
  2. 准备安全访问和删除检查,而无需在此处收集新的个人数据。

采购和服务业主

考虑每个处理方

接收邮箱、仪表板、支持提供商和分包商需要明确的关系图。

后续步骤

  1. 验证说明、服务条款和批准的收件人。
  2. 跨副本和导出分配保留证据和脱离所有权。

[ 常见问题解答 ]

常见问题

发布DMARC是否可以确保GDPR合规性?

不可以。适用性和实际处理活动需要他们自己评估。 DNS设置不批准收集、收件人或保留。

标准聚合报告是否包含完整的收件人邮箱?

RFC 9990描述了域级聚合数据,不包括单个用户地址和消息内容。分别检查实际的扩展、丰富和上传。

source_ip 是否始终是最终用户的个人 IP 地址?

不会。在聚合模式中,它标识连接邮件服务器 IP。必须评估其真实上下文和任何组合数据集,而不是假设单个客户端地址。

为什么要将故障报告与聚合分析分开?

故障报告可以揭示单个消息信息,包括内容。其诊断目的、接受者和保障措施需要单独考虑。

安防监控能自动利用合法利益吗?

不是,利益、必要性、平衡性都需要分析。公共当局在执行任务时不得使用第 6(1)(f) 条。

GDPR是否指定DMARC报告的一个保留期?

所引用的条款要​​求合理的存储限制,而不是通用的天数。定义并验证每个实际数据集和目的的周期。

欧盟托管是否可以消除转会问题?

区域标签不会自动得出结论。根据适用的第五章条件评估实际接收者、支持访问和后续处理。

委托的隐私领域地图完成了吗?

仅提供建议的地图。实际报告样本、处理关系、合同、访问和保留证据以及隐私批准仍然不存在。

[ 来源 ]

来源

  1. EDP​​B:合法处理个人数据
  2. EUR-Lex:法规 (EU) 2016/679 原始法案
  3. EUR-Lex:链接当前合并的GDPR文本
  4. RFC 9990 : DMARC汇总报告
  5. RFC 9991 : DMARC故障报告

[ 词汇表 ]

词汇表

汇总报告
RFC 9990描述的域级统计身份验证反馈,与单个消息样本不同。
故障报告
有关可能会暴露内容和标识符的失败消息的详细反馈。
控制器
单独或共同确定个人数据处理目的和方式的一方。
处理器
代表控制者处理个人数据的一方;实际活动决定角色。
存储限制
根据法规的条件,保留可识别个人数据的时间不得超过适用目的所需的时间。

企业出处

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

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

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

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

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

知识库