Email vào spam? Cấu hình SPF, DKIM, DMARC đúng cách từ A đến Z

Email vào spam thường vì một trong bốn lý do: tên miền thiếu hoặc sai bản ghi SPF, DKIM, DMARC; IP máy chủ không có reverse DNS (PTR) khớp với hostname; IP đã nằm trong danh sách đen vì từng gửi spam; hoặc nội dung và cách gửi khiến người nhận bấm "Báo cáo spam". Sửa đúng ba bản ghi DNS và PTR giải quyết phần lớn trường hợp với server tự quản. Phần còn lại là giữ IP sạch và tỉ lệ bị báo spam thấp.

Bài viết đi qua từng nguyên nhân, cách kiểm tra bằng lệnh và bằng tiêu đề thư, mẫu bản ghi đúng cho các tình huống hay gặp (chỉ gửi từ VPS, dùng thêm Google Workspace, dùng dịch vụ gửi thư), yêu cầu hiện hành của Gmail, Yahoo và Outlook.com, và cách làm trên ZoPanel.

Vì sao email vào spam?

Bộ lọc của Gmail hay Outlook không dựa vào một yếu tố duy nhất. Chúng đánh giá:

1. Xác thực: thư có thật sự đến từ tên miền nó tự nhận không? Đó là việc của SPF, DKIM và DMARC.
2. Hạ tầng: IP gửi có reverse DNS hợp lệ không, có dùng TLS không, có tuân chuẩn định dạng thư không.
3. Danh tiếng: IP và tên miền có lịch sử gửi spam không, có nằm trong blacklist như Spamhaus không.
4. Phản hồi của người nhận: bao nhiêu người mở, trả lời, hay bấm "Báo cáo spam".
5. Nội dung: link rút gọn đáng ngờ, chỉ có ảnh, tiêu đề kiểu quảng cáo.

Trên server hosting tự quản, nguyên nhân số một gần như luôn là xác thực thiếu, và số hai là một website bị hack dùng server để gửi spam, kéo IP vào blacklist, làm thư của mọi khách trên server vào spam theo.

Gmail, Yahoo và Outlook yêu cầu gì?

Từ 01/02/2024, Google yêu cầu mọi người gửi tới Gmail phải có SPF hoặc DKIM, có reverse DNS hợp lệ cho IP gửi, gửi qua TLS, và giữ tỉ lệ bị báo spam trong Postmaster Tools dưới 0,3%. Người gửi trên 5.000 thư mỗi ngày tới Gmail phải có cả SPF lẫn DKIM, có DMARC (chính sách p=none là đủ), tên miền ở dòng From phải khớp (aligned) với tên miền SPF hoặc DKIM, và thư marketing phải có hủy đăng ký một chạm. Google khuyên nên giữ tỉ lệ spam dưới 0,1%.

Yahoo có yêu cầu gần như giống hệt, cũng với ngưỡng 0,3%. Outlook.com áp dụng yêu cầu SPF, DKIM, DMARC cho tên miền gửi trên 5.000 thư/ngày từ tháng 5/2025.

Nói ngắn gọn: dù bạn chỉ gửi vài chục thư mỗi ngày, hãy cấu hình đủ cả ba. Không tốn tiền, và đó là chuẩn tối thiểu năm 2026.

SPF là gì và viết thế nào cho đúng?

SPF (RFC 7208) là một bản ghi TXT ở tên miền gốc, liệt kê những máy chủ được phép gửi thư cho tên miền đó.

Ví dụ khi chỉ gửi từ VPS của bạn, và VPS này cũng là MX:

example.com.  TXT  "v=spf1 mx a ~all"

• mx: các máy chủ trong bản ghi MX được phép gửi.
• a: IP trong bản ghi A của tên miền được phép gửi.
• ~all: mọi nguồn khác "nghi ngờ" (softfail). -all là từ chối hẳn, chặt hơn.

Nếu bạn dùng thêm Google Workspace cho một số hộp thư, hoặc dịch vụ gửi thư như Amazon SES, Mailgun, Brevo, hãy gộp vào cùng một bản ghi:

example.com.  TXT  "v=spf1 mx a include:_spf.google.com ~all"

Ba lỗi SPF hay gặp nhất:

• Có hai bản ghi SPF. Một tên miền chỉ được có đúng một bản ghi bắt đầu bằng v=spf1. Hai bản ghi làm SPF lỗi (permerror), tương đương không có.
• Vượt 10 lần tra DNS. Mỗi include, a, mx tốn ít nhất một lần tra, và các include lồng nhau cộng dồn. Quá 10 lần, SPF lỗi.
• Quên nguồn gửi. Form liên hệ gửi qua SMTP của dịch vụ khác, phần mềm kế toán gửi hoá đơn, CRM gửi báo giá: mọi nguồn gửi thư nhân danh tên miền đều phải có trong SPF hoặc tự ký DKIM.

DKIM là gì và vì sao cần?

DKIM ký số mỗi thư bằng khoá bí mật trên máy chủ gửi. Khoá công khai được đặt trong DNS dưới một "selector":

zp._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."

Máy chủ nhận lấy khoá công khai, kiểm tra chữ ký, và biết chắc thư không bị sửa trên đường đi và đúng là do máy chủ có khoá bí mật gửi. Khác với SPF, chữ ký DKIM vẫn còn nguyên khi thư bị chuyển tiếp, nên DKIM thường quyết định DMARC có đạt hay không.

Lưu ý:

• Dùng khoá RSA 2048 bit. Khoá 1024 bit vẫn được chấp nhận nhưng không còn được khuyên dùng.
• Khoá 2048 bit dài hơn 255 ký tự, nên bản ghi TXT được tách thành nhiều chuỗi. Phần lớn giao diện DNS tự làm việc này; nếu dán tay, đừng chèn khoảng trắng hay xuống dòng vào giữa khoá.
• Mỗi dịch vụ gửi có selector riêng. Google Workspace, SES, máy chủ của bạn có thể cùng tồn tại, mỗi cái một selector.
• Khi chuyển sang máy chủ mới, máy chủ mới ký bằng khoá mới: nhớ cập nhật bản ghi DKIM.

DMARC là gì và nên đặt chính sách nào?

DMARC nói cho máy chủ nhận biết phải làm gì khi thư không qua xác thực, và gửi báo cáo về cho bạn. Đặc tả gốc là RFC 7489; năm 2026 IETF đã ban hành RFC 9989 thay thế, nhưng bản ghi vẫn bắt đầu bằng v=DMARC1 và các bản ghi hiện có vẫn dùng được.

_dmarc.example.com.  TXT  "v=DMARC1; p=quarantine; rua=mailto:postmaster@example.com"

Điểm mấu chốt là alignment (khớp tên miền): DMARC chỉ đạt khi SPF hoặc DKIM đạt với chính tên miền ở dòng From. Thư gửi từ ban@example.com nhưng ký DKIM bằng tên miền của nhà cung cấp dịch vụ gửi thư sẽ qua DKIM, nhưng không qua DMARC.

Lộ trình an toàn cho tên miền đang có thư gửi từ nhiều nơi:

1. p=none kèm rua: chỉ theo dõi, đọc báo cáo trong 2 đến 4 tuần để tìm mọi nguồn gửi hợp lệ.
2. p=quarantine: thư không đạt vào spam.
3. p=reject: thư không đạt bị từ chối, chống giả mạo tên miền tốt nhất.

Với tên miền mới chỉ gửi từ một server bạn kiểm soát, có thể bắt đầu ngay ở p=quarantine.

Reverse DNS (PTR): bước hay bị quên nhất

PTR ánh xạ ngược từ IP về tên. Máy chủ nhận tra IP gửi và mong thấy một hostname, và hostname đó lại trỏ về đúng IP. Bản ghi PTR không đặt ở nhà cung cấp tên miền mà ở nhà cung cấp VPS, vì họ sở hữu dải IP. Hầu hết nhà cung cấp cho đặt PTR trong trang quản lý VPS; một số yêu cầu mở ticket.

Đặt PTR bằng đúng hostname mail, ví dụ mail.example.com, và đảm bảo mail.example.com có bản ghi A trỏ về IP đó.

Cách kiểm tra từng bản ghi

Trên Ubuntu hoặc Debian, cài công cụ dig (gói dnsutils) rồi kiểm tra:

sudo apt install dnsutils
dig +short MX example.com
dig +short TXT example.com | grep spf1
dig +short TXT zp._domainkey.example.com
dig +short TXT _dmarc.example.com
dig +short -x 203.0.113.10

Thay zp bằng selector DKIM của bạn và 203.0.113.10 bằng IP máy chủ. Lệnh cuối phải trả về hostname mail.

Cách kiểm tra đáng tin nhất là xem tiêu đề thư thật. Gửi một thư tới hộp Gmail, mở thư, chọn Hiển thị bản gốc (Show original) trong menu ba chấm. Gmail ghi rõ SPF, DKIM, DMARC là PASS hay FAIL. Trong tiêu đề, tìm dòng Authentication-Results:

Authentication-Results: mx.google.com;
       dkim=pass header.i=@example.com header.s=zp;
       spf=pass smtp.mailfrom=example.com;
       dmarc=pass (p=QUARANTINE) header.from=example.com

Nếu gửi số lượng lớn tới Gmail, đăng ký Google Postmaster Tools để theo dõi tỉ lệ bị báo spam và danh tiếng tên miền.

Khi IP đã nằm trong blacklist

Nếu cả ba bản ghi đều đạt mà thư vẫn vào spam hoặc bị từ chối, kiểm tra IP trên các danh sách như Spamhaus, SpamCop, Barracuda. Thứ tự xử lý:

1. Tìm và chặn nguồn spam trước. Thường là một website bị hack, một form liên hệ bị lạm dụng hoặc một hộp thư bị lộ mật khẩu. Nếu chưa chặn nguồn mà đã xin gỡ, IP sẽ bị liệt kê lại rất nhanh.
2. Xoá thư spam đang chờ trong hàng đợi.
3. Gửi yêu cầu gỡ trên trang của từng danh sách.
4. Nếu nhà cung cấp chặn cổng 25 gửi ra, hoặc IP có danh tiếng kém lâu dài, cân nhắc gửi qua relay (smarthost) như Amazon SES, Mailgun, SendGrid, Brevo.

Làm trên ZoPanel như thế nào?

ZoPanel dùng Postfix, Dovecot và Rspamd, tự ký DKIM cho mọi tên miền bật email. Các bước:

1. Ở trang Email, đặt Hostname mail (ví dụ mail.example.com) và cài mail server. Nhờ nhà cung cấp VPS đặt PTR của IP thành hostname này.
2. Bật email cho tên miền. Thẻ Bản ghi DNS hiển thị đúng bốn bản ghi cần có: MX, SPF (v=spf1 mx a ~all), DKIM ở zp._domainkey và DMARC (p=quarantine kèm rua). Nếu DNS của tên miền đặt trên chính server này, vùng DNS mới được tạo kèm sẵn các bản ghi đó.
3. Bấm Kiểm tra trong thẻ Kiểm tra gửi/nhận mail. Công cụ đối chiếu DNS công khai với MX, SPF, DKIM, DMARC cần có, kiểm tra PTR và cổng 25 gửi ra, tra IP trên Spamhaus, SpamCop, Barracuda, và gợi ý cách sửa cho từng lỗi.
4. Nếu nhà cung cấp chặn cổng 25, cấu hình Gửi mail qua relay (smarthost). Nhớ thêm nguồn gửi của dịch vụ relay vào SPF và bật DKIM theo hướng dẫn của họ.

Để IP không bị blacklist vì một khách, ZoPanel đếm số người nhận mỗi tài khoản gửi mỗi giờ (mặc định 500) và tạm từ chối khi vượt, chặn code website kết nối thẳng ra cổng 25 của máy chủ khác, cảnh báo khi hàng đợi mail tăng bất thường và mỗi ngày kiểm tra IP có nằm trong blacklist hay không. Chi tiết trong tài liệu Email và DNS.

Danh sách kiểm tra nhanh

• Một và chỉ một bản ghi SPF, liệt kê mọi nguồn gửi, dưới 10 lần tra DNS.
• DKIM ký cho mọi nguồn gửi, khoá 2048 bit.
• DMARC có rua, chính sách tăng dần tới quarantine hoặc reject.
• PTR của IP trùng hostname mail, hostname trỏ ngược về IP.
• IP không có trong blacklist.
• Gửi qua TLS, có link hủy đăng ký trong thư marketing.
• Giới hạn gửi theo tài khoản để một website bị hack không kéo cả server xuống.

Kết luận

Phần lớn trường hợp email vào spam trên VPS tự quản được giải quyết bằng ba bản ghi DNS và một bản ghi PTR, làm đúng một lần. Phần khó hơn là giữ IP sạch lâu dài khi server có nhiều khách, và đó là lý do nên có giới hạn gửi theo tài khoản cùng cảnh báo blacklist.

Nếu bạn chuẩn bị dựng email theo tên miền trên VPS, gói Free của ZoPanel có đầy đủ mail server, DKIM và công cụ kiểm tra gửi nhận. Xem bảng giá hoặc bài tạo email tên miền trên VPS.

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

Đã có SPF, DKIM, DMARC mà email vẫn vào spam thì sao?

Kiểm tra tiếp PTR của IP, IP có nằm trong blacklist không, và tiêu đề thư thật để chắc cả ba đều pass với đúng tên miền ở dòng From. Nếu xác thực đều đạt, nguyên nhân thường là danh tiếng IP hoặc tên miền còn mới, hay nội dung bị người nhận báo spam. Gửi đều đặn, số lượng tăng dần và chỉ gửi cho người đã đồng ý nhận.

Một tên miền có được hai bản ghi SPF không?

Không. Hai bản ghi bắt đầu bằng v=spf1 làm SPF lỗi và bị xem như không có. Hãy gộp mọi nguồn vào một bản ghi, ví dụ v=spf1 mx a include:_spf.google.com ~all.

Nên dùng ~all hay -all trong SPF?

~all (softfail) an toàn khi bạn chưa chắc đã liệt kê đủ nguồn gửi. Khi DMARC đã ở quarantine hoặc reject, chính sách DMARC mới là thứ quyết định số phận thư không đạt, nên ~all vẫn đủ dùng. -all phù hợp với tên miền bạn kiểm soát hoàn toàn nguồn gửi.

Đặt bản ghi PTR ở đâu?

Ở nhà cung cấp VPS hoặc nhà cung cấp IP, không phải ở nơi quản lý DNS tên miền. Tìm mục reverse DNS hoặc rDNS trong trang quản lý VPS, hoặc mở ticket yêu cầu đặt PTR bằng hostname mail của bạn.

DMARC p=none có tác dụng gì không?

Có. p=none không chặn thư giả mạo, nhưng giúp bạn nhận báo cáo về mọi nguồn đang gửi nhân danh tên miền, và đáp ứng yêu cầu DMARC tối thiểu của Gmail và Yahoo. Sau vài tuần đọc báo cáo, hãy nâng lên quarantine.