Email bị blacklist? Cách đọc thư báo lỗi và gỡ khỏi danh sách đen

Ngày đăng 2026-11-03 ／ Cập nhật 2026-11-03 ／ Tác giả Yuki Nakazawa

Nếu email của bạn bị đưa vào danh sách đen (blacklist), thư báo lỗi trả lại (bounce) thường sẽ cho bạn biết. Hãy mở thư từ chối nhận được và xem ba thứ: mã ba chữ số, mã có dấu chấm đi sau (ví dụ 5.7.1) và phần nội dung. Mã bắt đầu bằng 4 là lỗi tạm thời; mã bắt đầu bằng 5 là lỗi vĩnh viễn. Nếu nội dung nêu tên một danh sách chặn, đó là danh sách cần xử lý trước tiên.

Trước khi lo đến danh sách đen, bạn hãy lần lượt loại trừ các nguyên nhân đơn giản: gõ sai địa chỉ, hộp thư đầy, sự cố phía người nhận, và thiếu SPF, DKIM hoặc DMARC. Cách gỡ khỏi danh sách đen gần như nơi nào cũng giống nhau: tìm và chặn đứng nguyên nhân, gửi một yêu cầu gỡ nếu danh sách đó yêu cầu, rồi chờ. Không ai có thể hứa chắc việc được gỡ tên, và gửi yêu cầu nhiều lần mà không khắc phục thường khiến tình hình tệ hơn.

Thông tin về từng danh sách và nhà cung cấp hộp thư bên dưới được lấy từ trang chính thức của họ tại thời điểm tháng 11 năm 2026. Chính sách có thể thay đổi, vì vậy bạn hãy xác nhận chi tiết trên trang của chính đơn vị quản lý trước khi hành động.

Kiểm tra miễn phí xem tên miền hoặc địa chỉ IP của bạn có nằm trong khoảng 345 danh sách đen hay không.

Cách đọc thư báo lỗi trả lại

Thư báo lỗi (báo cáo không gửi được) trích lại câu trả lời mà máy chủ nhận đưa ra. Một lần từ chối điển hình do danh sách đen trông như sau:

<user@example.com>: host mx.example.com[203.0.113.25] said:
    550 5.7.1 Service unavailable; Client host [203.0.113.10]
    blocked using bl.example.org (in reply to RCPT TO command)

Mã trả lời (550). Theo RFC 5321, mã dạng 4yz nghĩa là lỗi tạm thời và có thể thử lại cùng yêu cầu đó. Mã dạng 5yz là lỗi vĩnh viễn, và máy chủ gửi không nên cứ thế lặp lại đúng yêu cầu đó.
Mã trạng thái mở rộng (5.7.1). Được định nghĩa trong RFC 3463 theo dạng class.subject.detail. Số ở giữa cho biết lĩnh vực: 1 là địa chỉ, 2 là hộp thư, 4 là mạng và định tuyến, 7 là bảo mật hoặc chính sách. Mã 5.7.x nghĩa là máy chủ nhận từ chối bạn vì lý do chính sách, và đây là nơi danh sách chặn và uy tín xuất hiện.
Phần nội dung tự do. Máy chủ nhận thường nêu tên danh sách (blocked using bl.example.org) hoặc cho một URL tra cứu. Bạn hãy sao chép toàn bộ thư báo lỗi; bạn sẽ cần đến nó cho mọi yêu cầu gỡ tên hoặc yêu cầu hỗ trợ.

Các mã thường gặp và ý nghĩa của chúng. Mô tả cho 5.7.25, 5.7.26 và 4.7.x lấy từ danh sách lỗi mà Gmail công bố; các nhà cung cấp khác có thể diễn đạt hoặc dùng cùng mã theo cách khác.

Mã	Ý nghĩa	Kiểm tra trước
`550 5.1.1`	Hộp thư người nhận không tồn tại	Chính tả, khoảng trắng thừa
`452 4.2.2` / `552 5.2.2`	Hộp thư người nhận đã đầy	Nhờ người nhận giải phóng dung lượng, rồi gửi lại
`550 5.7.1`	Không được phép gửi; bị từ chối theo chính sách. Thường do danh sách chặn hoặc uy tín người gửi kém	Tên danh sách trong nội dung, các danh sách đang liệt kê IP gửi của bạn
`550 5.7.26`	Thư không được xác thực bằng SPF hoặc DKIM, hoặc bị DMARC từ chối (Gmail)	Bản ghi SPF, DKIM và DMARC
`550 5.7.25`	IP gửi không có bản ghi PTR, hoặc PTR không khớp với DNS thuận (Gmail)	DNS ngược trên máy chủ gửi
`421 4.7.0`, `421 4.7.28`	Giới hạn tốc độ tạm thời do uy tín IP thấp hoặc tốc độ gửi bất thường (Gmail)	Các đợt tăng khối lượng gần đây, khiếu nại
4.4.x	Sự cố mạng, chẳng hạn hết thời gian chờ hoặc máy chủ đang bận	MX của tên miền người nhận, sự cố ở phía họ

Với lỗi 4xx, máy chủ của bạn sẽ tự động thử lại. RFC 5321 khuyến nghị chờ ít nhất 30 phút giữa các lần thử và cho rằng thời gian trước khi bỏ cuộc thường cần tối thiểu 4 đến 5 ngày, vì vậy bạn có thể nhận cảnh báo "bị trì hoãn" từ rất lâu trước khi thư thất bại hẳn.

Kiểm tra nguyên nhân theo thứ tự này

Hãy đi từ những nguyên nhân phổ biến, dễ kiểm tra nhất đến những nguyên nhân hiếm hơn. Các bước đầu chỉ mất vài giây, vì vậy hãy làm chúng trước tiên.

Gõ sai địa chỉ. Lỗi 5.1.1 không liên quan gì đến danh sách đen. Hãy sửa lại địa chỉ.
Hộp thư đầy. 4.2.2 hoặc 5.2.2 là vấn đề của người nhận. Hãy liên hệ họ bằng cách khác.
Chỉ một người nhận bị lỗi. Nếu thư gửi đến các công ty khác và đến Gmail vẫn đi được, nguyên nhân nhiều khả năng là bộ lọc riêng của người nhận. Hãy gửi toàn bộ nội dung thư báo lỗi cho quản trị viên bên họ.
SPF, DKIM và DMARC. Gmail yêu cầu mọi người gửi thiết lập SPF hoặc DKIM, và người gửi trên 5.000 thư mỗi ngày phải thiết lập SPF, DKIM và DMARC. Yêu cầu của Yahoo cũng tương tự, trong đó người gửi hàng loạt cần chính sách DMARC tối thiểu là p=none. Outlook.com bắt đầu áp dụng các yêu cầu tương tự với tên miền gửi trên 5.000 thư mỗi ngày từ ngày 5 tháng 5 năm 2025. Xem hướng dẫn thiết lập SPF, DKIM và DMARC.
Uy tín của IP gửi và tên miền. Hãy kiểm tra IP gửi có DNS thuận và DNS ngược (PTR) hợp lệ, bạn có gửi qua TLS, và lượng khiếu nại có thấp hay không. Gmail và Yahoo đều yêu cầu người gửi giữ tỷ lệ spam dưới 0,3%; Gmail khuyến nghị ở mức 0,10% hoặc thấp hơn.
Kiểm tra danh sách đen. Nếu thư báo lỗi nêu tên một danh sách, hoặc nhiều người nhận không liên quan đến nhau cùng trả về 5.7.1, hãy tra IP gửi và tên miền của bạn bằng công cụ kiểm tra danh sách đen.
Nội dung và khối lượng. Hãy tìm những gì đã thay đổi: một đợt gửi lớn đột ngột, một danh sách cũ được gửi một lượt, một biểu mẫu web bị lạm dụng để gửi thư cho người lạ.

Nếu chỉ có Gmail từ chối bạn, hướng dẫn xử lý sự cố gửi thư đến Gmail sẽ đi sâu hơn vào các mã lỗi riêng của Gmail.

Danh sách đen email (DNSBL) là gì và cách kiểm tra

Phần lớn danh sách đen email là DNSBL: danh sách được công bố qua DNS. Khi máy chủ của bạn kết nối, máy chủ nhận sẽ tra IP của bạn trong các danh sách mà họ tin dùng, rồi từ chối, chấm điểm hoặc gắn nhãn thư dựa trên kết quả.

RFC 5782 mô tả cách tra cứu này. Với IPv4, các octet được đảo ngược và ghép vào trước tên miền của danh sách. Địa chỉ bị liệt kê sẽ trả về bản ghi A, theo quy ước là 127.0.0.2, và có thể có bản ghi TXT giải thích lý do. Địa chỉ không bị liệt kê thì không có bản ghi nào. IPv6 dùng dạng đảo ngược theo từng nibble (nửa byte) của toàn bộ địa chỉ.

$ dig +short 10.113.0.203.bl.example.org A
127.0.0.2
$ dig +short 10.113.0.203.bl.example.org TXT
"Listed - see https://bl.example.org/lookup"

Vài điểm dễ gây nhầm lẫn:

Hãy kiểm tra IP của máy chủ gửi thư cho bạn, không phải máy tính xách tay hay đường truyền văn phòng. Bạn có thể tìm thấy nó trong thư báo lỗi (Client host [...]) hoặc trong các tiêu đề Received của một thư bạn đã gửi.
Tên miền cũng có thể bị liệt kê. Một số danh sách bao gồm tên miền gửi hoặc tên miền xuất hiện trong liên kết. Hãy kiểm tra cả IP lẫn tên miền.
Việc bị liệt kê chỉ có ý nghĩa ở nơi danh sách đó được sử dụng. Mỗi máy chủ nhận tự quyết định tra cứu những danh sách nào. Nằm trong một danh sách mà người nhận của bạn không dùng thì chẳng thay đổi gì đối với họ.

Tra hàng chục danh sách bằng tay rất mất công; công cụ kiểm tra danh sách đen làm việc này trong một lần và cho biết danh sách nào trả về kết quả bị liệt kê.

Những danh sách nào thực sự quan trọng

Không phải lần bị liệt kê nào cũng đáng được quan tâm như nhau. Thứ tự ưu tiên đại khái:

Danh sách được nêu tên trong thư báo lỗi. Đó là danh sách thực sự đang chặn bạn. Hãy xử lý nó trước.
Các danh sách lớn, được dùng rộng rãi. Bị liệt kê ở đây sẽ ảnh hưởng đến nhiều máy chủ nhận cùng lúc.
Một hai kết quả trên các danh sách nhỏ hoặc ít người biết, khi không có thư báo lỗi nào nêu tên chúng, thường không phải lý do email của bạn bị chặn. Hãy xem xét xác thực và uy tín trước khi dành thời gian cho chúng.

Cách một số danh sách nổi tiếng tự mô tả, dựa trên trang chính thức của họ tại thời điểm tháng 11 năm 2026:

Danh sách	Đối tượng bị liệt kê	Cách gỡ tên
Spamhaus PBL	Các dải IP của người dùng cuối, chẳng hạn băng thông rộng, vốn không nên gửi thư trực tiếp đến máy chủ nhận	Không phải dấu hiệu gửi spam. Thay vào đó, hãy gửi qua máy chủ thư có xác thực ở cổng 587 hoặc 465. Người dùng cuối chỉ có thể yêu cầu loại trừ khi chính sách của nhà mạng cho phép; việc loại trừ từng IP riêng lẻ hết hạn sau một năm
SpamCop	Các IP bị người dùng SpamCop báo cáo	Tự động gỡ 24 giờ sau khi không còn báo cáo. Không nhận yêu cầu gỡ sớm
Barracuda BRBL	Các IP bị hệ thống tự động gắn cờ	Gửi biểu mẫu yêu cầu gỡ một lần; các yêu cầu trùng lặp sẽ bị bỏ qua. Yêu cầu có giải thích hợp lệ thường được xử lý trong vòng 12 giờ
UCEPROTECT Level 1	Từng IP riêng lẻ	Tự động hết hạn 7 ngày sau lần gửi spam cuối cùng. Có dịch vụ gỡ nhanh trả phí, được mô tả là không bắt buộc
UCEPROTECT Level 2	Toàn bộ khối địa chỉ được cấp, khi số kết quả Level 1 trong dải vượt quá ngưỡng quy định	Tự động gỡ khi dải không còn đáp ứng tiêu chí. Thông thường chỉ nhà cung cấp dịch vụ mới có thể yêu cầu gỡ
UCEPROTECT Level 3	Toàn bộ mạng (ASN)	Tự động gỡ khi không còn đáp ứng tiêu chí. Chính sách ghi rõ yêu cầu gỡ từ khách hàng cuối là vô ích

Có hai điều cần lưu ý. Thứ nhất, các danh sách bao phủ cả dải, như UCEPROTECT Level 2 và 3, có thể chứa IP của bạn dù bạn chưa từng gửi spam, do các địa chỉ khác trên cùng mạng. Thứ hai, khi một danh sách có dịch vụ gỡ nhanh trả phí, thường cũng có cơ chế tự động hết hạn miễn phí song song, và trả tiền không khắc phục được nguyên nhân dẫn đến việc bị liệt kê. Nếu nguyên nhân vẫn còn, bạn sẽ lại bị liệt kê. Spamhaus có nhiều danh sách với cách gỡ khác nhau; xem cách gỡ tên khỏi Spamhaus.

Cách gỡ tên khỏi danh sách đen

Quy trình gần như giống nhau với mọi danh sách:

Tìm và chặn đứng nguyên nhân. Thủ phạm thường gặp là mật khẩu hộp thư bị lộ, máy tính nhiễm mã độc, biểu mẫu liên hệ gửi thư đến bất kỳ địa chỉ nào được nhập, máy chủ open relay (chuyển tiếp thư mở), hoặc gửi thư cho những người chưa từng đồng ý nhận. Hãy đổi mật khẩu và vá lỗ hổng trước mọi việc khác.
Đọc trang tra cứu của đơn vị quản lý. Hầu hết danh sách cho phép bạn nhập IP để xem lý do bị liệt kê và cách gỡ. Hãy làm theo hướng dẫn đó, đừng dựa vào phỏng đoán của bên thứ ba.
Nếu danh sách tự hết hạn, hãy chờ. SpamCop gỡ tên 24 giờ sau khi không còn báo cáo; UCEPROTECT Level 1 sau 7 ngày không có spam mới.
Nếu danh sách nhận yêu cầu, hãy gửi một lần. Trình bày rõ ràng chuyện gì đã xảy ra và bạn đã thay đổi những gì. Ví dụ, Barracuda nêu rõ các yêu cầu trùng lặp sẽ bị bỏ qua.
Gửi lại và theo dõi. Việc gỡ tên có thể cần thời gian để lan truyền. SpamCop lưu ý có thể mất đến 4 giờ để thay đổi đến các máy chủ nhân bản (mirror) và những máy chủ dùng danh sách này.

Gửi đi gửi lại cùng một yêu cầu, hoặc yêu cầu gỡ trước khi khắc phục nguyên nhân, sẽ phản tác dụng. Ngay cả khi có hiệu quả, bạn sẽ lại bị liệt kê ngay khi sự cố tái diễn, và dù thế nào thì đơn vị quản lý vẫn có quyết định cuối cùng.

Bạn cũng cần nhớ rằng DNSBL chỉ là một yếu tố đầu vào. Khi Gmail từ chối thư với mã 550 5.7.1 viện dẫn uy tín rất thấp của IP gửi hoặc tên miền của bạn, đó là đánh giá riêng của Gmail. Gỡ khỏi DNSBL sẽ không thay đổi điều đó; xác thực tốt hơn, danh sách người nhận sạch hơn và ít khiếu nại hơn mới làm được.

Hosting dùng chung và VPS: khi IP không chỉ của riêng bạn

Trên hosting dùng chung, nhiều khách hàng gửi thư qua cùng một IP gửi ra. Website bị xâm nhập của người khác có thể khiến IP đó bị liệt kê, và thư của bạn bị chặn cùng với thư của họ.

Hosting dùng chung. Nhà cung cấp hosting quản lý IP, vì vậy hãy mở yêu cầu hỗ trợ kèm toàn bộ thư báo lỗi và IP bị liệt kê, thay vì tự gửi yêu cầu gỡ. Các trường hợp liệt kê theo dải hoặc theo mạng, như UCEPROTECT Level 2 và 3, chỉ nhà cung cấp mới xử lý được.
VPS hoặc máy chủ riêng. Một IP vừa được cấp có thể mang lịch sử từ người thuê trước. Hãy kiểm tra trước khi bắt đầu gửi thư, và đặt DNS ngược (PTR) khớp với tên máy chủ thư của bạn, thường thực hiện qua bảng điều khiển của nhà cung cấp.
Gửi trực tiếp từ IP gia đình hoặc IP động. Đây chính là những dải mà Spamhaus PBL nhắm đến. Hãy chuyển thư qua máy chủ gửi (submission) của nhà mạng hoặc dịch vụ email, có xác thực ở cổng 587 hoặc 465.

Nếu bạn không kiểm soát được IP và nhà cung cấp không khắc phục được, chuyển thư gửi đi sang một máy chủ gửi có xác thực khác thường là giải pháp thực tế.

Cách tránh bị liệt kê lại

Việc gỡ tên chỉ bền vững nếu nguyên nhân vẫn được khắc phục. Hãy duy trì những thói quen sau:

Xác thực và những điều cơ bản. Giữ SPF, DKIM và DMARC hợp lệ, giữ DNS ngược chính xác và gửi qua TLS. Cập nhật SPF mỗi khi bạn thêm một dịch vụ gửi thư mới.
Bảo mật tài khoản. Dùng mật khẩu mạnh và xác thực hai yếu tố, đồng thời theo dõi các bước tăng đột ngột về khối lượng thư gửi đi hoặc kích thước hàng đợi.
Bảo vệ biểu mẫu. Giới hạn tần suất cho biểu mẫu liên hệ và đăng ký để chúng không bị dùng để gửi thư đến địa chỉ tùy ý.
Giữ danh sách sạch. Chỉ gửi thư cho người đã yêu cầu và xóa các địa chỉ bị trả lại. Gmail và Yahoo yêu cầu người gửi hàng loạt hỗ trợ hủy đăng ký bằng một lần nhấp.
Tránh tăng đột biến. Một đợt gửi lớn hơn hẳn bình thường có thể kích hoạt giới hạn tốc độ và khiếu nại.
Kiểm tra định kỳ. Thỉnh thoảng tra IP gửi và tên miền của bạn giúp phát hiện việc bị liệt kê trước khi khách hàng báo thiếu thư.

Nếu bạn không muốn tự xử lý

Chúng tôi giới thiệu các nhà cung cấp nhận làm yêu cầu gỡ tên (delist), tư vấn và hỗ trợ (từ JPY 50,000). Việc gỡ tên do từng đơn vị quản lý danh sách quyết định và không thể được cam kết.

Nhận hỗ trợ

Trang web này có thể nhận phí giới thiệu từ các nhà cung cấp được liệt kê. About

Câu hỏi thường gặp

Mất bao lâu để được gỡ khỏi danh sách đen?

Tùy vào danh sách. Tại thời điểm tháng 11 năm 2026, SpamCop gỡ tên 24 giờ sau khi không còn báo cáo, mục của UCEPROTECT Level 1 hết hạn 7 ngày sau lần gửi spam cuối cùng, còn Barracuda cho biết yêu cầu gỡ có giải thích hợp lệ thường được xử lý trong vòng 12 giờ. Tất cả đều với điều kiện nguyên nhân đã được chặn đứng, và đơn vị quản lý là người quyết định cuối cùng.

Tôi bị liệt kê trong một danh sách đen nhỏ. Tôi có cần làm gì không?

Thường là không, nếu không có thư báo lỗi nào nhắc đến danh sách đó và bạn không bị liệt kê trong các danh sách lớn. Hãy kiểm tra xác thực và các nguyên nhân phía người nhận trước. Nếu muốn kỹ lưỡng, bạn hãy đọc chính sách của danh sách đó trên trang của chính họ.

Tôi có nên trả phí để được gỡ nhanh không?

Hiếm khi cần thiết. UCEPROTECT mô tả dịch vụ gỡ nhanh trả phí của họ là không bắt buộc, và các mục liệt kê của họ cũng tự hết hạn miễn phí. Trả tiền không khắc phục được nguyên nhân, nên nếu không sửa lỗi thì bạn sẽ lại bị liệt kê.

Tôi đã được gỡ tên nhưng email vẫn bị chặn. Vì sao?

Việc gỡ tên có thể chưa lan truyền xong, hoặc vẫn còn một nguyên nhân khác. Hãy đọc kỹ thư báo lỗi mới. Nếu một nhà cung cấp như Gmail viện dẫn uy tín của IP hoặc tên miền của bạn, đó là đánh giá riêng của họ, và cần cải thiện xác thực, nội dung và tỷ lệ khiếu nại chứ không phải gỡ khỏi DNSBL.

Tôi nên làm gì với lỗi 4xx?

Lúc đầu thường không cần làm gì. Mã 4xx là lỗi tạm thời và máy chủ của bạn sẽ tự động thử lại trong vài ngày. Nếu cùng một lỗi cứ lặp lại, hoặc chuyển thành 5xx, hãy lần lượt thực hiện các bước kiểm tra trong bài viết này.

Các trang chính thức được tham khảo

Thông tin trong bài viết này đã được đối chiếu với các trang chính thức dưới đây tại thời điểm đăng. Chính sách và cách vận hành có thể thay đổi mà không báo trước, vì vậy bạn hãy kiểm tra lại các trang chính thức trước khi dựa vào thông tin cho việc quan trọng.

Hướng dẫn liên quan

Gmail chặn email hoặc đưa vào thư rác? Nguyên nhân và cách khắc phục

Vì sao Gmail chặn email hoặc đưa email vào thư rác, mã lỗi như 550 5.7.26 có nghĩa là gì, và cách tìm lại thư bị thiếu trong hộp thư Gmail của bạn.

Thiết lập SPF, DKIM và DMARC: bản ghi, lỗi thường gặp và cách kiểm tra

Thiết lập SPF, DKIM, DMARC: bản ghi DNS mẫu, giới hạn 10 lượt tra cứu, khóa 2048 bit, triển khai an toàn từ p=none, quy định của Gmail, Yahoo, Outlook.

Gỡ tên khỏi Spamhaus: cách gỡ IP hoặc tên miền bị liệt kê

Bị Spamhaus liệt kê? Xác định bạn nằm trong danh sách nào (ZEN, PBL, XBL, CSS, SBL, DBL), ý nghĩa của mã trả về và cách gỡ tên đúng cho từng danh sách.

Tất cả hướng dẫn →