Vì sao email vào spam dù đã cấu hình SPF/DKIM đúng

Vì sao email vào spam dù đã cấu hình SPF/DKIM đúng

Vì sao email vẫn rơi vào spam dù bạn đã cấu hình SPF và DKIM đúng là câu hỏi rất hay gặp khi vận hành hệ thống mail, làm MMO, gửi thông báo giao dịch, email marketing hoặc chăm sóc khách hàng.

Nhiều bạn kiểm tra DNS thấy SPF pass, DKIM pass, thậm chí DMARC cũng pass, nhưng Gmail, Outlook hoặc Yahoo vẫn đưa thư vào Spam/Junk. Lý do là SPF/DKIM chỉ là một phần trong bài toán deliverability, không phải “vé thông hành” đảm bảo inbox.

Email vào inbox hay spam phụ thuộc vào nhiều tín hiệu kết hợp:

• Danh tiếng IP gửi
• Danh tiếng tên miền
• rDNS/PTR
• Nội dung thư
• Hành vi người nhận
• Tần suất gửi
• Lịch sử khiếu nại spam
• Tỉ lệ bounce
• Cách hâm nóng IP/domain
• Cấu hình bảo mật và xác thực tổng thể

Bạn có thể xem SPF/DKIM giống như giấy tờ xe hợp lệ. Nhưng để được đi nhanh, không bị chặn, bạn còn cần lịch sử lái xe tốt, biển số sạch, không vi phạm và không chạy kiểu đáng ngờ.

Vì sao cần hiểu đúng vấn đề này

Pain point 1: Cấu hình đúng nhưng vẫn mất doanh thu

Với website bán hàng, SaaS, khóa học, tài khoản MMO hoặc hệ thống affiliate, email không vào inbox có thể làm mất tiền trực tiếp.

Ví dụ:

• Email xác minh tài khoản không tới
• Email reset mật khẩu vào spam
• Email mã giảm giá không được mở
• Email hóa đơn bị bỏ qua
• Email chăm sóc khách hàng không có phản hồi

Bạn có thể đã đầu tư hạ tầng, viết nội dung, chạy ads, kéo traffic, nhưng chỉ vì email vào spam mà toàn bộ phễu chuyển đổi bị nghẽn.

Pain point 2: Dễ kết luận sai do chỉ nhìn SPF/DKIM

Một sai lầm phổ biến là thấy SPF/DKIM pass thì kết luận “bên nhận chặn vô lý”. Thực tế, máy chủ nhận thư không chỉ hỏi “email này có được ký đúng không?”, mà còn hỏi “người gửi này có đáng tin không?”.

Nếu domain mới đăng ký hôm qua, IP chưa từng gửi thư, nội dung có nhiều link tracking, gửi một lúc 10.000 email, thì dù SPF/DKIM đúng, thư vẫn có thể vào spam.

Để xử lý đúng, bạn cần nhìn email deliverability như một hệ thống chấm điểm. Mỗi điểm yếu làm giảm độ tin cậy tổng thể.

Gợi ý: nếu bạn đang tự dựng mail server, nên đọc thêm phần cấu hình DNS email tại tài liệu Email của VSIS và kiểm tra đầy đủ SPF, DKIM, DMARC, PTR trước khi gửi thật.

Danh tiếng IP và tên miền quan trọng hơn cấu hình

SPF, DKIM, DMARC giúp chứng minh email không bị giả mạo. Nhưng danh tiếng IP và tên miền mới là yếu tố lớn quyết định thư có được tin tưởng hay không.

Các nhà cung cấp như Gmail, Microsoft, Yahoo đánh giá uy tín người gửi dựa trên lịch sử dài hạn. Họ không chỉ nhìn một email đơn lẻ.

Một IP hoặc domain có thể bị đánh giá thấp nếu:

• Gửi quá nhiều email trong thời gian ngắn
• Có nhiều email bị bounce
• Người nhận ít mở thư
• Người nhận xóa thư mà không đọc
• Nhiều người bấm “Report spam”
• Nội dung thường xuyên giống mẫu spam
• Gửi tới danh sách email mua, quét hoặc cũ
• IP từng bị dùng để gửi spam trước đó

Ngược lại, một domain có danh tiếng tốt thường có các tín hiệu:

• Người nhận hay mở thư
• Có người trả lời email
• Có người thêm vào danh bạ
• Tỉ lệ bounce thấp
• Tỉ lệ complaint thấp
• Lịch sử gửi ổn định
• Nội dung nhất quán với mục đích domain

Bảng dưới đây giúp bạn phân biệt rõ hơn:

Bạn nên hiểu rằng SPF/DKIM là điều kiện cần, không phải điều kiện đủ.

Nếu bạn dùng VPS để dựng mail riêng, hãy ưu tiên IP sạch. IP từng nằm trong blacklist, từng gửi spam hoặc thuộc dải IP bị lạm dụng nhiều sẽ khó vào inbox hơn.

Bạn có thể kiểm tra danh tiếng IP qua các công cụ như:

• Talos Intelligence: https://talosintelligence.com/
• Spamhaus: https://check.spamhaus.org/
• MXToolbox blacklist check: https://mxtoolbox.com/blacklists.aspx

Nếu IP bị liệt kê ở blacklist lớn, việc đầu tiên không phải sửa nội dung email, mà là xử lý nguyên nhân và yêu cầu gỡ blacklist.

rDNS/PTR thiếu – lỗi hay bị bỏ qua nhất

rDNS/PTR là bản ghi DNS ngược, dùng để ánh xạ IP về hostname. Đây là lỗi rất nhiều bạn bỏ qua khi tự dựng mail server.

Ví dụ IP 203.0.113.10 gửi mail với hostname mail.example.com. Khi máy chủ nhận thư kiểm tra ngược, IP đó nên trả về mail.example.com.

Cấu hình hợp lý thường là:

• mail.example.com trỏ A record về 203.0.113.10
• IP 203.0.113.10 có PTR trỏ ngược về mail.example.com
• Mail server dùng hostname khớp với PTR
• HELO/EHLO cũng nên dùng hostname hợp lệ

Nếu thiếu PTR, nhiều máy chủ nhận sẽ đánh giá email đáng ngờ. Một số nơi vẫn nhận nhưng đưa vào spam, một số nơi từ chối thẳng.

Ví dụ lỗi thường gặp:

• PTR không tồn tại
• PTR trỏ về hostname mặc định của nhà cung cấp VPS
• PTR trỏ về domain khác
• Hostname không có A record ngược lại IP
• HELO dùng localhost
• HELO dùng tên nội bộ như server.local

Bạn có thể kiểm tra PTR bằng lệnh:

dig -x 203.0.113.10

Hoặc:

host 203.0.113.10

Nếu kết quả không trả về hostname mail của bạn, hãy cấu hình lại trong trang quản lý IP/VPS. Không phải lúc nào bạn cũng tự sửa PTR trong DNS domain được, vì PTR thường do nhà cung cấp IP quản lý.

Một cấu hình đẹp thường như sau:

mail.example.com. A 203.0.113.10
10.113.0.203.in-addr.arpa. PTR mail.example.com.

Ngoài PTR, bạn cũng nên kiểm tra hostname của máy chủ:

hostname -f

Nếu hostname đang là localhost, ubuntu, vps123.provider.com, bạn nên đổi sang hostname mail rõ ràng.

Tham khảo thêm tài liệu chuẩn về DNS tại Cloudflare: https://www.cloudflare.com/learning/dns/dns-records/dns-ptr-record/

Nội dung thư và tỉ lệ mở

Nội dung email vẫn là yếu tố cực kỳ quan trọng. Một email có cấu hình kỹ thuật hoàn hảo nhưng nội dung giống spam thì vẫn dễ bị lọc.

Các bộ lọc spam thường phân tích:

• Tiêu đề email
• Nội dung văn bản
• Tỉ lệ chữ và hình ảnh
• Link trong email
• Domain của link
• File đính kèm
• Mã HTML
• Từ khóa nhạy cảm
• Độ giống nhau giữa nhiều email
• Lịch sử tương tác của người nhận

Một số kiểu nội dung dễ bị nghi ngờ:

• Tiêu đề viết hoa toàn bộ
• Lạm dụng từ “miễn phí”, “kiếm tiền nhanh”, “cam kết 100%”
• Chèn quá nhiều link rút gọn
• Chỉ có một ảnh lớn, ít text
• HTML copy từ trình kéo thả quá nặng
• Có file đính kèm .zip, .exe, .js
• Link hiển thị một domain nhưng trỏ sang domain khác
• Nội dung gửi hàng loạt giống nhau 100%

Với MMO, affiliate hoặc email marketing, bạn càng cần cẩn thận. Những lĩnh vực có nhiều spammer hoạt động thường bị bộ lọc soi kỹ hơn.

Ngoài nội dung, tỉ lệ mở và tương tác cũng ảnh hưởng lớn. Nếu nhiều người nhận không mở email của bạn, xóa ngay, hoặc bấm spam, hệ thống sẽ học rằng email từ bạn không được mong muốn.

Một số cách cải thiện engagement:

• Gửi cho danh sách người đã opt-in thật
• Dọn danh sách email không tương tác
• Cá nhân hóa nội dung vừa đủ
• Viết tiêu đề rõ ràng, không giật gân
• Cho phép hủy đăng ký dễ dàng
• Không gửi quá dày
• Khuyến khích người nhận trả lời email
• Tách email giao dịch và email marketing

Với email giao dịch như OTP, hóa đơn, reset mật khẩu, nội dung nên ngắn, rõ và ít link. Không nên nhồi banner marketing vào email giao dịch vì có thể làm giảm độ tin cậy.

Ví dụ tốt cho email reset mật khẩu:

• Tiêu đề: Yêu cầu đặt lại mật khẩu tài khoản của bạn
• Nội dung ngắn gọn
• Chỉ có 1 link chính
• Có thời hạn hiệu lực
• Có dòng cảnh báo nếu người nhận không yêu cầu

Ví dụ kém:

• Tiêu đề: NHẤN NGAY ĐỂ LẤY LẠI TÀI KHOẢN!!!
• Nhiều banner khuyến mãi
• Có link tracking phức tạp
• Nội dung dài và lẫn thông tin bán hàng

Nếu bạn đang dùng WordPress, hãy đảm bảo website gửi mail qua SMTP xác thực thay vì mail() mặc định. Bạn có thể tham khảo thêm các hướng dẫn liên quan tại doc.vsis.net hoặc dịch vụ hạ tầng tại https://vsis.net/.

Gửi hàng loạt từ IP mới: cách hâm nóng

Một IP mới không có lịch sử gửi email. Với các nhà cung cấp lớn, “mới” không có nghĩa là “sạch tuyệt đối”, mà là “chưa đủ dữ liệu để tin”.

Nếu bạn vừa dựng mail server và gửi ngay 20.000 email, khả năng vào spam rất cao. Đây là lỗi thường gặp khi chạy chiến dịch email marketing hoặc gửi thông báo tới toàn bộ user sau thời gian dài im lặng.

Hâm nóng IP, còn gọi là IP warming, là quá trình tăng dần lưu lượng gửi để xây dựng lịch sử tốt.

Nguyên tắc cơ bản:

• Bắt đầu với số lượng nhỏ
• Gửi tới nhóm người nhận có khả năng mở cao
• Tăng dần theo ngày
• Theo dõi bounce, complaint, open rate
• Dừng tăng nếu chỉ số xấu
• Không trộn danh sách cũ, lạnh ngay từ đầu

Ví dụ lịch hâm nóng tham khảo:

Lịch trên không phải công thức cố định. Gmail, Outlook, Yahoo có cách đánh giá riêng, nên bạn cần theo dõi phản hồi thực tế.

Khi hâm nóng domain mới, bạn cũng nên:

• Dùng email giao dịch trước nếu có traffic thật
• Gửi nội dung hữu ích, ít quảng cáo
• Tránh gửi tới email doanh nghiệp không quen biết
• Không gửi tới danh sách mua
• Tách subdomain cho từng loại email

Ví dụ:

• mail.example.com cho mail server
• transaction.example.com cho email giao dịch
• newsletter.example.com cho bản tin
• notify.example.com cho thông báo hệ thống

Tách luồng gửi giúp hạn chế rủi ro. Nếu chiến dịch marketing bị complaint cao, email giao dịch quan trọng vẫn ít bị ảnh hưởng hơn.

Nếu bạn đang vận hành nhiều website hoặc nhiều dự án MMO trên cùng VPS, không nên để tất cả dùng chung một IP gửi mail khi chưa có kế hoạch kiểm soát. Một domain xấu có thể kéo theo uy tín IP chung.

Công cụ tự chấm điểm thư trước khi gửi thật

Trước khi gửi chiến dịch thật, bạn nên test email bằng các công cụ chấm điểm. Việc này không đảm bảo 100% inbox, nhưng giúp phát hiện lỗi rõ ràng.

Một số công cụ hữu ích:

• Mail Tester: https://www.mail-tester.com/
• GlockApps
• MXToolbox
• Google Postmaster Tools
• Microsoft SNDS
• dmarcian
• URIports

Mail Tester rất dễ dùng. Bạn gửi email tới địa chỉ test mà công cụ cung cấp, sau đó nhận điểm và gợi ý sửa.

Các mục thường được kiểm tra:

• SPF pass hay fail
• DKIM pass hay fail
• DMARC có tồn tại không
• PTR/rDNS có hợp lệ không
• IP có blacklist không
• Nội dung có dấu hiệu spam không
• HTML có lỗi không
• Link có vấn đề không
• Tỉ lệ text/image
• Chữ ký DKIM có khớp không

Google Postmaster Tools hữu ích nếu bạn gửi nhiều tới Gmail. Công cụ này cho biết domain reputation, IP reputation, spam rate, authentication, delivery errors.

Bạn có thể truy cập tài liệu chính thức của Google tại: https://support.google.com/mail/answer/9981691

Nếu gửi nhiều tới Outlook/Hotmail, Microsoft SNDS giúp theo dõi IP gửi có bị đánh giá xấu không. Đây là nguồn dữ liệu quan trọng nếu user của bạn dùng hệ sinh thái Microsoft.

Ngoài công cụ web, bạn cũng nên đọc header email nhận được. Header cho biết SPF, DKIM, DMARC pass hay fail ở phía người nhận, không chỉ phía bạn.

Trong Gmail, bạn có thể mở email, chọn “Show original” để xem. Các dòng cần chú ý:

SPF: PASS
DKIM: PASS
DMARC: PASS

Ngoài ra, xem thêm:

Authentication-Results
Received-SPF
DKIM-Signature
Received

Nếu email gửi qua nhiều relay, header sẽ giúp bạn thấy thư đi qua đâu, IP nào thực sự gửi, DKIM có bị thay đổi nội dung hay không.

Checklist 10 điểm trước khi kết luận bị chặn

Trước khi kết luận “Gmail chặn mail của tôi” hoặc “Outlook lọc sai”, hãy kiểm tra đủ 10 điểm dưới đây.

Một SPF cơ bản có thể như sau:

example.com. TXT "v=spf1 ip4:203.0.113.10 -all"

Một DMARC khởi đầu thận trọng:

_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:[email protected]"

Khi đã theo dõi ổn định, bạn có thể nâng chính sách lên quarantine hoặc reject. Không nên đặt p=reject ngay nếu bạn chưa chắc toàn bộ nguồn gửi hợp lệ.

Với DKIM, hãy đảm bảo selector đúng và private key được cấu hình trong mail server. Public key sẽ nằm trong DNS dạng TXT, ví dụ:

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

Nếu bạn dùng nhiều dịch vụ gửi email cùng lúc, ví dụ website, CRM, helpdesk, newsletter, mỗi dịch vụ có thể cần DKIM riêng. Thiếu một nguồn gửi sẽ làm DMARC fail ở một số trường hợp.

Bạn cũng nên xem log mail server. Với Postfix, các tệp thường gặp là:

/var/log/mail.log
/var/log/maillog

Tìm các mã lỗi như:

550
554
421
451

Mã 550 thường là từ chối vĩnh viễn. Mã 421 hoặc 451 thường là tạm thời, có thể liên quan rate limit hoặc greylisting.

Nếu bạn cần kiểm tra nhanh bản ghi DNS, có thể dùng:

dig TXT example.com
dig TXT _dmarc.example.com
dig TXT default._domainkey.example.com
dig MX example.com
dig -x 203.0.113.10

Tài liệu về DNS và mail server có thể tham khảo thêm tại kho tài liệu kỹ thuật VSIS và trang VSIS.

Sai lầm phổ biến

Chỉ kiểm tra SPF/DKIM rồi bỏ qua PTR

Đây là lỗi rất hay gặp khi tự dựng mail server trên VPS. Bạn cấu hình DNS domain rất đẹp nhưng IP lại không có PTR hợp lệ.

Nhiều bộ lọc xem thiếu PTR là tín hiệu hạ tầng gửi mail không chuyên nghiệp. Với email hàng loạt, lỗi này càng dễ bị phạt.

Dùng IP mới để gửi số lượng lớn ngay

IP mới cần thời gian xây dựng uy tín. Gửi đột biến ngay ngày đầu là tín hiệu rất giống spam bot.

Nếu cần gửi gấp, bạn nên chia nhỏ, ưu tiên người nhận có tương tác cao và theo dõi phản hồi từng ngày.

Gửi tới danh sách email mua hoặc quá cũ

Danh sách mua thường chứa spam trap, email không tồn tại hoặc người nhận không hề biết bạn. Tỉ lệ complaint và bounce cao sẽ làm hỏng reputation rất nhanh.

Danh sách cũ cũng nguy hiểm nếu nhiều tháng không liên hệ. Nên chạy chiến dịch xác nhận lại trước khi gửi nội dung chính.

Trộn email giao dịch với email marketing

Email reset mật khẩu, OTP, hóa đơn cần độ tin cậy cao. Nếu gửi chung IP/domain với chiến dịch marketing rủi ro cao, email quan trọng có thể bị ảnh hưởng.

Nên tách subdomain hoặc tách hạ tầng gửi cho từng loại email.

Lạm dụng link tracking và rút gọn link

Link tracking không xấu, nhưng quá nhiều redirect làm bộ lọc nghi ngờ. Link rút gọn công khai càng dễ bị lạm dụng bởi spammer.

Tốt nhất dùng domain tracking riêng, có uy tín và nội dung link rõ ràng.

Không xử lý bounce

Nếu một email đã hard bounce mà bạn vẫn gửi tiếp, hệ thống nhận sẽ đánh giá bạn quản lý danh sách kém. Đây là tín hiệu xấu cho reputation.

Hãy tự động loại bỏ email hard bounce khỏi danh sách gửi.

Key takeaways

• SPF/DKIM đúng chỉ chứng minh email được xác thực, không đảm bảo vào inbox.
• Danh tiếng IP và domain ảnh hưởng rất mạnh đến việc email vào spam hay inbox.
• PTR/rDNS là lỗi kỹ thuật hay bị bỏ qua khi tự dựng mail server.
• Nội dung thư, link, file đính kèm và hành vi người nhận đều được dùng để chấm điểm.
• IP mới cần hâm nóng từ từ, không nên gửi hàng loạt ngay.
• Công cụ như Mail Tester, Google Postmaster Tools, Spamhaus giúp phát hiện vấn đề sớm.
• Cần kiểm tra cả kỹ thuật, nội dung và dữ liệu người nhận trước khi kết luận bị chặn.

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

Vì sao email có SPF pass và DKIM pass nhưng vẫn vào spam?

Vì SPF và DKIM chỉ là tín hiệu xác thực. Bộ lọc spam còn xem danh tiếng IP, domain, nội dung, hành vi người nhận, tỉ lệ bounce và complaint.

Nếu IP mới, domain mới hoặc nội dung có dấu hiệu spam, email vẫn có thể vào spam dù xác thực pass.

DMARC pass có đảm bảo email vào inbox không?

Không. DMARC giúp xác nhận email phù hợp chính sách xác thực của domain, nhưng không đảm bảo inbox.

Inbox còn phụ thuộc reputation, engagement và chất lượng nội dung. DMARC pass là điều kiện tốt, nhưng chưa đủ.

Có nên dùng domain mới để gửi email marketing không?

Có thể, nhưng cần hâm nóng từ từ. Domain mới chưa có lịch sử, nên gửi hàng loạt ngay rất dễ bị đánh giá xấu.

Bạn nên bắt đầu với số lượng nhỏ, gửi tới nhóm người nhận có tương tác tốt và tăng dần theo dữ liệu thực tế.

PTR/rDNS có bắt buộc không?

Về mặt kỹ thuật, không phải mọi máy chủ đều bắt buộc PTR để nhận thư. Nhưng trong thực tế, thiếu PTR làm giảm độ tin cậy rất nhiều.

Nếu bạn tự dựng mail server, hãy xem PTR là cấu hình gần như bắt buộc.

Email giao dịch và email marketing có nên gửi chung IP không?

Không nên nếu bạn có lưu lượng đáng kể. Email giao dịch cần độ ổn định cao, còn email marketing dễ phát sinh complaint hơn.

Tốt nhất nên tách subdomain, tách IP hoặc ít nhất tách luồng gửi để dễ kiểm soát reputation.

Bao lâu thì IP mới gửi mail ổn định?

Không có con số cố định. Thường cần vài tuần để xây dựng lịch sử tốt nếu bạn gửi đều, bounce thấp và người nhận tương tác tốt.

Nếu gửi sai cách trong vài ngày đầu, IP có thể bị đánh giá xấu và cần nhiều thời gian hơn để phục hồi.

Tóm tắt nhanh

• Vì sao email vào spam dù SPF/DKIM đúng: vì xác thực chỉ là một phần của deliverability.
• Danh tiếng IP và domain thường quan trọng hơn việc chỉ “pass” bản ghi DNS.
• Thiếu rDNS/PTR là lỗi phổ biến khi tự dựng mail server trên VPS.
• Nội dung thư, link, file đính kèm và tỉ lệ mở ảnh hưởng trực tiếp đến inbox.
• IP hoặc domain mới cần hâm nóng dần, không gửi hàng loạt ngay.
• Nên test bằng Mail Tester, Google Postmaster Tools, blacklist check và đọc header email.
• Trước khi kết luận bị chặn, hãy kiểm tra đủ SPF, DKIM, DMARC, PTR, blacklist, reputation, bounce và nội dung.