DMARC 保护您免受哪些威胁，以及它无法保护什么

# DMARC 实际能保护你什么，又不能保护你什么 来源：https://senderledger.com/articles/what-dmarc-actually-protects-you-from DMARC 被要求承担许多它从未被设计来承担的工作。团队把它当作垃圾邮件过滤器、钓鱼邮件过滤器，以及一种通用的信任信号。它其实都不是。当前的 DMARC 协议定义于 RFC 9989（https://www.rfc-editor.org/rfc/rfc9989.html），回答的是一个刻意限定的问题：可见的 `From` 地址中的域名所有者是否授权了这封邮件，并且这种授权能否通过对齐的 SPF 或 DKIM 结果得到确认？这个问题值得回答，但它远比 DMARC 被赋予的名声要狭窄得多。一个团队如果以为设置了 `p=reject` 就能免疫钓鱼，就会跳过那些覆盖 DMARC 无能为力之处的控制措施。 ## 电子邮件如何证明发送者是谁 整篇文章会反复出现三个术语，这里用通俗的话解释一下。**SPF** 是一个已发布的服务器列表，列出一个域名声称允许哪些服务器代它发信；接收方检查邮件是否确实来自其中之一。**DKIM** 是附加在邮件上的加密签名，接收方可以确认邮件确实来自签名域名，且在传输途中未被篡改。DMARC 将两者都关联到一个东西上：**可见的 From** 地址。 每封邮件分两个阶段处理，每个阶段都有自己的“发件人”地址。投递阶段使用一个**信封地址**，就像包裹上写的寄件地址：邮件服务器读取它来路由邮件，收件人永远看不到它。邮件本身则带有**可见的 From**，也就是你的邮件应用显示的名字和地址（例如“Your Bank <[email protected]>”）。这才是人类会阅读并信任的那个地址。 由于这两个地址是独立设置的，攻击者可以把你的银行放在可见的 From 中，而信封地址完全指向别处。SPF 检查的是信封地址；DKIM 的签名携带自己的域名；DMARC 的存在就是为了把通过验证的那一个关联回可见的 From，让认证结果与读者真正能看到的地址对齐。 ### 这些记录实际长什么样 三个技术都以文本记录的形式存放在你域名的 DNS 中，也就是配置网站地址的同一个地方。你不需要记住语法，但能认出它们的形态会有帮助。 一条 **SPF** 记录列出谁被允许发信。下面这条授权了 Google Workspace 和一个营销工具，并表明其他一切来源都应被视为可疑： ``` example.com. TXT "v=spf1 include:_spf.google.com include:sendgrid.net -all" ``` `include:` 条目引入了每个供应商自己的服务器列表，而 `-all` 的意思是“如果不在这些列表里，就不是我们”。 一条 **DKIM** 记录发布签名密钥的公开部分，让接收方可以检查你邮件的签名。长字符串就是密钥本身： ``` selector1._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQ...AB" ``` 最后，**DMARC** 记录把两者联系起来，并告诉接收方当邮件验证失败时该怎么做。下面这条要求接收方拒绝失败邮件并向你发送报告： ``` _dmarc.example.com. TXT "v=DMARC1; p=reject; rua=mailto:[email protected]" ``` 这里的 `p=reject` 就是本文其余部分反复提到的那个策略，而 `rua=` 是你的汇总报告发送到的地址。 ## 通过判定实际是如何作出的 DMARC 建立在 SPF 和 DKIM 之上，并独立评估它们。邮件有两种不同的通过方式：SPF 通过了隐藏信封域名的验证，且该域名与可见的 `From` 域名对齐；或者 DKIM 签名验证有效，且其签名域名与可见的 `From` 域名对齐。只要任意一条对齐路径成功，DMARC 就通过；如果两者都不满足，就失败。 “对齐”Simply put，意思是两个域名匹配程度足够高，可以被视为同一组织。 ``` flowchart TD A[收到的邮件] --> S{SPF 验证通过并与 From 域名对齐?} S -->|是| P([DMARC 通过]) S -->|否| D{DKIM 验证有效并与 From 域名对齐?} D -->|是| P D -->|否| F([DMARC 失败]) ``` 只要 SPF 或 DKIM 中有一个既通过验证又与可见的 From 域名对齐，DMARC 就通过；只有当两者都不满足时才会失败。 对齐是大多数解释跳过的那部分。DMARC 定义了两种对齐模式。在**宽松**模式（默认模式）下，两个域名只需共享同一个组织域名，因此来自 `mail.example.com` 的 DKIM 签名可以与 `From` 为 `example.com` 对齐。在**严格**模式下，两个域名必须完全相同，同一个签名就会失败。 如果你见过“SPF 通过，DMARC 失败”并疑惑两者怎么能同时成立，那通常意味着 SPF 确认了隐藏信封域名是合法的，但该域名与可见的 `From` 地址匹配程度不够，无法对齐。严格与宽松模式随后决定了关系相近的域名是否算作同一个。 注意这个检查从不检查什么：正文、链接、附件，或发送者的意图。它检查的是来源，而非内容。 ## DMARC 在哪些地方有用 DMARC 被设计要应对的场景是精确域名伪造。如果有人把 `your-bank.com` 放进 `From` 地址，却拿不出对齐的 SPF 或 DKIM 结果，`p=reject` 策略会要求参与的接收方拒绝该邮件，不过接收方对如何处理保留最终决定权，并可能应用本地策略或例外情况。这是真实的保护，而且针对这种特定攻击，它是强有力的。 它还给了你一样以前没有的东西：汇总报告（定义于 RFC 9990（https://www.rfc-editor.org/rfc/rfc9990.html））。这些报告会揭示参与接收方观察到哪些系统以你的域名发信，这正是你在攻击者之前发现被遗忘的营销工具或配置错误的转发服务器的途径。 ## 它在哪些地方力有不逮 **相似域名。**攻击者注册 `your-bank-support.com`，配置好合法的 SPF 和 DKIM，在他们自己的域名上通过 DMARC。你的策略对你不拥有的域名没有任何约束力。对每个接收方来说，那封邮件都是完全通过验证的。 **显示名称冒充。**可见名称写着“Your Bank Security”，实际地址却是 `[email protected]`。DMARC 验证的是域名，而不是大多数人真正会读的友好名称。邮件可以照常通过，却仍然是冒充。 **被攻破的邮箱。**当攻击者通过钓鱼凭证登录真实账户，并通过合法供应商发送邮件时，这封邮件通常会通过 SPF、DKIM 和 DMARC，因为按协议的标准，它是通过授权的基础设施发送的。认证无法区分真实用户和掌控该用户账户的攻击者。 **已认证但恶意的域名。**任何人都可以注册一个域名并配置完美的认证；垃圾邮件发送者经常这么做。在 `totally-legit-invoices.com` 上通过验证只说明域名所有者授权了这封邮件，却无法说明该所有者是否诚实。 **垃圾邮件与收件箱投递。**DMARC 不是垃圾邮件过滤器，也不决定邮件能否进入收件箱。过滤器可能把它作为一项输入来考量，但通过认证的垃圾邮件仍然是垃圾邮件，而投递位置是一个有自身逻辑的独立系统。 **转发和邮件列表。**合法的中间环节可能破坏认证。转发通常会破坏 SPF，因为转发服务器并未获得原始发送者域名的授权；邮件列表则可能修改主题或正文，使 DKIM 失效。因此，一封合法邮件可能即使没有人冒充发件人，也会 DMARC 失败。这也是为什么实施强制策略应该先经过谨慎监控和修复，而不是盲目切换到 `p=reject`。 ## 认证不等于信任 一次通过只确认一个事实：`From` 地址中的域名通过 SPF 或 DKIM 并满足对齐条件，授权了这封邮件。这个事实能封死精确域名伪造，并让你看清是谁在以你的名义发信。它不能确认的是这封邮件是否真实，或是否安全到可以据此行动。那些是内容和意图的属性，任何认证检查都无法触及。 暗示 DMARC “阻止钓鱼”的供应商，会让客户暴露在上述每一类风险之下。SenderLedger 的立场刻意更窄：我们帮助你实现在不破坏合法邮件的前提下执行强制策略，证明哪些发件人确实是你的，并封死精确域名伪造。除此之外的一切（相似域名监控、邮箱沦陷检测，以及人的判断）都是另一项工作，假装不是如此，正是许多域名在 `p=reject` 下却带着虚假安全感的根源。 看看谁真正在以你的域名发信。SenderLedger 会映射每一个发件人、跟踪修复进度，并告诉你何时到达 `p=reject` 才是真正安全的。 申请访问权限（https://senderledger.com/request-access）