DMARC 能防什么,又防不了什么

What DMARC Protects You From, and What It Does Not

DMARC 常被误当作万能防钓鱼工具,但它的设计初衷非常明确:仅验证可见的 From 地址是否经过 SPF 或 DKIM 授权且对齐。它能有效阻止精确域名伪造,却无法识别外观相似的域名、显示名称冒充、已入侵邮箱的合法发送,或是内容恶意的认证邮件。DMARC 不是垃圾邮件过滤器,也不决定邮件是否进入收件箱。盲目启用 p=reject 政策可能带来虚假的安全感,真正有效的防护需要结合监控、修复与人工判断。理解 DMARC 的边界,才能避免被攻击者绕过。

DMARC 能验证的是域名是否授权了这封邮件,但它无法判断邮件内容是否真实或安全。
  1. sam_lowry_

    > 每封邮件都携带两个“发件人”地址

    很多年前我也做过完全相同主题的演讲,但我毫不避讳地将 SMTP 协议(RFC 821 及其后续版本)与邮件消息本身(RFC 822 及其后续版本)区分开来。

    这让 SPF、DKIM 和 DMARC 之间的关联变得清晰得多。

    不过,这篇文章只涵盖了最基础的内容,而且写得晦涩难懂。

    对于那些对现代邮件投递内部机制感兴趣的人……我推荐 Alex Shakhov 在 LinkedIn 上的文章 https://www.linkedin.com/in/alexshakhov/(是的,LinkedIn 上确实还有有价值的内容,只是极其罕见)。

  2. avian

    一个略微相关的问题:如今主流的开源 DMARC 检查实现是什么?我是说检查_接收_到的邮件是否符合 DMARC 规则的那部分。以前大家用的是 opendmarc,但似乎因为历史上频繁破坏性变更以及缺乏良好的维护管理,人们已经逐渐弃用它了 [1]。有人在使用 pydmarc [2] 吗?

    很难找到这方面的可靠信息,因为 99% 的搜索结果都在讨论如何从_发件人_侧配置 DMARC。

    [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1014058#39

    [2] https://pypi.org/project/dmarc/

  3. joladev

    > 这里就是让人困惑的地方。

    当内容明显是 AI 生成时,很难让人认真对待。文章里的信息是否正确,纯属抛硬币猜运气。

同日更多故事

2026-08-03