一封伪造的"PayPal 支持"邮件可以通过你被告知要信任的每一项安全检查

是的，一封欺骗性邮件可以通过 DMARC，同时发件人一栏显示"PayPal 支持"或"Chase 欺诈部门"。每个人都引用的三字母协议——SPF、DKIM、DMARC——只验证发送域和密码签名。显示名称是人类可读的部分，是你目光最先落在的地方，从未被检查过。信任徽章保护的是没人看的字段。

伪造的邮件真的能通过 DMARC 并显示伪造的发件人名称吗？

可以，原因深深植入了这个标准。RFC 7489（DMARC 规范）明确指出它只涉及"RFC5322.From"标头中的域——@ 符号后的部分。它对显示名称（出现在地址前的自由文本标签）只字未提。所以，攻击者如果控制一个普通域名，比如 support-team-alerts.com，设置正确的 SPF 和 DKIM 记录，并从 billing@support-team-alerts.com 发送，就会获得干净的 DMARC 通过。他们只需把显示名称设置为"PayPal Service"。技术上完美的身份验证。完全不诚实的呈现。

大多数邮件客户端则让情况更糟。特别是手机，它显示友好名称，完全隐藏地址，直到你点击它。你看到"PayPal Service"；真实的 support-team-alerts.com 隐藏在你永远不会按下的箭头后面。

那么 DMARC 到底在检查什么？

DMARC 检查发件人标头中的域是否与发件人被授权使用的域相匹配——仅此而已。SPF 确认发送服务器的 IP 在域的批准列表上。DKIM 添加绑定到域的密码签名。DMARC 的工作是"对齐"：它确保 SPF 或 DKIM 验证的域与可见的发件人域匹配，这样你就不能在 evil.com 上通过身份验证而声称是 paypal.com。

这确实很有用。这就是为什么大品牌的彻底域名冒充变得更难了，也是为什么 Google 和 Yahoo 在 2024 年 2 月开始要求大量发件人使用 DMARC。但行业组织 M3AAWG（编写发件人身份验证指南）明确指出，这些协议对域进行身份验证，而不是对意图或措辞进行身份验证。信封可以是真的，而信息是谎言。

为什么显示名称逃过了检查？

因为电子邮件是在有人想象它会转移资金之前构建的，显示名称被设计为友好的，而不是经过验证的。它是一个礼貌标签。没有注册表说明谁可以自称"Apple Billing"，没有商标检查，什么都没有。你可以把你的设置为教宗。邮件标准把它当作装饰，所以身份验证步骤直接跳过它。

这也是一类不断增长的诈骗的运作方式：显示名称欺骗与看起来合法的山寨域名配对。FBI 的互联网犯罪投诉中心在 2023 年记录了超过 $2.9 billion 的商业电子邮件入侵损失——而 BEC 严重依赖这个技巧，即在一个目标从不仔细检查的地址上放一个看起来可信的名字。所有协议都通过了。钱还是走了。

现在你实际上应该如何阅读发件人一栏？

停止读名字，开始读地址。在桌面上，悬停或点击以展开完整的 user@domain，问一个问题：这是真实公司使用的域吗，一个字母一个字母？PayPal 从 paypal.com 发送，而不是 paypal-secure.net 或 service-paypal.com。在手机上，在点击其他任何东西之前，点击发件人以显示地址。

然后进行第二次检查：这个组织会用通用问候语来称呼你，并推你点击登录链接而不是因你没想到的需求而要求吗？这是没有标头能够验证的部分。这也是 AI 过滤展现其价值的地方——像 xmail 的诈骗标记这样的工具比较显示名称和验证域，显示不匹配之处，而不是像你的眼睛那样信任友好标签。DMARC 通过告诉你域名就是它所说的那样。它永远不会告诉你这个名字是。