IP hosting chia sẻ bị blacklist? Việc bạn tự sửa được và không
Khi IP hosting chia sẻ bị đưa vào danh sách đen, việc đầu tiên là xác định ai kiểm soát IP đó, chính xác nó nằm trong danh sách nào và với mã trả về nào. Sau đó, hãy khắc phục mọi vấn đề ở phía bạn và gửi cho nhà cung cấp hosting bằng chứng tra cứu để họ xử lý. Trên một IP dùng chung, nguyên nhân có thể hoàn toàn đến từ một khách hàng khác, và với một số danh sách, chỉ chủ sở hữu mạng mới có thể yêu cầu gỡ.
Một IP VPS hoặc cloud vừa được cấp cũng có thể trông như "bị blacklist" ngay từ ngày đầu, do lịch sử của người dùng trước hoặc do dải địa chỉ được liệt kê là dải không nên gửi thư trực tiếp. Dù trong tình huống nào, quyết định gỡ khỏi danh sách luôn thuộc về đơn vị vận hành danh sách.
Hướng dẫn này dựa trên các trang chính thức của Spamhaus, AWS, Google Cloud và Microsoft Azure tính đến tháng 11 năm 2026. Các hạn chế và quy trình có thể thay đổi, vì vậy hãy xác nhận nội dung hiện hành trước khi hành động. Để có cái nhìn tổng quát hơn về thư bị trả về liên quan đến danh sách đen, xem hướng dẫn của chúng tôi về email bị chặn bởi danh sách đen.
Trước hết, xác định IP nào và danh sách nào
"Máy chủ của tôi bị blacklist" có thể mang những ý nghĩa rất khác nhau, và cách khắc phục phụ thuộc vào chi tiết. Hãy trả lời ba câu hỏi trước khi làm bất cứ điều gì khác.
- IP nào thực sự gửi thư của bạn? IP lưu trữ trang web chưa chắc là IP gửi email của bạn. Hãy đọc thư báo lỗi (bounce), vốn thường trích dẫn IP bị từ chối, và kiểm tra các header Received của một thư bạn đã gửi để xác nhận địa chỉ gửi đi thực sự.
- Ai kiểm soát IP đó? Trên hosting chia sẻ, đó là địa chỉ dùng chung với các khách hàng khác. Trên máy chủ riêng, VPS hoặc máy ảo cloud, IP được gán cho bạn, dù dải địa chỉ xung quanh vẫn thuộc về nhà cung cấp. Gói hosting hoặc bảng điều khiển sẽ cho bạn biết thư gửi đi có dùng địa chỉ chung hay không.
- IP nằm trong danh sách nào? Mỗi danh sách có ý nghĩa khác nhau và người có thể khắc phục cũng khác nhau. Hãy chạy IP qua công cụ kiểm tra danh sách đen của chúng tôi để xem tất cả các danh sách lớn cùng lúc, và ghi lại tên danh sách cùng mã trả về.
Khi đã có ba câu trả lời đó, thường sẽ rõ đây là việc bạn tự khắc phục được, việc nhà cung cấp phải khắc phục, hay là dấu hiệu cho thấy bạn nên thay đổi hẳn cách gửi thư.
Đọc kết quả tra cứu và mã trả về
Spamhaus ZEN (zen.spamhaus.org) là danh sách IP tổng hợp của Spamhaus. Một IP bị liệt kê sẽ trả về một địa chỉ trong dải 127.0.0.x, và số cuối cho biết danh sách thành phần nào đã khớp. Với IP hosting chia sẻ và cloud, đây là những mã cần phân biệt:
| Mã trả về | Danh sách | Ý nghĩa thường gặp với hosting hoặc cloud |
|---|---|---|
| 127.0.0.2 | SBL | IP được xác định là độc hại. Yêu cầu gỡ phải do ISP hoặc công ty hosting quản lý IP đó gửi. |
| 127.0.0.3 | CSS | Bị liệt kê tự động do gửi thư có uy tín thấp. Hãy khắc phục nguyên nhân trước khi yêu cầu gỡ. |
| 127.0.0.4 | XBL | Có dấu hiệu bị xâm nhập. Hãy nghi ngờ có máy bị nhiễm hoặc trang web bị lợi dụng ở đâu đó trên IP. |
| 127.0.0.10 | PBL (do ISP duy trì) | Nhà mạng đã đánh dấu dải địa chỉ là dải không nên gửi thư trực tiếp. |
| 127.0.0.11 | PBL (do Spamhaus duy trì) | Cùng ý nghĩa về chính sách; có thể tự loại trừ nếu bạn đáp ứng các điều kiện. |
Mục PBL không phải là lời buộc tội. Đó là một tuyên bố chính sách rằng thư từ địa chỉ này nên được gửi, kèm xác thực, tới một máy chủ chuyển tiếp thư đi tiếp. Spamhaus tích cực khuyến khích các ISP và mạng khác liệt kê mọi dải địa chỉ không nên gửi thư, và điều này bao gồm rõ ràng cả máy chủ web.
Các mã 127.255.255.252, 127.255.255.254 và 127.255.255.255 là lỗi, không phải mục liệt kê. Câu hỏi thường gặp về cách dùng DNSBL của Spamhaus cũng cảnh báo rằng một resolver công cộng miễn phí như Google Public DNS (8.8.8.8) trong hầu hết trường hợp sẽ trả về "không bị liệt kê", đó là lý do các công cụ khác nhau có thể cho kết quả khác nhau. Khi còn nghi ngờ, hãy kiểm tra kết quả trên công cụ kiểm tra uy tín của chính Spamhaus. Để biết đầy đủ quy trình theo từng danh sách, xem cách gỡ khỏi Spamhaus.
Việc bạn tự khắc phục được và việc không thể
Bạn có thể thay đổi được bao nhiêu phụ thuộc vào dịch vụ bạn đang trả tiền.
| Loại hosting | Thường có thể tự khắc phục | Thường không thể tự khắc phục |
|---|---|---|
| Hosting chia sẻ (IP dùng chung) | Vấn đề trong chính tài khoản của bạn: mật khẩu hộp thư bị lộ, trang web bị tấn công, biểu mẫu liên hệ bị lợi dụng; SPF, DKIM và DMARC cho tên miền của bạn | Việc gửi thư của khách hàng khác, bản thân IP gửi đi, yêu cầu gỡ SBL, DNS ngược và HELO của máy chủ |
| VPS hoặc máy chủ riêng | Cấu hình hệ điều hành và máy chủ thư, DNS ngược và HELO khớp nhau, chính sách cổng 25 đi ra, dọn dẹp mã độc | Các mục liệt kê bao trùm cả dải địa chỉ của nhà cung cấp (chẳng hạn mục PBL do ISP duy trì) và chính sách mạng của nhà cung cấp |
| Máy ảo cloud | Tất cả những điều trên, cộng với việc chuyển thư gửi đi sang một dịch vụ gửi thư bên ngoài | Hạn chế cổng 25 của chính nền tảng, chỉ nhà cung cấp mới có thể gỡ bỏ |
Loại trừ khả năng lỗi từ chính tài khoản của bạn trên hosting chia sẻ
- Hộp thư bị chiếm quyền. Xem nhật ký gửi thư và thư mục thư đã gửi để tìm những đợt thư bạn không hề gửi. Đổi mật khẩu ngay nếu phát hiện.
- Trang web bị tấn công. Bản cài CMS và plugin lỗi thời là con đường phổ biến để kẻ tấn công tải lên các script gửi thư.
- Biểu mẫu bị lợi dụng. Biểu mẫu liên hệ có tính năng trả lời tự động cho phép người truy cập chọn người nhận hoặc nội dung thư có thể bị biến thành cỗ máy phát tán thư rác.
- Chất lượng danh sách nhận thư. Gửi thư tới danh sách mua lại hoặc tới những địa chỉ chưa từng đồng ý nhận là cách chắc chắn làm hỏng uy tín của IP dùng chung đối với tất cả mọi người, kể cả bạn.
Nếu không tìm thấy vấn đề nào ở trên, nguyên nhân nhiều khả năng là một người khác trên cùng địa chỉ. Câu hỏi thường gặp về cổng 25 của Spamhaus nói thẳng điều này: trên các nhóm IP dùng chung, phần lớn những người bị ảnh hưởng bởi một mục liệt kê không phải là người sở hữu thiết bị bị nhiễm. Trong trường hợp đó, phần việc của bạn là thu thập bằng chứng và chuyển cho nhà cung cấp.
Cách báo cho nhà cung cấp hosting
Spamhaus nêu rằng yêu cầu gỡ SBL phải do ISP quản lý IP bị liệt kê gửi, và khuyên người dùng thông thường trao đổi với ISP của mình để khắc phục. Với khách hàng hosting chia sẻ, ISP đó chính là công ty hosting của bạn. Một phiếu hỗ trợ chỉ ghi "email của tôi không đến được" thường bị chuyển qua lại. Phiếu hỗ trợ có đủ các thông tin sau thường được xử lý nhanh hơn:
- IP gửi thư, đã được xác nhận từ header hoặc thư báo lỗi.
- Danh sách và mã trả về, ví dụ zen.spamhaus.org trả về 127.0.0.2.
- Thời điểm và công cụ bạn đã dùng để kiểm tra, bao gồm kết quả của công cụ kiểm tra uy tín chính thức nếu bạn đã dùng.
- Nội dung thư báo lỗi, cụ thể là dòng mà máy chủ nhận giải thích lý do từ chối.
- Những gì bạn đã loại trừ, chẳng hạn đã đặt lại mật khẩu và quét trang web không thấy vấn đề.
- Điều bạn yêu cầu: điều tra, gửi yêu cầu gỡ tới đơn vị vận hành danh sách nếu phù hợp, hoặc chuyển thư gửi đi của tài khoản sang một IP khác.
Một ví dụ ngắn:
Our outbound IP 192.0.2.10 returns 127.0.0.2 (SBL) on zen.spamhaus.org.
We confirmed this on the official Spamhaus checker at 10:00 UTC on 2026-11-03.
We have reset all mailbox passwords and found no unexpected files on our site.
Please investigate, request removal if appropriate, or advise whether our mail
can be sent from a different IP.Nhà cung cấp có thể cần thời gian, và ngay cả khi họ đã hành động, đơn vị vận hành danh sách mới là bên quyết định cuối cùng. Nếu có thư không thể chờ, hãy xem phương án relay được mô tả bên dưới như một cách xử lý song song. Nếu bạn đang bế tắc trong việc xác định vấn đề nằm ở đâu, bạn cũng có thể nhờ chúng tôi hỗ trợ.
Hạn chế cổng 25 và DNS ngược trên VPS và cloud
Nếu bạn tự vận hành máy chủ thư trên VPS hoặc máy ảo cloud, bạn có thể gặp vấn đề trước cả khi danh sách đen nào đó xuất hiện: nhiều nhà cung cấp hạn chế cổng TCP 25 đi ra, cổng dùng để chuyển thư giữa các máy chủ với nhau. Tài liệu chính thức của AWS, Google Cloud và Microsoft Azure nói như sau.
- Amazon EC2 (AWS). Theo mặc định, EC2 chỉ cho phép lưu lượng cổng 25 đi ra tới các địa chỉ IPv4 riêng; lưu lượng tới địa chỉ IPv4 và IPv6 công cộng bị chặn. Bạn có thể yêu cầu gỡ bỏ hạn chế này. Đối với email gửi cho bên thứ ba, AWS khuyến nghị cấp phát địa chỉ Elastic IP và gán bản ghi DNS ngược tĩnh cho chúng, đồng thời lưu ý điều này có thể giúp tránh việc thư bị đánh dấu là thư rác. Bản ghi DNS thuận (A) phân giải tới Elastic IP phải tồn tại trước khi bạn tạo bản ghi ngược.
- Google Cloud (Compute Engine). Lưu lượng đi ra tới cổng TCP 25 trên các địa chỉ IP bên ngoài bị chặn theo mặc định. Hạn chế này được tự động gỡ bỏ khi Google Cloud xác định một dự án có rủi ro thấp, và bạn có thể kiểm tra trạng thái của dự án qua biểu ngữ trên trang VPC networks hoặc firewall policies trong console. SMTP qua TLS trên cổng 465 và 587 không thuộc phạm vi chặn. Google khuyến nghị dùng một nhà cung cấp email bên thứ ba đáng tin cậy, và cho biết điều này cải thiện uy tín IP của bạn.
- Microsoft Azure (máy ảo). Cổng 25 đi ra bị chặn với mọi loại gói đăng ký ngoại trừ Enterprise Agreement tiêu chuẩn và Microsoft Customer Agreement for enterprise (MCA-E). Gói đăng ký Enterprise Dev/Test bị chặn theo mặc định nhưng có thể được miễn trừ thông qua công cụ chẩn đoán trên portal. Dịch vụ SMTP relay có xác thực, thường trên cổng 587, không bị hạn chế với bất kỳ loại gói đăng ký nào, và Microsoft khuyến nghị dùng chúng. Ngay cả khi cổng 25 được mở, Microsoft lưu ý rằng không có gì bảo đảm các tên miền bên ngoài sẽ chấp nhận thư.
Cổng 25 bị chặn là vấn đề về chuyển phát, không phải vấn đề uy tín, và việc mở cổng không cải thiện gì cho uy tín IP của bạn. Nếu bạn thực sự muốn được loại trừ khỏi Spamhaus PBL cho một địa chỉ cloud hoặc VPS, IP đó phải là IP tĩnh, thực sự chạy máy chủ thư gửi đi, có DNS thuận và DNS ngược phù hợp, và được gán cho bạn. Spamhaus cũng yêu cầu cổng 25 đi ra phải được đóng đối với mọi thiết bị khác phía sau IP đó.
Chuyển sang IP riêng hoặc SMTP relay có xác thực
Nếu một IP dùng chung liên tục bị các "hàng xóm" kéo xuống, hoặc nhà cung cấp cloud không mở cổng 25, thay đổi cách gửi thư thường thực tế hơn là chạy theo các yêu cầu gỡ danh sách.
SMTP relay bên ngoài có xác thực
Thay vì để máy chủ của bạn chuyển thư thẳng tới người nhận, máy chủ sẽ chuyển từng thư cho một máy chủ gửi thư có xác thực để gửi thay bạn. Đây chính là mô hình Spamhaus mô tả cho các dải địa chỉ thuộc PBL: thư được kỳ vọng sẽ được gửi kèm xác thực tới một relay, có thể do ISP kết nối hoặc một dịch vụ thư bên ngoài vận hành. Câu hỏi thường gặp về cổng 25 của Spamhaus bổ sung rằng người dùng cuối nên dùng cổng 587 hoặc 465 với SMTP AUTH. Cả Azure và Google Cloud đều khuyến nghị relay có xác thực hoặc dịch vụ email bên thứ ba, và Microsoft lưu ý rằng các dịch vụ như vậy được dùng một phần để duy trì uy tín IP mà việc chuyển phát phụ thuộc vào.
- Cấu hình hostname, cổng (thường là 587) và thông tin đăng nhập của relay theo tài liệu của nhà cung cấp.
- Cập nhật bản ghi SPF của tên miền để bao gồm relay và thiết lập ký DKIM cho relay đó. Xem cách thiết lập SPF, DKIM và DMARC.
- Kiểm tra giới hạn gửi của relay trước khi chuyển lượng thư lớn sang.
IP riêng
IP riêng giúp bạn tách khỏi hành vi của các khách hàng khác, nhưng không tự động nâng cao uy tín. Hướng dẫn dành cho người gửi của Spamhaus liệt kê các yếu tố ảnh hưởng đến uy tín, bao gồm nhà cung cấp dịch vụ, các IP lân cận, hạ tầng phía sau địa chỉ và lịch sử của IP.
- Địa chỉ mới bị xem xét kỹ hơn. Cũng hướng dẫn đó cho biết các tên miền HELO chưa có lịch sử gửi thư sẽ bị lọc bổ sung, và một IP hoặc hostname HELO đã thay đổi nên được coi là mới và được làm nóng (warm-up) dần dần. Các dịch vụ warm-up tạo lưu lượng giả bị cấm.
- Đặt DNS ngược có ý nghĩa. Spamhaus cảnh báo rằng DNS ngược chung chung hoặc được tạo tự động trên IP riêng có thể làm giảm uy tín.
- Kiểm tra IP mới trước khi dùng. Một địa chỉ có thể còn mang mục liệt kê từ người dùng trước, vì vậy hãy tra cứu trước khi bắt đầu gửi thư.
Ngăn tình trạng này tái diễn
- Đồng bộ hostname, HELO và DNS ngược. Câu hỏi thường gặp về CSS của Spamhaus cho biết DNS thuận của IP nên khớp với giá trị HELO được đặt trên máy chủ, và HELO nên là một tên miền đầy đủ (FQDN). Tài liệu nêu các giá trị như localhost.localdomain là lỗi thường gặp.
- Chỉ cho phép máy chủ thư dùng cổng 25. Trên một VPS còn chạy các tác vụ khác, hãy đóng cổng 25 đi ra đối với mọi thứ không phải máy chủ thư của bạn.
- Giữ trang web và tài khoản được bảo vệ chặt chẽ. Cập nhật CMS và plugin, không dùng lại mật khẩu và bật xác thực hai yếu tố khi có thể.
- Xem lại thiết lập thư gửi đi trong bảng điều khiển. Câu hỏi thường gặp về CSS mô tả một tùy chọn của Plesk đưa tên riêng của từng tên miền vào lời chào SMTP. Tài liệu cảnh báo rằng khi nhiều tên miền trên máy chủ dùng chung một IP, thư từ một số hoặc tất cả các tên miền đó có thể bị bên nhận dùng Spamhaus XBL đánh dấu là thư rác, và tùy chọn này cần được dùng hết sức thận trọng. Hãy kiểm tra thiết lập tương đương trong bảng điều khiển của bạn và làm theo hướng dẫn của nhà cung cấp hoặc nhà phát triển bảng điều khiển.
- Theo dõi thường xuyên. Trạng thái của một IP dùng chung có thể thay đổi vì hành động của người khác. Hãy kiểm tra định kỳ bằng công cụ kiểm tra danh sách đen của chúng tôi và báo sớm cho nhà cung cấp khi có thay đổi.
Ngay cả sau khi được gỡ khỏi danh sách, bên nhận vẫn áp dụng bộ lọc riêng, nên việc chuyển phát có thể không phục hồi ngay. Mục liệt kê CSS thường hết hạn khoảng ba ngày sau lần phát hiện cuối cùng, nhưng IP sẽ bị liệt kê lại nếu vấn đề vẫn còn được phát hiện, và số lần tự gỡ bị giới hạn.
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
IP hosting chia sẻ của tôi bị blacklist. Tôi có thể tự yêu cầu gỡ không?
Còn tùy danh sách. Với Spamhaus SBL, yêu cầu gỡ phải do ISP hoặc công ty hosting quản lý IP gửi. Trên một địa chỉ dùng chung, nguyên nhân cũng có thể là khách hàng khác, nên cách thông thường là gửi cho nhà cung cấp kết quả tra cứu và mã trả về, rồi đề nghị họ xử lý.
IP của VPS hoàn toàn mới đã nằm trong PBL. Có gì sai không?
Không hẳn. PBL liệt kê các dải địa chỉ không nên gửi thư trực tiếp, và Spamhaus khuyến khích các mạng đưa cả máy chủ web vào. Hãy gửi qua relay có xác thực, hoặc nếu bạn chạy một máy chủ thư được cấu hình đúng trên IP tĩnh với DNS thuận và DNS ngược khớp nhau, hãy cân nhắc yêu cầu loại trừ.
Máy ảo cloud của tôi hoàn toàn không gửi được email. Có phải do danh sách đen?
Hãy kiểm tra cổng 25 trước. Theo mặc định, AWS và Google Cloud chặn cổng 25 đi ra tới các địa chỉ bên ngoài, còn Azure chặn cổng này với hầu hết các loại gói đăng ký. Google Cloud và Azure ghi nhận việc gửi có xác thực qua các cổng như 587 là phương án thay thế, còn AWS cho phép bạn yêu cầu gỡ bỏ hạn chế.
IP riêng có giúp tôi tránh bị blacklist không?
IP riêng loại bỏ rủi ro đến từ khách hàng khác, nhưng không có gì ngăn chặn hoàn toàn việc bị liệt kê. IP mới chưa có lịch sử có thể bị lọc bổ sung, vì vậy hãy làm nóng dần dần và đặt DNS ngược cùng HELO chính xác.
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.
- Spamhaus: Policy Blocklist (PBL)
- Spamhaus: Spamhaus Blocklist (SBL)
- Spamhaus FAQ: DNSBL Usage (return codes and public resolvers)
- Spamhaus FAQ: Combined Spam Sources (CSS)
- Spamhaus FAQ: Port 25 General Questions
- Spamhaus: Sender Guidelines
- AWS: Amazon EC2 service quotas (Restriction on email sent using port 25)
- AWS: Create a reverse DNS record for email on Amazon EC2
- Google Cloud: Sending email from an instance
- Google Cloud: VPC firewall rules (Blocked and limited traffic)
- Microsoft Learn: Troubleshoot outbound SMTP connectivity in Azure
Hướng dẫn liên quan
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.
Email bị chặn vì danh sách đen? Đọc mã lỗi trả lại, kiểm tra nguyên nhân theo đúng thứ tự, xác định danh sách nào quan trọng và yêu cầu gỡ đúng cách.
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.