Defaults.Exposed › 修复 › Guides
Gmail 550 5.7.26 "The Sender Is Unauthenticated"：按要求顺序排列的修复方案（2026）
发布于 2026-07-08
数据截至 2026-06-29 · 方法论 v7。 基于 261 百万个已评分域名的汇总普查数据。参见我们如何评分。
当你的邮件未通过 SPF 和 DKIM 认证检查时，Gmail 会返回 550 5.7.26。修法是让你发信域名的 SPF 或 DKIM 至少有一项通过——大多数发件方就缺这一步：根据 Defaults.Exposed 对 261,086,232 个域名的普查，在通过 _spf.google.com 授权 Google 服务器的 12,145,313 个域名中，只有 18.5% 强制执行 DMARC。
修法是 DNS 层面的工作，不是提工单：先确认你的发信 IP 有反向 DNS，让 Gmail 实际检查的那个域名的 SPF 或 DKIM 通过，然后让 DKIM 与你的 From 地址对齐，并发布一条 DMARC 记录。以下是完整的要求顺序，外加 550 5.7.26 系列及其相邻代码的解码表。
Gmail 错误 550 5.7.26 是什么意思？
自 Google 2024 年发件方要求生效以来，每一个给 Gmail 发信的发件方——不只是大宗发件方——都必须让发信域名的 SPF 或 DKIM 至少有一项通过。如果两项都失败，Gmail 会在 SMTP 阶段直接以 550 5.7.26 拒收，而不是投进垃圾箱。
目前的完整文本版本是：“This email has been blocked because the sender is unauthenticated. Gmail requires all senders to authenticate with either SPF or DKIM. Authentication results: DKIM = did not pass, SPF [domain] with ip: [ip] = did not pass.” 外面流传的一些旧退信可能仍带着 Google 之前的措辞（“This mail is unauthenticated, which poses a security risk…”），还有一个限速版的近亲——421 4.7.26 This email has been rate limited because it is unauthenticated——原因相同。
550 5.7.26 不是单一一条消息，而是一个代码系列，措辞会告诉你到底是哪条腿失败了：Google 目前的参考文档保留了三种 5.7.26 字符串（未认证、SPF 硬失败、DMARC 策略），并把大宗发件方专属的“仅 SPF”和“仅 DKIM”失败挪到了各自独立的代码 5.7.27 和 5.7.30。动 DNS 之前先把确切文本读一遍——这是你的第一手诊断依据。
这种差距的规模正是这类退信如此常见的原因：全球 138,927,207 个发布 SPF 的域名中，有 12,145,313 个在 SPF 记录里授权了 Google 的邮件服务器，但其中只有 18.5% 有强制执行的 DMARC 策略，只有 8.0% 使用严格 SPF（-all）。大多数托管在 Google 上的发件方，连 Google 自己给大宗发件方定的规则都没达标——而现在 Gmail 已经把这些基本要求套用到所有人身上。
你遇到的是 550 5.7.26 的哪种变体——还是相邻代码？
把收到的退信文本对照下表比对。引用的片段依据 Google 目前的 SMTP 错误参考文档——请一定对照你实际收到的 NDR 核实，因为 Google 会定期修订措辞。
| 代码 | 退信文本大意（片段） | 失败的是什么 | 修法在哪里 |
|---|---|---|---|
| 550 5.7.26（未认证） | “This email has been blocked because the sender is unauthenticated … authenticate with either SPF or DKIM” | SPF 和 DKIM 都没通过 | 本指南第 2–4 步 |
| 550 5.7.26（SPF 硬失败） | “has an SPF record with a hard fail policy (-all) but it fails to pass SPF checks” | 你的严格 SPF 记录没有授权发信的 IP | 下方第 3 步 + 修复 SPF |
| 550 5.7.26（DMARC 策略） | “Unauthenticated email from [domain] is not accepted due to domain’s DMARC policy” | 你自己的 DMARC 策略拒收了未对齐的邮件 | 下方第 4 步 |
| 550 5.7.27（大宗，SPF） | “didn’t pass SPF authentication … Gmail requires bulk email senders to authenticate their email with SPF” | SPF 失败，且你处于大宗发件方档位 | 下方第 3 步 + 修复 SPF |
| 550 5.7.30（大宗，DKIM） | “didn’t pass DKIM authentication … Gmail requires bulk email senders to authenticate their email with DKIM” | 没有有效的 DKIM 签名，且你处于大宗发件方档位 | 下方第 3 步 + 修复 DKIM |
| 550 5.7.29（大宗，TLS） | “wasn’t sent over a TLS connection” | 批量邮件没走 TLS 发送 | 下方第 6 步 |
| 550 5.7.25 | “doesn’t have a PTR record” | 发信 IP 没有反向 DNS（PTR） | 下方第 2 步 |
| 421-4.7.0 | “try again later” / 异常流量 | 临时延迟——信誉或速率问题，不是永久拦截 | 重试；检查第 2–3 步和第 8 步 |
| 550 5.7.28 | “unusual rate of unsolicited email” | 发信速率/垃圾邮件率限制 | 下方第 8 步 |
| 550-5.7.1 | “message blocked” / 策略文本 | 策略、垃圾邮件，或没有 PTR 的 IPv6 拒收 | 见 Gmail 550-5.7.1 指南 |
怎么按要求顺序修复 550 5.7.26？
Google 没有公布字面意义上的“检查顺序”——但它的各项要求在逻辑上是层层递进的，所以按这个要求顺序逐项处理。大多数发件方在第 3 步之后就已经解除拦截了；但仍建议把整份清单走完，因为后面的步骤才是让你脱离拒收后、继续留在收件箱而不是垃圾箱的关键。
- 先运行免费扫描。 它会读取你实时的 SPF、DKIM、DMARC 和 DNS 配置，准确显示哪一条腿在失败——先诊断，再动 DNS。
- 为你的发信 IP 配上反向 DNS（PTR）。 连接用的 IP 必须有一条 PTR 记录，其主机名能解析回同一个 IP。主流服务商通常会替你处理好这一点；这一步常在自建服务器发信的人身上出问题（也是相邻代码 550 5.7.25 背后的全部故事）。
- 让 SPF 或 DKIM 通过。 先提醒一句：接收方是对照 Return-Path（RFC5321.MailFrom）域名，而不是 From 标头来检查 SPF 的——在断定 SPF“应该”通过之前，先确认你的邮件实际退信到的是哪个域名。把你真正的发信服务加进那个域名的 SPF 记录（完整 SPF 操作指南），或者在服务商那边启用 DKIM 签名（完整 DKIM 操作指南）。任何一项通过，就能解除基础的 550 5.7.26 拦截。
- 让 DKIM 与你的 From 域名对齐。 对于大宗发件——以及 DMARC 而言，Gmail 要的是针对 From 地址里那个域名的认证，而不是服务商的默认值。Google Workspace 用户：发布你自己的 DKIM 密钥（Workspace DKIM 设置）；默认的
gappssmtp.com签名能通过 DKIM，但对不上齐——这是个陷阱，有自己的指南。对齐的 DKIM 还能扛住转发，SPF 从来做不到这点。 - 发布一条 DMARC 记录。 Google 的发件方要求至少要有
p=none加一个报告地址。这是五分钟的 DNS 编辑——见“DMARC 策略未启用” 了解诚实的第一步，以及p=none能做到和做不到的事。 - 用 TLS 发信。 任何现代邮件服务器或服务商默认都会这样做；如果你自己搭了 MTA，确认外发 TLS 已开启——没走 TLS 的批量邮件现在会收到自己专属的代码，550 5.7.29。
- 给营销邮件和订阅邮件加上 RFC 8058 一键退订（
List-Unsubscribe+List-Unsubscribe-Post标头）。 - 把垃圾邮件率控制在 Google Postmaster Tools 里的 0.10% 以下——绝不能碰到 0.30%。 Google 的要求上限是 0.3%；它的建议是保持在 0.10% 以下。在那里注册你的域名；这是 Google 自己给你打的成绩单，垃圾邮件率这道门槛是任何 DNS 记录都修不了的。
这份清单做不到的一件事：把你从第三方黑名单上摘下来。认证只能阻止 Gmail 因未认证而做的拒收；有垃圾邮件历史的 IP 是一个有自己一套清理路径的信誉问题——修好认证能防止再犯，但本身不能让你脱离黑名单。
如果每天发信量不到 5000 封，大宗发件方规则也适用吗？
完整清单——对齐认证、发布 DMARC、一键退订、垃圾邮件率——正式生效的门槛是每天给 Gmail 发 5000 封以上邮件，仅限大宗发件方的代码（5.7.27、5.7.29、5.7.30）也来自这个档位。但认证的基本要求（SPF 或 DKIM 通过、有效 PTR）是套用在所有人身上的，这就是为什么小发件方也会碰到 550 5.7.26。把第 1–5 步当成任何发信量下都必须做的，把第 7–8 步当成一旦开始批量发信就必须做的。两家服务商完整的要求清单见我们的 Google 与 Yahoo 发件方要求 数据文章。
常见问题
550 5.7.26 是不是意味着我的域名或 IP 被拉黑了？ 不是。这是一次认证失败，不是信誉判断——Gmail 是在说“证明你是谁”，不是在说“我们知道你是垃圾邮件发送者”。这算是好消息：完全可以在 DNS 里修好。坏消息是这有多常见——在普查的 261,086,232 个域名中（截至 2026-06-29），只有 10.59% 有强制执行的 DMARC 策略。
只修好 SPF 能止住退信吗？ 对基础变体来说，通常可以——Gmail 要求的是 SPF 或 DKIM 至少一项通过。但 SPF 是对照 Return-Path 域名评估的，转发场景下会失效，所以对齐的 DKIM（第 4 步）才是持久的修法。在 12,145,313 个托管在 Google 上的发件域名中，只有 8.0% 使用严格 SPF（数据截至 2026-06-29），所以不管走哪条路，你都已经领先大多数人了。
我用的是 Google Workspace——为什么 Google 会拦截我自己的邮件？ 因为 Gmail 认证的是域名，不是邮箱服务商。一个没有 SPF 记录、也没有自定义 DKIM 密钥的 Workspace 域名，发出的邮件连 Google 自己都验证不了——在授权了 Google 服务器的 12,145,313 个域名中，只有 18.5% 有强制执行的 DMARC（数据截至 2026-06-29）。是 Google 的客户和符合 Google 的规则，是两回事。
DNS 修好之后，Gmail 多久会接受我的邮件？ 新记录一旦生效就会立即起效——通常是几分钟到几小时，TTL 较慢的情况下最多 48 小时。认证方面的修复对 550 5.7.26 检查会立即生效；垃圾邮件率和信誉的恢复（421-4.7.0、5.7.28）则需要几天到几周的干净发信记录。
把报告发给老板
如果你是在替客户修这个问题，别用“退信已解决”就结束工单。修改 DNS 后重新运行免费扫描，把评分报告转发给企业负责人。它会用大白话说明他们的域名现在能认证邮件了，以及还有哪些不足——这正是网络保险续保和供应商安全问卷需要的凭证。你修好了退信；报告证明了这一点。
免费检查你的域名
私密、仅域名所有者可见地看看 Gmail 是在 SPF、DKIM、DMARC 的哪一条腿上拦住了你。
检查你的域名 → · 修复 SPF → · Gmail “550-5.7.1 message blocked” → · 我们如何评分 → · 仅使用汇总数据。数据在欧盟境内存储和处理。