SPF、DKIM、DMARC 全部通过：攻击者如何滥用 OpenAI 邀请邮件投递钓鱼内容

昨天我打开邮箱，准备查一下我申请的开源项目 OpenAI 赞助申请是否通过，结果却发现了一封高仿 OpenAI 官方邮件的钓鱼邮件。

大家可以看到 邮件发送者是 OpenAI 官方无疑。 但我总觉得很诡异，因为邮件内容是 OpenAI 给我 SuperGrok 的邀请。。。

这他妈可能吗？

于是我让 GPT 5.6 帮我分析原始邮件信息。 得到了下面结论。

P.S. 这个钓鱼信息我已经报告给了 OpenAI 客服。

本文依据原始邮件头与解码后的 MIME 正文，复盘一次对 ChatGPT“可信联系人”邀请功能的滥用：发信链路真实，正文中的商业承诺却来自攻击者控制的输入字段。

一封“怎么看都像真的”邮件

邮件 Date 头记录的发送时间是 2026 年 8 月 7 日 20:53 UTC，即北京时间 8 月 8 日 04:53。

我收到的邮件来自 noreply@tm.openai.com，声称我获邀加入“OpenAI × xAI collaborative workspace”，可以免费使用六个月 SuperGrok Heavy，并提供一个名为 xai-partners[.]com 的激活地址。

这封邮件具备很多让人放松警惕的要素：发件人显示为 OpenAI，邮件使用 OpenAI 品牌样式，正文谈到真实存在的 Grok 产品，甚至还有“限时邀请”制造紧迫感。

但 xai-partners[.]com 并非 OpenAI 或 xAI 公开列出的官方域名。截至 2026 年 8 月 29 日，我也未在双方公开页面中找到为该域名或这项联合活动背书的公告。

OpenAI 官方合作伙伴入口^[1]位于 openai.com 和 partners.openai.com，xAI 的产品入口^[2]则位于 x.ai 和 grok.com。

Verisign RDAP^[3]只能确认该可疑外部域名注册于 8 月 6 日 12:00 UTC，距离邮件发出约 32 小时 53 分钟，不能从公开注册信息确认其实际控制者。

邮件头证明了什么

我随后检查了 Gmail 的“显示原始邮件”。结果与普通仿冒邮件不同：

• SPF：PASS。Gmail 确认投递 IP 获准使用 mandrillapp.com 信封发件域。SPF 在这里认证的是 Return-Path／MAIL FROM，而不是可见的 From: noreply@tm.openai.com。

• DKIM：PASS。邮件带有 d=mandrillapp.com 和 d=tm.openai.com 两份有效签名。

• DMARC：PASS。可见 From 为 tm.openai.com，与通过验证的 d=tm.openai.com DKIM 域名对齐；这里的 SPF 域名并未与 From 对齐。

• Return-Path、Received 链路和 X-Mandrill-User 表明邮件经 Mandrill/Mailchimp 投递。Message-ID 中的 family-api-… 与可信联系人流程相符，但不能单独证明 OpenAI 的内部服务架构。

这些结果可以确认：这不是简单伪造 From 的邮件。收件时，它带有与 tm.openai.com 对齐的有效 DKIM 签名，并经 Mandrill/Mailchimp 投递。

OpenAI 官方文档^[4]也明确列出，noreply@tm.openai.com 用于发送工作区和 GPT 邀请。

结合完整的可信联系人模板、合法的 ChatGPT 操作链接，以及字符串在主题和正文中的一致复用，现有证据更符合“官方功能被滥用”，而不是传输途中篡改或普通域名伪造。

不过，仅凭这一封邮件，不能对 OpenAI 内部基础设施是否还存在其他安全问题作绝对取证结论。

真正的问题不在邮件传输层，而在进入官方模板的用户输入。

攻击者如何把钓鱼文案塞进官方模板

邮件后半部分暴露了它的真实用途：一个陌生账号邀请我成为其 ChatGPT“可信联系人”。

这是 OpenAI 的 Trusted Contacts 功能^[5]，用于在特定安全场景下联系用户预先指定的现实联系人。

结合官方设置流程中的 Name 字段，以及原始 MIME 中各字符串的模板位置，下面是最符合证据的高置信度还原，而不是对攻击者操作日志的直接观察：

1. 邮件结构表明，邀请账号的显示名很可能被设置为“Invitation: SuperGrok Heavy and Grok Build Priority Access”。这个名称随后进入邮件主题和真正的邀请说明。

2. 恶意长文位于模板固定的“Hi”之后，最可能被填入可信联系人的 Name 字段；其中包含疑似钓鱼域名和假冒合作邀请。

3. OpenAI 模板在该字段前自动添加“Hi”，于是收件人首先看到的就是完整钓鱼文案。

4. 攻击者在假签名后加入由 U+200E 与普通空格交错组成的视觉填充。解码后，text/plain 和 text/html 两个 MIME 替代部分各含 3,925 个 U+200E。

   这些零宽字符本身不占宽度，却把普通空格彼此隔开，使邮件客户端不能把整段空格简单折叠，从而制造大量换行机会，把真正的可信联系人说明推到下方。

5. 模板渲染后的邮件经 Mandrill/Mailchimp 投递，最终同时带有 tm.openai.com 与 mandrillapp.com 的有效 DKIM 签名。仅凭邮件头无法进一步确定两份签名分别在哪个内部节点生成。

攻击链可以概括为：

攻击者账号
  → 填写恶意显示名和联系人姓名
  → OpenAI 将用户输入写入可信联系人模板
  → 经 Mandrill/Mailchimp 签名和投递
  → Gmail 验证全部通过
  → 收件人把“官方发信”误认为“官方内容”

这里的字段对应关系，是根据主题、问候语和真实邀请段落进行的高置信度还原。仅凭邮件无法确定攻击者使用了哪个客户端或接口，也无法判断其最初如何获得收件地址。

为什么三项认证全部通过

SPF 判断来源 IP 是否获准使用指定的信封发件域；DKIM 验证签名域以及被签名正文和邮件头的完整性；DMARC 再检查 SPF 或 DKIM 中至少一项是否通过并与可见 From 域对齐。

三者都不判断正文中的商业承诺是否真实。

这里通过验证的 DKIM body hash 表明，恶意文案在 tm.openai.com 签名形成时已经存在，而不是投递后才被普通中间人插入。

认证结果证明：收件时，这份内容已经包含在由 tm.openai.com 域名签署的正文中；它并不为其中的用户可控文案，或者所谓“OpenAI × xAI 免费六个月”活动背书。

这类攻击的危险之处在于，它绕过了用户长期形成的经验：

检查发件域名，看到 SPF、DKIM、DMARC 通过，就说明邮件可信。

这个判断并不完整。

当正规平台允许外部用户控制邮件主题、问候语或大段文本时，平台自身的信誉就可能被借来为钓鱼内容背书。

点击后出现 502，意味着什么

根据我当时的操作记录，点击该可疑外部域名后，页面只返回 502。我没有输入账号、验证码或支付信息，也没有下载文件或批准授权。

原始 HTML 中，该域名只是没有 <a href> 的纯文本；在我收到的 Gmail 界面里，它被客户端自动识别为可点击链接。

该字符串本身不含可信联系人令牌，也不是模板提供的接受操作。结合实际只到达 502、没有出现 ChatGPT 确认页面，目前没有证据表明邀请被接受。最终仍应以 ChatGPT 账户中的邀请状态为准。

502 只表示网站网关或上游服务异常，不能证明网站安全。如果请求到达了对方服务器，对方仍可能记录 IP 和浏览器类型。

该域名与 chatgpt.com 属于不同 origin。正常浏览器的 Cookie 域作用域和同源策略，会阻止前者直接读取 ChatGPT Cookie。

在系统和浏览器已更新，没有输入凭据、运行下载、安装扩展或描述文件、授予权限，也没有触发浏览器漏洞的前提下，一次最终停在 502 的访问，通常不足以成为专门重置 OpenAI 密码的理由。

用户应该如何防范

第一，不要只看发件人和认证结果，还要检查邮件的“业务目的”是否一致。一封可信联系人邀请，不应该突然变成跨公司的免费订阅活动。

第二，独立打开官方网站验证。不要通过邮件按钮进入账号；手动访问 chatgpt.com、openai.com、x.ai 或 grok.com，查看账户内是否真的存在相同邀请。

第三，继续向下阅读。大量空白、不可见字符或异常长的问候语，可能是在隐藏模板原文、法律说明或真正的邀请者身份。

第四，如果已经输入密码，应立即从官方网站修改密码、退出其他会话并启用多因素认证。如果只是打开页面且没有进一步操作，关闭页面、检查下载记录并清除该站点数据即可。

第五，保留原始邮件并举报。邮件头提供了 Mandrill 的滥用举报渠道；同时可以通过 OpenAI Help Center 报告“Trusted Contact invitation field abuse”，让平台定位具体消息和发起账号。

平台可以修补什么

平台侧至少应该做三件事：

1. 限制名称字段长度，过滤 URL、换行和异常 Unicode 控制字符。

2. 让固定的官方说明与真实邀请者身份始终置顶，并明确标注哪些内容由用户提供。

3. 对新账号批量邀请、外部域名和异常长字段进行风控。

邮件模板还应保证官方操作说明始终出现在用户输入之前。

否则，即使 HTML 已经正确转义，没有传统意义上的脚本注入，攻击者仍能利用纯文本、自动链接和视觉填充完成社会工程攻击。

结论

这次事件给出的规则很简单：

把“发信链路可信”和“正文主张可信”分开验证。

前者由 SPF、DKIM、DMARC 回答；后者仍需独立访问官网、核对目标域名，并确认真实邀请者身份。

脱敏说明：本文未公开收件地址、邀请者完整邮箱、邀请令牌、Message-ID 与邮件跟踪参数。

参考资料

• OpenAI：验证官方通信与发件域名^[6]

• OpenAI：ChatGPT Trusted Contacts 功能说明^[7]

• OpenAI：拒绝或移除可信联系人^[8]

• OpenAI Partner Network^[9]

• xAI 官方价格与产品入口^[10]

• Verisign RDAP：可疑域名注册记录^[11]

参考资料

[1] 

OpenAI 官方合作伙伴入口: https://openai.com/business/partners/