Defaults.Exposed › 修复 › Guides
Gmail "550-5.7.1 Message Blocked"——解读退信原因并修复（2026）
发布于 2026-07-08
数据截至 2026-06-29 · 方法论 v7。 基于 261 百万个已评分域名的汇总普查数据。参见我们如何评分。
当 Gmail 因为策略原因而不是因为缺记录而拦截一封邮件时，会返回 550-5.7.1：可能是发信方或接收方的策略、没有反向 DNS 的 IPv6 连接，或者是可疑的垃圾邮件。根据 Defaults.Exposed 对 261 百万个域名的普查，在 SPF 中授权了 Google 自家服务器的 12,145,313 个域名里，只有 18.5% 强制执行 DMARC。
550-5.7.1 是 Gmail 最老的一个笼统拒收代码，修法取决于退信里代码后面那句话。以下内容：一张按确切措辞排列的解码表，然后是每种变体对应的修法——策略拒收、没有反向 DNS 的 IPv6 服务器、垃圾邮件或内容拦截——外加人们常和它搞混的相似代码，包括 Google 现在用来处理“DMARC 策略拒收”的 5.7.26 系列（老参考资料曾把这归到 5.7.1 下面）。
Gmail 的 550-5.7.1 到底是什么意思？
在 SMTP 增强状态码方案（RFC 3463）里，每个 5.7.x 代码都表示“永久失败，策略原因”。Gmail 把 550-5.7.1 用作它的旧版策略大类：发件方或收件方的策略拦截、垃圾邮件信誉拦截，以及最让管理员意外的那种变体——邮件通过没有反向 DNS（PTR）记录的服务器经 IPv6 送达。
Google 一直在陆续给各种变体重新编码。“DMARC 策略拒收”（“not accepted due to domain’s DMARC policy”）在 Google 目前的参考文档里现在归在 550-5.7.26 下，不过外面还流传着一些旧退信仍显示为 5.7.1；内容安全拦截现在编码为 552 5.7.0。还有两个近亲常被和 5.7.1 搞混：550-5.7.26，也就是认证要求那一类（它有自己的指南），以及 550-5.7.25，适用于任何 IP 版本的缺失 PTR 代码。不管代码是什么，都以下面的文本为准来解读。
你遇到的是哪种 550-5.7.1 变体？
对照你的退信通知（NDR）里的措辞。Google 会在不同年份调整这些字符串——比对大意，别较真标点。
| 你的退信读起来像… | 意味着什么 | 对应的修法 |
|---|---|---|
| “This message does not meet IPv6 sending guidelines regarding PTR records and authentication.” | 你的服务器经 IPv6 发信，但没有（或不匹配的）反向 DNS | 为 IPv6 地址配 PTR 记录，或者改经服务商的 smarthost 中转（见下文） |
| “The user or domain that you are sending to (or from) has a policy that prohibited the email that you sent.” | 策略拦截——收件方的，或者你自己域名的 | 联系接收方的管理员；如果拦截来自你自己域名的 DMARC，见下文 |
| “This message is likely unsolicited email. To reduce the amount of spam sent to Gmail, this message has been blocked.” | 针对你的内容、IP 或域名的垃圾邮件/信誉拦截 | Postmaster Tools + 名单清理 + 一键退订（见下文） |
| “This message is likely suspicious due to the very low reputation of the sending domain”（或“…sending IP address”） | 信誉拦截——域名或 IP | 同样的信誉修复路径（见下文） |
| “Unauthenticated email from yourdomain is not accepted due to domain’s DMARC policy.”——在 Google 目前的参考文档里编码为 550-5.7.26；旧退信可能仍显示 5.7.1 | 你自己的 DMARC 策略让 Gmail 拒收了一封未认证的邮件 | 找出未认证的来源——不要先放宽策略（见下文） |
| “…blocked because its content presents a potential security issue.”——现在编码为 552 5.7.0 | 内容/策略拦截（附件类型、链接信誉） | 去掉被标记的那类内容；检查链接和附件 |
| 代码是 550-5.7.25，“the sending IP address doesn’t have a PTR record” | 任何 IP 版本上都缺失反向 DNS | 和 IPv6 变体一样的反向 DNS 修法 |
| 代码是 550-5.7.26 | 认证要求这一类，不是 5.7.1 | 见 550-5.7.26 指南 |
| 代码是 421-4.7.0，“Try again later, closing connection.” | 临时延迟——速率或信誉问题，不是永久拦截 | 放慢速度，修好认证和垃圾邮件率；通常会自行清除 |
怎么修复 550-5.7.1 退信？
- 在 defaults.exposed 运行免费扫描——它会在你动 DNS 之前，像外界看到的那样为你的 SPF、DKIM 和 DMARC 评分，并显示你的域名是否可能出现 DMARC 那种变体。
- 对照解码表阅读完整的 NDR 文本——决定原因的是那句话，不是代码本身。
- **DMARC 变体：**找出是哪个发信来源认证失败并修复那个来源（见下一节）。
- **IPv6/PTR 变体：**为服务器的 IPv6 地址配上匹配的反向 DNS，或改经服务商的 smarthost 中转。
- **垃圾邮件/策略变体：**Postmaster Tools、垃圾邮件率控制在 0.10% 以下（Google 的硬性上限是 0.30%）、名单清理、RFC 8058 一键退订。
- 给一个 Gmail 邮箱发测试邮件并重新扫描——确认退信消失、评分也已反映出来。
退信提到了你的 DMARC 策略——为什么这说明你的策略在起作用
Google 目前的参考文档把这个字符串编码为 550-5.7.26，但旧退信和第三方文档里仍可能显示为 5.7.1——不管哪种，机制都是一样的。这话乍看有点绕，其实是这样：Gmail 检查了一封自称来自你域名的邮件，发现既没有对齐通过 SPF，也没有对齐通过 DKIM，查了你的 DMARC 记录，然后照你的要求做了——拒收。你的篱笆起作用了。问题在于篱笆挡住了什么：是一个被遗忘的合法发件方（CRM、开票工具、通讯平台），还是一次真正的伪造。
所以不要第一步就放宽策略。先找出未认证的来源。大多数情况都出在这两个陷阱上：
- SPF 通过了，但通过的是错误的域名。 接收方是对照 Return-Path（RFC5321.MailFrom）域名，而不是 From 标头来检查 SPF 的。以你的名义发信的 SaaS 工具，通常在自己的退信域名上通过 SPF，和你的 From 域名对不上——所以 DMARC 依然失败。详解见 DMARC 失败但 SPF 和 DKIM 都通过。
- DKIM 通过了，但用的是默认签名。 Google Workspace 的
gappssmtp.com和 Microsoft 的onmicrosoft.com默认签名都能验证通过，但和任何域名都对不上齐。见 DKIM 通过但 DMARC 仍然失败。
这种变体比你想的要少见：根据 Defaults.Exposed 普查（2026-06-29），261,086,232 个域名中有 27,640,987 个——占 10.59%——强制执行 quarantine 或 reject 的 DMARC 策略。其余 89.41% 从来不会看到这种退信，因为它们根本没有篱笆可守。修好来源而不是修松策略，完整流程见 DMARC 修复指南。
退信提到了 IPv6 发送准则——反向 DNS 的修法
现代服务器往往默认经 IPv6 连接 Gmail，而 Google 要求连接用的 IPv6 地址要有一条能解析到主机名、且该主机名又能解析回同一地址的 PTR 记录（正反向解析一致）。做不到这点，无论你的 SPF 多干净，每封邮件都会收到 550-5.7.1。
三种修法，按优先顺序：
- 为服务器的 IPv6 地址设置 PTR 记录——这要在 IP 所在的地方完成（你的 VPS 主机商或 ISP 控制面板，而不是你域名的 DNS 区），同时配上一条对应指回来的 AAAA 记录。
- 改经服务商的 smarthost 中转。 如果你没法控制反向 DNS，就把外发邮件路由经过你的邮件服务商或 ISP 的中继，它们已经有合规的反向 DNS。
- 暂时优先用 IPv4 传输，作为权宜之计。 这通常能掩盖症状，因为你的 IPv4 地址有 PTR——这是变通办法，不是真正的修复。有条件时还是要把 IPv6 的 PTR 设好。
退信说“likely unsolicited email”——信誉路径
这种情况下认证可能没问题，但 Gmail 的过滤器不信任这封邮件。认证只是底线，不是天花板——在授权了 _spf.google.com 的 12,145,313 个域名中，只有 8.0% 用严格的 -all 锁死了 SPF，所以单是检查通过说明不了太多问题。（完整对比见哪家邮件服务商的 SPF 默认设置最强。）
信誉检查清单：
- 在 Google Postmaster Tools 注册，盯着垃圾邮件率仪表盘——把它控制在 0.10% 以下，绝不能碰到 Google 大宗发件准则设定的 0.30% 硬性上限。
- 清理你的名单。 去掉不参与互动的地址，以及任何购买或爬取来的地址；只发给主动要求的人。
- 在批量邮件上实现 RFC 8058 一键退订——这是 Google 规则要求的，而且每一次不是点“垃圾邮件”而是点退订，都是在保护你的邮件率。
- 保持认证对齐（SPF 和 DKIM 都用你自己的域名），这样信誉才能积累到你自己掌控的域名上。
常见问题
550-5.7.1 和 550-5.7.26 是一回事吗？ 不是。550-5.7.26 是 Gmail 的认证要求大类（SPF/DKIM 缺失或失败）——Google 目前的参考文档也把 DMARC 策略拒收归到这里。550-5.7.1 是更老的策略大类：收件方和发件方的策略拦截、没有 PTR 的 IPv6、垃圾邮件和信誉拦截。决定用哪种修法的是退信文本，不是那个数字（以 2026-06-29 及 Google 现行准则为准）。
我该把 DMARC 策略调回 p=none 来止住退信吗？ 那等于是拆掉篱笆来止住退信。根据 Defaults.Exposed 普查（2026-06-29），261,086,232 个域名里只有 10.59% 真正强制执行 DMARC；如果你是其中之一，请保留它，转而去修未认证的来源——放宽策略会重新打开精准域名伪造的大门。
我的 SPF 记录在各种检测工具上都能通过，为什么 Gmail 还是拦截我的邮件？ 检测工具测的是记录本身；Gmail 测的是邮件。SPF 是对照 Return-Path 域名评估的，不是对照可见的 From 地址，所以在某个服务商退信域名上的通过，对你的 DMARC 对齐毫无帮助——而信誉拦截根本不看 SPF。免费扫描会显示到底是哪一层出了问题。
550-5.7.1 是不是意味着我的 IP 上了黑名单？ 不一定。Gmail 有自己的一套信誉系统；你可以在没上任何公共黑名单的情况下，仍被 Google 拦截。去 Postmaster Tools 查一下 Google 那边的看法——另外要注意，修好认证能防止未来的损害，但本身并不能重置一个已经很差的发信信誉。
把报告发给老板
退信修好之后，重新运行扫描，把评分报告转发给邮件曾经被拦截的企业负责人或客户。它会用大白话说明哪里坏了、你修了什么、这个域名现在相对于 261 百万域名的基线处在什么位置——这正是保险续保或客户安全问卷里“你们的邮件有没有做认证？”那道题所需要的凭证。悄无声息修好一个退信是看不见的工作；一份前后对比报告才是证据。
检查你的域名 → · Gmail 550-5.7.26——按要求顺序修复 → · 修复 DMARC → · 我们如何评分 → · 仅使用汇总数据。数据在欧盟境内存储和处理。