Defaults.Exposed › Cách khắc phục › Guides
Gmail "550-5.7.1 Message Blocked" — Giải Mã Lỗi và Khắc Phục (2026)
Đã xuất bản 2026-07-08
Số liệu tính đến 2026-06-29 · phương pháp v7. Dữ liệu tổng hợp trên 261 triệu tên miền được chấm điểm. Xem cách chúng tôi chấm điểm.
Gmail trả về 550-5.7.1 khi chặn tin nhắn vì lý do chính sách chứ không phải bản ghi bị thiếu: chính sách của tên miền gửi hoặc nhận, kết nối IPv6 không có reverse DNS, hoặc nghi ngờ spam. Trong số 12,145,313 tên miền phân quyền máy chủ riêng của Google trong SPF, chỉ 18.5% thực thi DMARC, theo thống kê Defaults.Exposed trên 261 triệu tên miền.
550-5.7.1 là lỗi từ chối catch-all cũ nhất của Gmail, và cách khắc phục phụ thuộc vào câu sau mã trong lỗi của bạn. Dưới đây: bảng giải mã cho từ ngữ chính xác, rồi con đường khắc phục theo từng biến thể — từ chối chính sách, máy chủ IPv6 không có reverse DNS, chặn spam hoặc nội dung — cùng các mã trông giống nhau mà người ta nhầm lẫn với nó, bao gồm nhóm 5.7.26 mà Google giờ dùng cho từ chối chính sách DMARC mà các tài liệu cũ đặt dưới 5.7.1.
550-5.7.1 của Gmail thực sự có nghĩa là gì?
Trong sơ đồ trạng thái nâng cao SMTP (RFC 3463), mọi mã 5.7.x đều có nghĩa là “lỗi vĩnh viễn, lý do chính sách”. Gmail dùng 550-5.7.1 là nhóm chính sách kế thừa: chặn chính sách người gửi hoặc người nhận, chặn danh tiếng spam, và — biến thể làm ngạc nhiên hầu hết quản trị viên — mail đến qua IPv6 từ máy chủ không có bản ghi reverse-DNS (PTR).
Google đã mã hóa lại các biến thể theo thời gian. Từ chối chính sách DMARC (“not accepted due to domain’s DMARC policy”) giờ nằm dưới 550-5.7.26 trong tài liệu tham khảo hiện tại của Google, mặc dù các lỗi cũ hơn vẫn có thể hiển thị là 5.7.1; chặn bảo mật nội dung giờ được mã hóa là 552 5.7.0. Hai anh em khác bị nhầm với 5.7.1: 550-5.7.26, nhóm yêu cầu xác thực (hướng dẫn riêng), và 550-5.7.25, mã thiếu PTR trên bất kỳ phiên bản IP nào. Dù là mã nào, hãy giải mã văn bản dưới đây.
Bạn có biến thể 550-5.7.1 nào?
Khớp từ ngữ trong báo cáo không gửi được (NDR) của bạn. Google điều chỉnh các chuỗi này giữa các năm — khớp ý nghĩa, không phải dấu câu.
| Lỗi của bạn có nội dung như… | Ý nghĩa | Con đường khắc phục của bạn |
|---|---|---|
| ”This message does not meet IPv6 sending guidelines regarding PTR records and authentication.” | Máy chủ của bạn gửi qua IPv6 không có (hoặc không khớp) reverse DNS | Bản ghi PTR cho địa chỉ IPv6, hoặc chuyển tiếp qua smarthost của nhà cung cấp (bên dưới) |
| “The user or domain that you are sending to (or from) has a policy that prohibited the email that you sent.” | Chặn chính sách — của người nhận, hoặc tên miền của bạn | Liên hệ quản trị viên nhận; nếu DMARC của tên miền riêng là chính sách đang được áp dụng, xem bên dưới |
| ”This message is likely unsolicited email. To reduce the amount of spam sent to Gmail, this message has been blocked.” | Chặn spam/danh tiếng trên nội dung, IP hoặc tên miền của bạn | Postmaster Tools + làm sạch danh sách + hủy đăng ký một cú nhấp (bên dưới) |
| “This message is likely suspicious due to the very low reputation of the sending domain” (hoặc “…sending IP address”) | Chặn danh tiếng — tên miền hoặc IP | Cùng con đường danh tiếng (bên dưới) |
| “Unauthenticated email from yourdomain is not accepted due to domain’s DMARC policy.” — được mã hóa là 550-5.7.26 trong tài liệu tham khảo hiện tại của Google; lỗi cũ hơn có thể vẫn hiển thị là 5.7.1 | Chính sách DMARC của bạn nói với Gmail từ chối tin nhắn chưa xác thực | Tìm nguồn chưa xác thực — đừng nới lỏng chính sách trước (bên dưới) |
| “…blocked because its content presents a potential security issue.” — giờ được mã hóa là 552 5.7.0 | Chặn nội dung/chính sách (loại tệp đính kèm, danh tiếng liên kết) | Xóa loại nội dung bị gắn cờ; kiểm tra liên kết và tệp đính kèm |
| Mã là 550-5.7.25, “the sending IP address doesn’t have a PTR record” | Thiếu reverse DNS trên bất kỳ phiên bản IP nào | Cùng cách khắc phục rDNS như biến thể IPv6 |
| Mã là 550-5.7.26 | Nhóm yêu cầu xác thực, không phải 5.7.1 | Xem hướng dẫn 550-5.7.26 |
| Mã là 421-4.7.0, “Try again later, closing connection.” | Trì hoãn tạm thời — tốc độ hoặc danh tiếng, không phải chặn vĩnh viễn | Làm chậm lại, khắc phục xác thực và tỷ lệ spam; thường tự xóa |
Làm thế nào để khắc phục lỗi 550-5.7.1?
- Chạy quét miễn phí tại defaults.exposed — nó chấm điểm SPF, DKIM và DMARC của bạn như thế giới thấy chúng, trước khi bạn chạm vào DNS, và cho biết liệu biến thể DMARC có thể xảy ra với tên miền của bạn không.
- Đọc toàn bộ văn bản NDR theo bảng giải mã — câu, không phải mã, xác định nguyên nhân.
- Biến thể DMARC: tìm nguồn gửi nào thất bại xác thực và khắc phục nguồn đó (phần tiếp theo).
- Biến thể IPv6/PTR: thêm reverse DNS khớp cho địa chỉ IPv6 của máy chủ, hoặc chuyển tiếp qua smarthost của nhà cung cấp.
- Biến thể spam/chính sách: Postmaster Tools, tỷ lệ spam dưới 0,10% (yêu cầu trần cứng của Google là 0,30%), làm sạch danh sách, hủy đăng ký một cú nhấp RFC 8058.
- Gửi thử nghiệm đến hộp thư Gmail và quét lại — xác nhận lỗi đã biến mất và điểm số phản ánh điều đó.
Lỗi đề cập đến chính sách DMARC của bạn — tại sao đó là chính sách của bạn đang hoạt động
Tài liệu tham khảo hiện tại của Google mã hóa chuỗi này là 550-5.7.26, nhưng các lỗi cũ hơn và tài liệu bên thứ ba vẫn hiển thị nó dưới 5.7.1 — dù sao cơ chế cũng giống hệt nhau. Nó đọc ngược lại cho đến khi bạn hiểu: Gmail kiểm tra tin nhắn tuyên bố là từ tên miền của bạn, thấy rằng cả SPF lẫn DKIM đều không vượt qua với căn chỉnh, tra cứu bản ghi DMARC của bạn, và đã làm chính xác điều bạn yêu cầu — từ chối. Hàng rào của bạn đã giữ. Câu hỏi là điều gì bị bắt vào nó: người gửi hợp lệ bị quên (CRM, công cụ lập hóa đơn, nền tảng newsletter) hay một vụ giả mạo thực sự.
Vì vậy đừng nới lỏng chính sách như bước một. Tìm nguồn chưa xác thực. Hai bẫy phổ biến nhất:
- SPF vượt qua, nhưng trên sai tên miền. Máy chủ nhận đánh giá SPF dựa trên tên miền Return-Path (RFC5321.MailFrom), không phải tiêu đề From. Công cụ SaaS gửi “từ” bạn thường vượt qua SPF trên tên miền bounce của chính nó, không căn chỉnh với tên miền From của bạn — vì vậy DMARC vẫn thất bại. Hướng dẫn thực hiện: DMARC thất bại nhưng SPF và DKIM vượt qua.
- DKIM vượt qua, nhưng với chữ ký mặc định. Mặc định
gappssmtp.comcủa Google Workspace vàonmicrosoft.comcủa Microsoft xác minh tốt và không căn chỉnh với bất cứ điều gì. Xem DKIM vượt qua nhưng DMARC vẫn thất bại.
Biến thể này hiếm hơn bạn nghĩ: 27,640,987 trong số 261,086,232 tên miền — 10.59% — thực thi chính sách DMARC quarantine hoặc reject, theo thống kê Defaults.Exposed (2026-06-29). 89.41% còn lại không bao giờ thấy lỗi này vì họ không có hàng rào để giữ. Khắc phục nguồn, không phải chính sách, được trình bày đầy đủ trong hướng dẫn sửa DMARC.
Lỗi đề cập đến hướng dẫn gửi IPv6 — cách khắc phục reverse-DNS
Các máy chủ hiện đại thường kết nối với Gmail qua IPv6 theo mặc định, và Google yêu cầu địa chỉ IPv6 kết nối phải có bản ghi PTR phân giải đến hostname phân giải ngược lại về cùng địa chỉ (reverse DNS được xác nhận chuyển tiếp). Thiếu điều đó, và mọi tin nhắn đều nhận 550-5.7.1 bất kể SPF của bạn sạch đến đâu.
Ba cách khắc phục, theo thứ tự ưu tiên:
- Đặt bản ghi PTR cho địa chỉ IPv6 của máy chủ — thực hiện ở nơi IP tồn tại (bảng điều khiển VPS host hoặc ISP của bạn, không phải vùng DNS của tên miền), với bản ghi AAAA khớp trỏ ngược lại.
- Chuyển tiếp qua smarthost của nhà cung cấp. Nếu bạn không thể kiểm soát rDNS, định tuyến mail đi ra qua relay của nhà cung cấp email hoặc ISP, vốn đã có rDNS đúng.
- Ưu tiên truyền tải IPv4 như giải pháp tạm thời. Nó thường ẩn triệu chứng vì địa chỉ IPv4 của bạn có PTR — là giải pháp vòng quanh, không phải khắc phục. Đặt PTR IPv6 khi có thể.
Lỗi nói “likely unsolicited email” — con đường danh tiếng
Ở đây xác thực có thể ổn, nhưng bộ lọc của Gmail không tin tưởng mail. Xác thực là sàn, không phải trần — trong số 12,145,313 tên miền phân quyền _spf.google.com, chỉ 8.0% khóa SPF bằng -all nghiêm ngặt, vì vậy một kiểm tra vượt qua nói rất ít về bản thân nó. (So sánh đầy đủ: nhà cung cấp email nào cho SPF mặc định mạnh nhất.)
Danh sách kiểm tra danh tiếng:
- Đăng ký trong Google Postmaster Tools và theo dõi dashboard tỷ lệ spam — giữ dưới 0,10%, và không bao giờ để đạt trần 0,30% mà hướng dẫn người gửi số lượng lớn của Google đặt là yêu cầu cứng.
- Làm sạch danh sách của bạn. Bỏ những người không tương tác và bất cứ thứ gì mua hoặc thu thập; chỉ gửi đến những người đã yêu cầu.
- Thực hiện hủy đăng ký một cú nhấp RFC 8058 trên mail hàng loạt — bắt buộc theo quy tắc của Google, và mỗi lần hủy đăng ký không phải nhấp “spam” bảo vệ tỷ lệ của bạn.
- Giữ xác thực căn chỉnh (SPF và DKIM trên tên miền riêng của bạn) để danh tiếng tích lũy cho tên miền bạn kiểm soát.
Câu hỏi thường gặp
550-5.7.1 có giống 550-5.7.26 không? Không. 550-5.7.26 là nhóm yêu cầu xác thực của Gmail (SPF/DKIM bị thiếu hoặc thất bại) — và tài liệu tham khảo hiện tại của Google cũng đặt từ chối chính sách DMARC ở đó. 550-5.7.1 là nhóm chính sách cũ hơn: chặn chính sách người nhận và người gửi, IPv6 không có PTR, chặn spam và danh tiếng. Văn bản lỗi, không phải số, cho biết cách khắc phục nào áp dụng (tính đến 2026-06-29 và hướng dẫn Google hiện tại).
Tôi có nên đặt lại chính sách DMARC về p=none để dừng lỗi không? Điều đó dừng chúng bằng cách phá bỏ hàng rào. Chỉ 10.59% trong số 261,086,232 tên miền trong thống kê Defaults.Exposed (2026-06-29) thực thi DMARC; nếu bạn là một trong số đó, hãy giữ và khắc phục nguồn chưa xác thực — nới lỏng chính sách mở lại việc giả mạo tên miền chính xác.
Tại sao Gmail chặn mail của tôi khi bản ghi SPF của tôi vượt qua mọi công cụ kiểm tra? Công cụ kiểm tra thử nghiệm bản ghi; Gmail thử nghiệm tin nhắn. SPF được đánh giá dựa trên tên miền Return-Path, không phải địa chỉ From có thể nhìn thấy, vì vậy vượt qua trên tên miền bounce của nhà cung cấp không làm gì cho căn chỉnh DMARC của bạn — và chặn danh tiếng bỏ qua SPF hoàn toàn. Quét miễn phí cho thấy lớp nào thực sự thất bại.
550-5.7.1 có nghĩa là IP của tôi nằm trong danh sách đen không? Không nhất thiết. Gmail chạy hệ thống danh tiếng riêng; bạn có thể bị Google chặn trong khi không có danh sách chặn công khai nào. Kiểm tra Postmaster Tools để xem quan điểm của Google — và lưu ý rằng khắc phục xác thực ngăn chặn thiệt hại trong tương lai nhưng không tự nó đặt lại danh tiếng gửi kém.
Gửi báo cáo cho chủ sở hữu
Một khi lỗi được khắc phục, hãy chạy lại quét và chuyển tiếp báo cáo có điểm số cho chủ doanh nghiệp hoặc khách hàng có mail bị lỗi. Nó cho thấy, bằng ngôn ngữ đơn giản, điều gì bị hỏng, bạn đã khắc phục gì, và tên miền hiện đứng ở đâu so với nền tảng 261 triệu tên miền — chính xác điều họ cần cho đợt gia hạn bảo hiểm hoặc bảng câu hỏi bảo mật khách hàng hỏi “bạn có xác thực email không?”. Một lỗi được khắc phục âm thầm là công việc vô hình; một báo cáo trước-và-sau là bằng chứng.
Kiểm tra tên miền của bạn → · Gmail 550-5.7.26 — cách khắc phục theo thứ tự yêu cầu → · Sửa DMARC → · Cách chúng tôi chấm điểm → · Chỉ dữ liệu tổng hợp. Dữ liệu được lưu trữ và xử lý tại EU.