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” → · 我們如何評分 → · 僅使用彙總資料。資料在歐盟境內儲存和處理。