中文 (中国)
English
Email bị Blacklist là một trong những nguyên nhân phổ biến khiến email doanh nghiệp không đến được Inbox, bị chuyển vào Spam hoặc bị máy chủ nhận từ chối.
Tình trạng này có thể xảy ra với:
- Địa chỉ IP Mail Server
- Tên miền gửi email
- Domain trong nội dung email
- Email account
- SMTP server
- Shared Mail Server
- Dedicated Mail Server
Đặc biệt, nếu doanh nghiệp tự vận hành Mail Server trên VPS hoặc Dedicated Server, việc quản lý IP reputation, domain reputation, PTR/rDNS, SPF, DKIM, DMARC và hành vi gửi email là yếu tố rất quan trọng.
Một IP bị đưa vào blacklist không đồng nghĩa toàn bộ email chắc chắn bị chặn ở mọi nơi. Mỗi nhà cung cấp email có hệ thống đánh giá reputation và chính sách lọc riêng. Vì vậy, cần xác định chính xác IP nào bị blacklist, blacklist nào đang liệt kê và nguyên nhân là gì trước khi tiến hành xử lý.
Trong bài viết này, DataOnline sẽ phân tích:
- Email Blacklist là gì?
- IP Blacklist và Domain Blacklist khác nhau thế nào?
- 15 nguyên nhân khiến email bị blacklist
- Vì sao Mail Server mới cũng có thể bị blacklist?
- Shared IP ảnh hưởng đến email như thế nào?
- SPF, DKIM, DMARC có liên quan gì đến blacklist?
- PTR/rDNS và HELO ảnh hưởng đến email ra sao?
- Cách kiểm tra IP có nằm trong Email Blacklist
- Cách kiểm tra Domain Blacklist
- Cách xử lý khi IP bị blacklist
- Cách gửi yêu cầu delist
- Cách phòng tránh Mail Server bị blacklist trở lại
DataOnline cung cấp dịch vụ Email,cũng được cung cấp bản ghi PTR (phân giải ngược) để tăng độ trust cho email.
1. Email Blacklist là gì?
Email Blacklist, Email Blocklist hoặc DNSBL/RBL là các danh sách được sử dụng để nhận diện những IP, domain hoặc nguồn gửi có reputation xấu hoặc liên quan đến spam, malware, phishing hay các hành vi lạm dụng email.
Các hệ thống nhận email có thể sử dụng nhiều nguồn dữ liệu khác nhau để quyết định:
Email
↓
Mail Server nhận
↓
Kiểm tra IP Reputation
↓
Kiểm tra Domain Reputation
↓
SPF / DKIM / DMARC
↓
PTR / rDNS / HELO
↓
Sender Reputation
↓
Spam / Abuse Signals
↓
Inbox / Spam / Reject
Một trong những hệ thống reputation nổi tiếng là Spamhaus. Spamhaus duy trì các blocklist dành cho IP và domain có liên quan đến spam hoặc hoạt động độc hại. Ví dụ, SBL chứa các IP được xác định có liên quan đến spam hoặc abuse, trong khi DBL tập trung vào domain có reputation xấu.
Do đó, khi nói:
“Email của tôi bị blacklist”
cần xác định chính xác đang nói đến:
IP bị blacklist, domain bị blacklist hay email đang có sender reputation thấp.
Ba vấn đề này không hoàn toàn giống nhau.
2. IP Blacklist và Domain Blacklist khác nhau thế nào?
IP Blacklist
IP của Mail Server bị đưa vào danh sách chặn.
Ví dụ:
Mail Server
mail.example.com
203.0.113.10
Nếu IP:
203.0.113.10
có reputation xấu, một số hệ thống nhận email có thể từ chối hoặc giảm độ tin cậy đối với email gửi từ IP này.
IP blacklist thường liên quan đến:
- Spam volume lớn
- Compromised account
- Malware
- Open relay
- SMTP abuse
- IP reputation kém
- Shared hosting/mail infrastructure
- Previous owner của IP đã gửi spam
Domain Blacklist
Domain gửi email hoặc domain xuất hiện trong nội dung email bị đánh giá có reputation xấu.
Ví dụ:
example.com
Domain reputation có thể bị ảnh hưởng bởi:
- Phishing
- Malware
- Spam
- Website bị hack
- Link độc hại
- Domain mới gửi email với volume lớn
- Domain bị lạm dụng làm redirect/link tracking
Spamhaus DBL là ví dụ về hệ thống đánh giá domain reputation và có thể liệt kê các domain liên quan đến spam, phishing, malware hoặc hoạt động đáng ngờ.
3. Email bị Blacklist có phải lúc nào cũng không gửi được?
Không.
Đây là một hiểu nhầm khá phổ biến.
Ví dụ:
IP bị blacklist tại List A
nhưng:
Gmail → nhận
Microsoft → nhận
Yahoo → Spam
Provider X → Reject
Mỗi hệ thống mail có thể sử dụng các reputation database và thuật toán riêng.
Ngoài ra, việc không nằm trong blacklist cũng không đảm bảo email chắc chắn vào Inbox.
Một email có thể:
Không blacklist
↓
SPF PASS
DKIM PASS
DMARC PASS
↓
Spam
vì hệ thống nhận còn đánh giá:
- Sender reputation
- User complaints
- Engagement
- Bounce rate
- Sending behavior
- Content
- Domain reputation
- IP reputation
- Authentication
- Historical behavior
Do đó, Blacklist chỉ là một trong nhiều tín hiệu ảnh hưởng đến Email Deliverability.
4. 15 nguyên nhân khiến Email bị Blacklist
4.1. Mail Server gửi Spam
Đây là nguyên nhân phổ biến nhất.
Ví dụ một tài khoản:
sales@example.com
bị lộ mật khẩu.
Kẻ tấn công sử dụng tài khoản này gửi:
10.000 email
50.000 email
100.000 email
trong thời gian ngắn.
Mail Server nhanh chóng tạo reputation xấu.
Tệ hơn, nếu hệ thống không có rate limit:
1 account bị hack
↓
SMTP relay
↓
Hàng trăm nghìn email
↓
IP reputation giảm
↓
Blacklist
4.2. Tài khoản email bị hack
Đây là nguyên nhân rất thường gặp khi doanh nghiệp tự vận hành Mail Server.
Ví dụ:
user@example.com
Password: abc123456
Người dùng sử dụng mật khẩu yếu hoặc dùng lại mật khẩu từ một website khác.
Khi password bị lộ, attacker có thể đăng nhập SMTP và gửi spam.
Điểm quan trọng:
Mail Server không nhất thiết bị hack hoàn toàn. Chỉ cần một tài khoản SMTP bị compromise cũng có thể làm reputation của IP bị ảnh hưởng.
Nên kiểm tra:
SMTP authentication logs
IMAP login
POP3 login
Webmail login
Failed authentication
Successful authentication
4.3. Gửi email với volume tăng đột biến
Ví dụ Mail Server bình thường:
100 email/ngày
nhưng đột nhiên:
50.000 email trong 1 giờ
Đây là behavior rất khác thường.
Đặc biệt với IP mới, việc tăng volume quá nhanh có thể khiến reputation xấu.
Ví dụ:
Ngày 1: 50 email
Ngày 2: 100 email
Ngày 3: 500 email
Ngày 4: 50.000 email
Cách làm này có rủi ro cao hơn so với việc xây dựng volume gửi email một cách ổn định.
4.4. Gửi email tới danh sách không chất lượng
Một database email có thể chứa:
Email không tồn tại
Email hết hạn
Email spam trap
Email sai
Email không còn sử dụng
Nếu gửi số lượng lớn tới những địa chỉ này, tỷ lệ bounce tăng.
Ví dụ:
100.000 email
30.000 bounce
đây là tín hiệu rất xấu.
Do đó không nên mua database email trôi nổi để gửi marketing.
4.5. Người nhận đánh dấu email là Spam
Một trong những tín hiệu quan trọng là complaint.
Ví dụ:
10.000 email gửi đi
500 người đánh dấu Spam
Tỷ lệ complaint rất cao.
Điều này có thể làm reputation của sender giảm.
Google hiện yêu cầu các sender gửi tới Gmail duy trì spam rate trong Postmaster Tools dưới 0,3%; với sender lớn, việc kiểm soát spam complaint là một yêu cầu quan trọng đối với deliverability.
4.6. SPF cấu hình sai
SPF cho phép domain công bố những server/IP nào được phép gửi email thay mặt domain.
Ví dụ:
example.com
có Mail Server:
203.0.113.10
SPF có thể chứa IP hoặc cơ chế phù hợp để xác định nguồn gửi hợp lệ.
Nếu SPF sai:
Email Server
↓
SPF Check
↓
FAIL
thì email có thể gặp vấn đề về authentication và deliverability.
Tuy nhiên cần phân biệt:
SPF fail không đồng nghĩa chắc chắn IP bị blacklist.
Nó là một yếu tố trong quá trình đánh giá email.
4.7. DKIM không được cấu hình
DKIM sử dụng chữ ký mật mã để giúp máy chủ nhận xác minh email có thực sự được gửi bởi hệ thống được domain ủy quyền hay không.
Ví dụ:
Email
↓
Mail Server
↓
DKIM Sign
↓
Recipient
↓
DKIM Verify
Nếu DKIM được triển khai đúng, email có thêm một tín hiệu xác thực quan trọng.
Với Gmail, sender hiện phải có ít nhất SPF hoặc DKIM; sender lớn trên 5.000 email/ngày tới Gmail phải triển khai cả SPF, DKIM và DMARC.
4.8. DMARC không được cấu hình
DMARC giúp domain xác định cách xử lý email không vượt qua authentication và quan trọng hơn là thiết lập alignment giữa domain trong From header với SPF hoặc DKIM.
Ví dụ:
From:
user@example.com
nhưng email thực tế được xác thực bằng một domain hoàn toàn khác.
Đây là vấn đề liên quan đến spoofing và phishing.
Một DMARC record cơ bản có thể có dạng:
v=DMARC1; p=none; rua=mailto:dmarc@example.com
Sau khi thu thập báo cáo và xác nhận hệ thống gửi hoạt động đúng, doanh nghiệp có thể cân nhắc nâng policy.
Với sender gửi trên 5.000 email/ngày tới Gmail, Google yêu cầu DMARC và yêu cầu domain trong From phải align với SPF hoặc DKIM đối với email gửi trực tiếp.
4.9. PTR/rDNS không chính xác
Đây là vấn đề rất quan trọng đối với Mail Server tự vận hành.
Ví dụ:
IP:
203.0.113.10
PTR:
mail.example.com
Sau đó:
mail.example.com
↓
203.0.113.10
Forward DNS và Reverse DNS nên được cấu hình hợp lý.
Google hiện yêu cầu sender tới Gmail có forward và reverse DNS hợp lệ.
Spamhaus cũng lưu ý rằng một IP chạy outbound mail server cần có forward DNS và reverse DNS phù hợp khi xem xét việc loại IP khỏi PBL.
Vì vậy nếu bạn chạy Mail Server trên VPS/Dedicated Server, cần đặc biệt quan tâm tới:
A Record
PTR Record
HELO/EHLO
Hostname
4.10. HELO/EHLO không hợp lệ
Khi Mail Server kết nối tới SMTP server khác, nó thường gửi:
EHLO mail.example.com
Nếu hostname:
localhost
server
unknown
vps
123.123.123.123
hoặc hostname không liên quan tới DNS của server, reputation có thể bị ảnh hưởng.
Một cấu hình chuyên nghiệp thường có:
Hostname:
mail.example.com
PTR:
203.0.113.10 → mail.example.com
A:
mail.example.com → 203.0.113.10
4.11. Open Relay
Open Relay là một lỗi cấu hình nghiêm trọng.
Mail Server bị cấu hình cho phép bên ngoài sử dụng server để relay email mà không cần authentication hợp lệ.
Khi đó:
Attacker
↓
Your Mail Server
↓
Internet
↓
Millions of spam emails
Đây là tình huống cần xử lý ngay.
Mail Server hiện đại nên:
- Không cho phép anonymous relay.
- Yêu cầu SMTP authentication đối với user submission.
- Giới hạn relay theo network/domain.
- Theo dõi SMTP queue.
- Giới hạn số email gửi.
4.12. Website hoặc CMS bị hack
Không phải lúc nào spam cũng xuất phát từ Mail Server.
Ví dụ WordPress bị hack:
Website
↓
PHP malware
↓
Sendmail / SMTP
↓
Spam
Hoặc attacker upload một script:
mailer.php
send.php
wp-mail.php
và sử dụng server để gửi hàng loạt email.
Nếu IP bị blacklist, cần kiểm tra cả:
Website
WordPress
PHP
Cron
SMTP
System users
4.13. Máy chủ bị nhiễm Malware
Server có thể bị malware hoặc webshell.
Ví dụ:
Malware
↓
SMTP connection
↓
Spam
Dấu hiệu:
CPU tăng
SMTP connection tăng
Mail queue tăng
Unknown process
Unknown cron
Unknown PHP script
Nếu chỉ xóa blacklist nhưng không xử lý malware, IP có thể bị blacklist trở lại.
4.14. Dùng Shared Mail Server / Shared IP
Đây là vấn đề quan trọng khi sử dụng Mail Server chung.
Ví dụ:
Mail Server
203.0.113.10
|
+-- company-a.com
+-- company-b.com
+-- company-c.com
+-- company-d.com
Nếu:
company-c.com
gửi spam quá nhiều, reputation của IP chung có thể bị ảnh hưởng.
Khi đó các domain khác có thể gặp:
Spam
Reject
Rate limit
Poor deliverability
Đây là một trong những lý do doanh nghiệp có nhu cầu email quan trọng thường cân nhắc IP reputation riêng hoặc sử dụng ESP chuyên nghiệp.
4.15. Domain mới nhưng gửi volume lớn ngay lập tức
Một domain mới:
example-new.com
vừa được tạo đã gửi:
100.000 email/ngày
là behavior bất thường.
Domain reputation cần thời gian để hình thành.
Spamhaus cũng lưu ý rằng reputation được xây dựng theo thời gian và một domain chưa có reputation có thể có rủi ro cao hơn domain đã có lịch sử tốt.
5. Tại sao IP mới thuê vẫn có thể bị Blacklist?
Đây là câu hỏi rất phổ biến khi thuê VPS.
Bạn thuê:
VPS
IP: 203.0.113.10
nhưng kiểm tra thấy IP đã có reputation xấu.
Nguyên nhân có thể là:
Previous customer
Previous spam
Previous malware
Previous Mail Server
Previous abuse
IP range reputation
Đặc biệt với IP được tái sử dụng, lịch sử của IP có thể ảnh hưởng tới khả năng gửi email.
Vì vậy trước khi triển khai Mail Server production, nên kiểm tra:
IP Reputation
DNSBL
PTR
rDNS
SMTP
Port 25
6. Cách kiểm tra IP có bị Email Blacklist hay không
Một trong những cách đơn giản nhất là sử dụng các dịch vụ kiểm tra blacklist.
Có thể sử dụng:
- MXToolbox
- Spamhaus IP & Domain Reputation Checker
- MultiRBL
- DNSBL checker
Spamhaus hiện cung cấp IP & Domain Reputation Checker để kiểm tra IP/domain có nằm trong các DNSBL của Spamhaus hay không, đồng thời cung cấp thông tin troubleshooting và hướng xử lý.
Khi kiểm tra nên nhập:
Mail Server IP
Ví dụ:
203.0.113.10
Không chỉ kiểm tra domain.
7. Kiểm tra Domain Blacklist
Nếu IP sạch nhưng email vẫn vào Spam, hãy kiểm tra domain:
example.com
Đặc biệt nếu email có chứa link:
https://example.com
thì domain reputation cũng cần được kiểm tra.
Một domain có reputation xấu có thể ảnh hưởng đến khả năng deliverability ngay cả khi IP gửi email hoàn toàn sạch.
8. Kiểm tra PTR/rDNS
Linux:
dig -x 203.0.113.10
Kết quả mong muốn:
203.0.113.10
↓
mail.example.com
Kiểm tra A:
dig mail.example.com A
Kết quả:
mail.example.com
↓
203.0.113.10
Tốt nhất:
A:
mail.example.com → 203.0.113.10
PTR:
203.0.113.10 → mail.example.com
9. Kiểm tra SPF
dig example.com TXT
Tìm:
v=spf1
Ví dụ:
v=spf1 ip4:203.0.113.10 -all
Nếu sử dụng nhiều hệ thống gửi email:
Mail Server
+
Amazon SES
+
Google Workspace
SPF cần được thiết kế phù hợp với toàn bộ hệ thống gửi.
Không nên tạo nhiều SPF TXT record cho cùng một domain.
10. Kiểm tra DKIM
Ví dụ selector:
default
Kiểm tra:
dig default._domainkey.example.com TXT
Nếu sử dụng selector:
mail2026
thì:
dig mail2026._domainkey.example.com TXT
Cần đảm bảo DKIM public key tồn tại và đúng với private key trên Mail Server.
11. Kiểm tra DMARC
dig _dmarc.example.com TXT
Ví dụ:
v=DMARC1; p=none; rua=mailto:dmarc@example.com
Có thể bắt đầu với:
p=none
để quan sát.
Sau khi hệ thống ổn định, có thể triển khai policy nghiêm ngặt hơn tùy mô hình:
p=quarantine
hoặc:
p=reject
12. Kiểm tra SMTP port 25
Nếu tự vận hành Mail Server, cần kiểm tra outbound SMTP.
Ví dụ:
nc -vz gmail-smtp-in.l.google.com 25
Hoặc:
telnet gmail-smtp-in.l.google.com 25
Nếu không kết nối được, có thể do:
Provider block port 25
Firewall
Network policy
IP reputation
Một số nhà cung cấp VPS/Dedicated Server có chính sách hạn chế SMTP port 25.
13. Kiểm tra Mail Queue
Nếu sử dụng Postfix:
postqueue -p
Hoặc:
mailq
Nếu queue bình thường:
Mail queue = vài email
nhưng đột nhiên:
10.000
50.000
100.000
thì cần điều tra ngay.
Kiểm tra:
postqueue -p | tail
Tìm sender:
mailq | grep '@'
Nếu sử dụng Exim:
exim -bp
và:
exim -bpc
14. Kiểm tra log Mail Server
Với Postfix:
tail -f /var/log/mail.log
Tìm authentication:
grep -i "sasl" /var/log/mail.log
Tìm failed login:
grep -i "authentication failure" /var/log/mail.log
Với Exim:
tail -f /var/log/exim4/mainlog
Nếu phát hiện:
user@example.com
gửi hàng nghìn email, cần khóa hoặc reset password account ngay.
15. Làm gì khi Email Server bị Blacklist?
Không nên làm theo cách:
Blacklist
↓
Request delist
↓
Xong
Đây là cách xử lý sai.
Quy trình đúng:
Blacklist
↓
Xác định blacklist nào
↓
Xác định nguyên nhân
↓
Ngăn spam tiếp diễn
↓
Fix Mail Server
↓
Reset compromised account
↓
Fix DNS
↓
Fix authentication
↓
Kiểm tra queue/log
↓
Request delisting
↓
Theo dõi reputation
Nếu nguyên nhân chưa được xử lý, việc delist chỉ mang tính tạm thời.
16. Bước 1: Xác định nguyên nhân
Kiểm tra:
Mail Queue
SMTP Logs
Authentication Logs
Web Logs
Cron
Running Processes
Outbound Traffic
DNS
SPF
DKIM
DMARC
PTR
17. Bước 2: Khóa tài khoản bị compromise
Nếu phát hiện:
user@example.com
đang gửi spam:
Disable account
Reset password
Revoke sessions
Enable MFA
Check forwarding rules
Check mailbox rules
Không nên chỉ block IP attacker vì attacker có thể sử dụng nhiều IP khác nhau.
18. Bước 3: Kiểm tra Open Relay
Đảm bảo server không cho phép anonymous relay.
SMTP submission cho user nên yêu cầu:
Authentication
+
TLS
Spamhaus cũng khuyến nghị hệ thống end-user mail submission sử dụng kết nối được xác thực và mã hóa, chẳng hạn port 465 hoặc 587.
19. Bước 4: Kiểm tra Malware
Kiểm tra:
ps aux
crontab -l
ls -lah /etc/cron.*
Kiểm tra website:
WordPress
Plugin
Theme
PHP files
Upload directory
Webshell
Nếu server có DirectAdmin, nên kiểm tra toàn bộ user/domain thay vì chỉ kiểm tra một domain.
20. Bước 5: Kiểm tra SPF/DKIM/DMARC
Mục tiêu:
SPF = PASS
DKIM = PASS
DMARC = PASS
Đồng thời phải đảm bảo domain alignment phù hợp.
21. Bước 6: Kiểm tra PTR và HELO
Ví dụ:
IP:
203.0.113.10
PTR:
mail.example.com
A:
mail.example.com → 203.0.113.10
HELO:
mail.example.com
Đây là cấu hình tốt hơn rất nhiều so với:
PTR:
server123.provider.local
HELO:
localhost
22. Bước 7: Request Delisting
Sau khi xử lý nguyên nhân, thực hiện request delist theo hướng dẫn của chính blacklist đó.
Với Spamhaus, IP/domain nên được kiểm tra bằng IP & Domain Reputation Checker và thực hiện theo hướng dẫn được cung cấp cho listing cụ thể.
Đối với một số SBL listing, việc xử lý phải thông qua ISP/network owner quản lý IP. Spamhaus nêu rõ rằng network owner/ISP chịu trách nhiệm xử lý và yêu cầu removal đối với các trường hợp SBL phù hợp.
Không nên thuê các dịch vụ quảng cáo kiểu:
“Xóa Spamhaus blacklist trong 5 phút”
Spamhaus cho biết việc removal không thu phí và cảnh báo các dịch vụ thu tiền để “xóa Spamhaus listing” không có quyền đặc biệt để tác động hoặc đẩy nhanh quá trình removal.
23. Có nên đổi IP Mail Server không?
Có thể, nhưng không phải giải pháp đầu tiên.
Nếu nguyên nhân là:
IP reputation quá xấu
và đã xử lý hoàn toàn nguyên nhân nhưng IP vẫn gây khó khăn cho deliverability, có thể cân nhắc IP mới.
Tuy nhiên:
IP mới
+
Domain cũ
+
Spam behavior cũ
thì vẫn có thể gặp vấn đề.
Đổi IP mà không xử lý:
Compromised account
Malware
Open relay
Spam campaign
Bad list
thì IP mới cũng có thể bị blacklist.
24. Khi nào nên sử dụng IP riêng cho Mail Server?
Nếu doanh nghiệp có nhu cầu:
Transactional Email
Order Email
Invoice
OTP
Customer Notification
Business Email
thì IP riêng có thể giúp dễ quản lý reputation hơn so với shared IP.
Ví dụ:
Mail Server A
IP A
Domain A
Mail Server B
IP B
Domain B
Nếu hệ thống gửi email marketing lớn, có thể tách:
Transactional Email
↓
IP / Subdomain A
Marketing Email
↓
IP / Subdomain B
Mục tiêu là hạn chế việc reputation của một loại traffic ảnh hưởng tới loại traffic khác.
25. Tách domain gửi email marketing
Thay vì:
example.com
có thể sử dụng mô hình:
example.com
|
+--- Transactional
|
+--- Marketing
Ví dụ:
mail.example.com
news.example.com
Tùy chiến lược reputation và hệ thống gửi, có thể sử dụng subdomain riêng cho email marketing.
26. Không dùng Mail Server thông thường để gửi email marketing số lượng lớn
Nếu cần gửi:
10.000
50.000
100.000
1.000.000 email
không nên chỉ cài Postfix/Exim rồi bắt đầu gửi hàng loạt.
Email marketing cần:
List Management
Bounce Processing
Unsubscribe
Complaint Handling
Rate Control
IP Reputation
Domain Reputation
Feedback Monitoring
Authentication
Các ESP chuyên dụng thường cung cấp những cơ chế này.
Mail Server doanh nghiệp phù hợp hơn với:
Business Email
Transactional Email
Internal Email
Customer Notification
trong khi email marketing quy mô lớn nên được thiết kế thành một hệ thống riêng.
27. Warm-up IP là gì?
IP mới không nên lập tức gửi volume cực lớn.
Ví dụ không nên:
Ngày 1
100 email
Ngày 2
100.000 email
Thay vào đó cần tăng volume có kiểm soát và theo dõi:
Delivery
Bounce
Complaint
Engagement
Reputation
Mục tiêu là xây dựng lịch sử gửi ổn định.
28. Các nguyên tắc giúp Email không bị Blacklist
1. Không gửi spam
Chỉ gửi cho người thực sự đăng ký nhận email.
2. Không mua database email
Database mua ngoài thường có:
Invalid email
Spam trap
Inactive email
Complaint
3. Cấu hình SPF
Kiểm tra:
dig example.com TXT
4. Cấu hình DKIM
Kiểm tra:
dig selector._domainkey.example.com TXT
5. Cấu hình DMARC
Kiểm tra:
dig _dmarc.example.com TXT
6. Cấu hình PTR
Đảm bảo:
IP → hostname
hostname → IP
7. HELO hợp lệ
Ví dụ:
mail.example.com
8. Không Open Relay
SMTP relay phải được kiểm soát.
9. Giới hạn tốc độ gửi
Ví dụ:
Per account
Per domain
Per IP
Per hour
Per day
10. Theo dõi Mail Queue
Queue tăng đột biến phải được cảnh báo.
11. Theo dõi SMTP authentication
Phát hiện login bất thường.
12. Bảo mật tài khoản
Sử dụng:
Password mạnh
MFA
SMTP AUTH
TLS
13. Cập nhật Mail Server
Luôn cập nhật:
Postfix
Exim
Dovecot
Roundcube
DirectAdmin
OS
CMS
14. Theo dõi IP reputation
Kiểm tra định kỳ:
IP
Domain
DNSBL
15. Theo dõi spam complaint
Đây là một trong những chỉ số quan trọng đối với sender reputation.
29. Checklist Mail Server trước khi đưa vào Production
[ ] Static Public IP
[ ] PTR/rDNS
[ ] A record
[ ] Hostname
[ ] HELO/EHLO
[ ] SPF
[ ] DKIM
[ ] DMARC
[ ] TLS
[ ] SMTP Authentication
[ ] Không Open Relay
[ ] Port 25 hoạt động
[ ] Port 465/587 cho submission
[ ] Mail Queue monitoring
[ ] SMTP login monitoring
[ ] Malware scanning
[ ] Backup
[ ] IP blacklist check
[ ] Domain blacklist check
[ ] Bounce monitoring
[ ] Spam complaint monitoring
[ ] Rate limit
30. Checklist xử lý khi IP đã bị Blacklist
[ ] Xác định IP bị blacklist
[ ] Xác định blacklist nào
[ ] Đọc lý do listing
[ ] Kiểm tra Mail Queue
[ ] Kiểm tra SMTP logs
[ ] Kiểm tra account bị hack
[ ] Reset password
[ ] Kiểm tra malware
[ ] Kiểm tra website/CMS
[ ] Kiểm tra Open Relay
[ ] Kiểm tra SPF
[ ] Kiểm tra DKIM
[ ] Kiểm tra DMARC
[ ] Kiểm tra PTR
[ ] Kiểm tra HELO
[ ] Ngừng nguồn spam
[ ] Theo dõi traffic outbound
[ ] Request delisting
[ ] Monitor reputation sau khi delist
31. Email bị vào Spam nhưng IP không Blacklist phải làm gì?
Đây là trường hợp rất phổ biến.
Nếu:
Blacklist = Clean
nhưng:
Inbox = Spam
hãy kiểm tra tiếp:
SPF
DKIM
DMARC
PTR
HELO
Domain reputation
IP reputation
Bounce rate
Complaint rate
Email content
Sending volume
Recipient engagement
Không nên chỉ kiểm tra blacklist.
Đặc biệt với Gmail, Google yêu cầu sender phải đáp ứng các yêu cầu về authentication, DNS, TLS và spam rate; với sender lớn còn có thêm yêu cầu DMARC và alignment.
32. Email bị reject khác gì Email bị Spam?
Reject
Mail Server nhận từ chối email.
Ví dụ:
550
554
421
Nguyên nhân có thể là:
IP reputation
Blacklist
Authentication
Rate limit
Policy
Invalid recipient
Spam
Email vẫn được nhận nhưng đưa vào:
Spam
Junk
Bulk
Điều này thường liên quan đến nhiều yếu tố reputation và filtering.
Do đó:
Blacklist ≠ Spam
Blacklist ≠ Email không gửi được
33. Domain và IP có thể ảnh hưởng lẫn nhau
Một hệ thống email chuyên nghiệp cần quản lý cả:
IP Reputation
+
Domain Reputation
Ví dụ:
IP sạch
Domain xấu
↓
Deliverability vẫn có thể kém
Hoặc:
Domain tốt
IP xấu
↓
Deliverability vẫn có thể kém
Spamhaus cũng lưu ý rằng IP reputation và domain reputation có mối quan hệ với nhau và domain reputation được xây dựng theo thời gian.
34. Mô hình Mail Server chuẩn cho doanh nghiệp
Một mô hình cơ bản:
INTERNET
|
|
+---------------+
| Mail Gateway |
+-------+-------+
|
SMTP/TLS
|
+-------+-------+
| Mail Server |
+-------+-------+
| |
DKIM Queue
|
SPF/DMARC
|
DNS/PTR
Đối với hệ thống lớn hơn:
Internet
|
+---------+---------+
| |
Transactional Marketing
| |
IP Pool A IP Pool B
| |
Domain A Subdomain B
Mô hình này giúp phân tách các loại email và dễ quản lý reputation hơn.
35. Kết luận
Email Blacklist không phải là một lỗi đơn lẻ mà là kết quả của nhiều yếu tố liên quan đến IP reputation, domain reputation, authentication và hành vi gửi email.
Những nguyên nhân thường gặp nhất gồm:
- Gửi Spam.
- Tài khoản email bị hack.
- Volume gửi tăng đột biến.
- Database email kém chất lượng.
- Spam complaint cao.
- SPF sai.
- DKIM sai hoặc thiếu.
- DMARC thiếu hoặc cấu hình sai.
- PTR/rDNS không hợp lệ.
- HELO/EHLO không phù hợp.
- Open Relay.
- Website/CMS bị hack.
- Server nhiễm malware.
- Shared IP có reputation xấu.
- Domain/IP có lịch sử gửi email xấu.
Khi xử lý Email Blacklist, không nên chỉ đổi IP hoặc gửi yêu cầu delist. Cần xác định và loại bỏ nguyên nhân gây abuse trước, sau đó mới tiến hành delisting.
Đối với Mail Server tự triển khai trên VPS hoặc Dedicated Server, tối thiểu nên đảm bảo:
PTR/rDNS
+
SPF
+
DKIM
+
DMARC
+
TLS
+
SMTP Authentication
+
Không Open Relay
+
Rate Limit
+
Monitoring
Gmail hiện yêu cầu các sender có SPF hoặc DKIM, forward/reverse DNS hợp lệ và TLS; sender gửi trên 5.000 email/ngày tới Gmail còn phải có SPF, DKIM, DMARC và đáp ứng DMARC alignment.
Đồng thời, nên thường xuyên kiểm tra IP và domain trên các hệ thống reputation. Spamhaus hiện cung cấp công cụ kiểm tra IP/domain để xác định listing, nguyên nhân và hướng xử lý; với một số SBL listing, việc removal cần được thực hiện thông qua network owner/ISP quản lý IP.
Một hệ thống email tốt không chỉ là “gửi được email”, mà phải đảm bảo email đến đúng người nhận, đúng Inbox và duy trì reputation ổn định trong thời gian dài.
FAQ – Câu hỏi thường gặp về Email Blacklist
Email bị Blacklist có gửi được không?
Có thể. Việc một IP hoặc domain nằm trong một blacklist không đồng nghĩa tất cả nhà cung cấp email đều chặn email từ nguồn đó. Tuy nhiên, reputation xấu có thể làm tăng nguy cơ reject hoặc vào Spam.
Làm sao biết IP Mail Server có bị Blacklist?
Sử dụng các công cụ kiểm tra IP reputation như Spamhaus IP & Domain Reputation Checker hoặc các DNSBL checker. Spamhaus cho phép kiểm tra IP/domain và cung cấp thông tin về listing cũng như hướng xử lý.
Đổi IP có hết Blacklist không?
Không nhất thiết. Nếu nguyên nhân như tài khoản bị hack, malware, open relay hoặc spam vẫn còn, IP mới có thể tiếp tục bị đánh giá xấu.
SPF, DKIM và DMARC có giúp chống Blacklist không?
Có thể giúp cải thiện authentication và sender trust, nhưng không phải “lá chắn chống blacklist”. Bạn vẫn phải kiểm soát spam, bounce, complaint, volume và bảo mật Mail Server.
PTR có quan trọng khi chạy Mail Server không?
Có. PTR/rDNS giúp xây dựng danh tính hợp lệ cho IP gửi email. Google yêu cầu sender tới Gmail có forward và reverse DNS hợp lệ.
Có nên dùng VPS để chạy Mail Server không?
Có thể, nếu VPS có IP sạch, PTR/rDNS, port 25 được phép, network ổn định và nhà cung cấp cho phép SMTP. Tuy nhiên cần tự chịu trách nhiệm về reputation, security và deliverability.
Có nên dùng IP riêng cho Mail Server?
Nếu email là dịch vụ quan trọng của doanh nghiệp, IP riêng giúp dễ kiểm soát reputation hơn so với việc dùng chung IP với nhiều hệ thống hoặc khách hàng khác.
Spamhaus có thu phí để xóa blacklist không?
Spamhaus cho biết việc removal khỏi các listing của họ không có phí và cảnh báo các dịch vụ tuyên bố có thể trả tiền để “xóa” hoặc đẩy nhanh Spamhaus listing.
Bao lâu thì Email Blacklist được gỡ?
Không có một thời gian cố định cho tất cả blacklist. Thời gian phụ thuộc vào từng danh sách, nguyên nhân, việc đã xử lý abuse hay chưa và quy trình removal của đơn vị quản lý blacklist.
Email không bị Blacklist nhưng vẫn vào Spam, tại sao?
Vì blacklist chỉ là một tín hiệu. Hệ thống nhận còn đánh giá sender reputation, domain reputation, authentication, spam complaint, bounce, nội dung, volume gửi và hành vi người nhận.
Thông tin SEO đề xuất
SEO Title:
Email bị Blacklist là gì? 15 nguyên nhân & cách xử lý hiệu quả
Meta Description:
Email bị Blacklist khiến email vào Spam hoặc bị từ chối? Tìm hiểu 15 nguyên nhân, cách kiểm tra IP/domain blacklist, SPF, DKIM, DMARC, PTR và cách xử lý Email Blacklist.
URL Slug:
nguyen-nhan-email-blacklist
Từ khóa chính:
email bị blacklist
Từ khóa phụ:
email blacklist
email bị block
IP bị blacklist
mail server bị blacklist
kiểm tra email blacklist
check email blacklist
check IP blacklist
IP mail server bị blacklist
domain bị blacklist
cách xử lý email blacklist
cách gỡ email blacklist
SPF DKIM DMARC
PTR mail server
email vào spam
mail server bị spam
IP reputation
domain reputation
Search Intent:
Informational
Troubleshooting
Commercial Investigation
Đối tượng tìm kiếm:
Quản trị viên Mail Server
IT/System Administrator
Doanh nghiệp
Người vận hành VPS/Dedicated Server
Người sử dụng DirectAdmin/cPanel
Người triển khai Email Hosting
Doanh nghiệp gửi Email Marketing
Tools check Email Blacklist mxtoolbox
