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