[ DNS和域名 ]

用于电子邮件身份验证的DNS记录和所有者

在更改SPF 、 DKIM或DMARC之前,将每个身份验证身份映射到其确切的DNS所有者、记录类型和负责的操作员。

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

[ 要点 ]

  • 从实际协议身份中派生SPF 、 DKIM和DMARC问题。
  • 确认委托的权限,而不仅仅是注册商或熟悉的DNS控制台。
  • 保留TXT记录边界并将别名与区域委派区分开来。
在此页面上

从接收者将检查的身份开始

电子邮件身份验证更改从名称开始, 一个记录 类型和负责的操作员。 “向我们的域添加身份验证”过于宽泛,无法识别正确的DNS编辑器或接收者所需的答案。营销服务可以使用一个域进行签名,使用另一个域作为其SMTP信封,并在“发件人”字段中显示第三个域。在任何人编辑区域之前,清单应该保留这些差异。

为了 SPF,获取SMTP使用的域名 邮件来自 身份;这 HELO身份 有自己的检查,包括空反向路径情况。查询TXT的适用域。不要仅通过读取可见的发件人地址来选择SPF所有者。 RFC 7208 ,第 2.3–2.4 节和 3.1 节.

为了 DKIM,取 选择器 从 s= 和签名域来自 d= 在签名中。键查找名称是selector,那么 _domainkey,然后是签名域。为了 DMARC,策略发现从下面的TXT查询开始 _dmarc 位于作者域并可以继续使用指定的 DNS树遍历。缺少初始记录本身并不表明政策不适用。 RFC 6376 ,第 3.6.2 节; RFC 9989 ,第 4.5 和 4.10 节.

将所有者姓名与拥有变更的人员分开

在DNS中,记录的所有者是域名。在变更票中,其所有者通常是个人或团队。记录两者。域名注册商、权威DNS主机、发送平台管理员和批准域名所有者可以是不同的各方。注册访问并不是特定DNS控制台控制当今公共答案的证据。

识别包含所请求名称的区域的委派权威服务器。子域可能有自己的委托,因此正确的编辑器可能与父域的编辑器不同。将区域、完整所有者名称、请求的类型、建议的数据和负责的操作员保存在一起。 DNS委派定义权限更改的位置;它不遵循组织的支持团队界限。 RFC 1034 ,第 4.2 和 4.2.1 节.

要求发件人管理员提供帐户颁发的值并解释所有别名。供应商的 CNAME 指令将一个名字指向另一个名字;它与用 NS 记录委派子区域的操作不同。捕获谁维护别名目标以及谁可以更改客户端记录。

阅读已发表的记录集而不是编辑的外表

DNS控制台通常接受相对主机标签并附加区域名称。因此,以错误模式输入的复制的完全限定名称可能会落入非预期所有者手中。验证最终的绝对名称,包括每个子域和下划线标签。编辑的保存价值是准备证据;权威的DNS答案是发布证据。

TXT演示也需要小心。一条TXT资源记录可能包含多个字符串。对于SPF这些字符串连接在一起而不插入空格。这与发布两个单独的 SPF记录 属于同一所有者,这是禁止的。在查看导出或屏幕截图时保留记录边界,而不是计算引号。 RFC 1035 ,第 3.3.14 节; RFC 7208 ,第 3.2–3.3 节.

MX记录 识别用于接收邮件的邮件交换器。他们不独立​​证明哪个出站服务被授权或哪个密钥签署消息。 SPF策略可以通过某种机制引用MX ,但该关系必须来自实际策略,而不是来自所有与邮件相关的DNS记录都验证发送的假设。 RFC 1035 ,第 3.3.9 节; RFC 7208 ,第 5.4 节.

处理虚构的所有权清单

假设一个虚构的服务发送带有 From 的邮件 news@example.com, 邮件来自 bounce@mail.example.com,和一个 DKIM签名 含有 d=example.com; s=nov26。初始清单包含三个独立的TXT问题: mail.example.com, nov26._domainkey.example.com, 和 _dmarc.example.com。这些是说明性名称和标识,而不是观察到的消息或建议的生产值。

电子邮件管理员确认预期的路由和选择器。 DNS管理员检查哪个区域包含每个名称以及是否有任何提供商所需的别名更改了查找路径。域所有者批准范围。如果选择器是由厂商发布的,则厂商必须保留相应的私钥;只有公钥材料才属于DNS 。绝不能将私钥复制到票证或公共TXT记录中。

库存行应区分“由服务提供”、“存在于权威DNS中”和“在收到的邮件中观察到”。让其中一列未知比过早检查单个“经过身份验证”的框更有用。

在结束变更之前收集证据

提议的检查是 挖掘@AUTH_IP nov26._domainkey.example.com 。 TXT +norecurse 和 挖掘@RESOLVER_IP nov26._domainkey.example.com 。 TXT。将大写占位符替换为批准的端点。对每个实际所有者和相关权威服务器重复此操作。保留 UTC 时间、服务器地址、问题、响应代码、标志、答案和权限部分、TTL 和任何别名链。本文中尚未执行这些命令。

如果权限和递归不一致,请在添加重复记录之前调查发布一致性、缓存和解析器路径。 DNS应答仍然无法证明签名已验证、 SPF授权实际发送 IP 或DMARC对齐。使用受控接收消息和可信接收者结果来结束这些问题。带时间戳的权威和递归记录仍然是这份纪录片草稿的开放原始证据之门。

[ 外卖 ]

将协议身份、 DNS所有者名称和责任运营商保留在一起,然后分别验证发布和接收的邮件。

[ 按角色 ]

这对您意味着什么

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

DNS管理员

验证实际发布点

请求的所有者可以位于委托的子区域中或指向提供者控制的目标。

后续步骤

  1. 编辑前记录完整的所有者、类型、区域和操作员。
  2. 保留相关权威服务器的答案并识别别名。

电子邮件平台所有者

从发送工作流程提供身份

服务的信封域和DKIM选择器确定不同的DNS问题。

后续步骤

  1. 提供实际的 MAIL FROM 域和预期的d=/s=对。
  2. 将发布的配置与接收到的消息观察分开。

安全审查员

批准有界身份验证更改

已发布的记录是一种依赖性,并不能证明发送者已对齐或可以安全发布。

后续步骤

  1. 检查没有私钥进入DNS或票证。
  2. 审查受控消息并保留未解决的身份差距。

[ 常见问题解答 ]

常见问题

如果发件人地址是news@example.com ,我应该查询哪个域的SPF ?

使用适用的SMTP MAIL FROM 身份中的域,以及包括空反向路径情况的HELO规则。仅可见的发件人地址并不能识别SPF查询所有者。

如何构建DKIM查找名称?

获取签名的 s= 选择器和 d= 签名域,然后查询选择器。 TXT的_domainkey.signing-domain 。不要假设每条消息都使用旧设置票证中显示的选择器。

注册商一定是可以更改TXT记录的人吗?

否。确定该区域的委托权威服务以及管理该服务的运营商。注册和DNS托管可以由不同的服务处理。

MX记录能否证明出站平台是授权的?

不会MX标识接收邮件交换器。 SPF策略可以显式使用 mx 机制,但单独的MX发布并不是出站身份验证。

TXT中的两个带引号的字符串是否对应两个SPF策略?

未必。一条TXT记录可以包含多个字符串, SPF将这些字符串连接起来而不添加空格。在确定是否存在重复的SPF策略之前保留资源记录边界。

提供商CNAME指令是否委托整个DNS区域?

不会CNAME在名称上建立别名。 NS 记录建立区域委派。记录别名目标的操作员,而不将别名视为区域权限的转移。

第一个_dmarc名称中没有TXT是否意味着DMARC策略不适用?

不是靠它自己。当初始查找未找到有效的策略记录时, RFC 9989策略发现可以继续进行DNS树遍历。

完成库存的证据门还需要什么?

针对每个确切所有者和类型的原始时间戳权威和递归答案,以及帐户适用性和受控接收消息结果。示例库存是虚构的。

[ 来源 ]

来源

  1. RFC 1034 :域名:概念和设施
  2. RFC 1035 :域名:实施和规范
  3. RFC 6376 :域名密钥识别邮件签名
  4. RFC 7208 :用于授权在电子邮件中使用域的发件人策略框架
  5. RFC 9989 :基于域的消息身份验证、报告和一致性

[ 词汇表 ]

词汇表

DNS所有者名称
DNS资源记录所属的域名,与负责更改该记录的人员不同。
选择器
DKIM s= 值与签名域一起使用来定位_domainkey下的公钥记录。
邮件来自身份
其域通常提供SPF策略查找的SMTP信封标识;空反向路径处理使用基于 HELO 的身份规则。
作者域
消息的RFC5322域。DMARC 用于DMARC发现和对齐评估的发件人地址。
TXT字符串
TXT资源记录中的一个长度分隔字符串;多个字符串可能属于单个记录。

企业出处

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

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

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

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

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

知识库