SPF, DKIM, DMARC: giải thích dễ hiểu cho người quản trị VPS

Vì sao cần

SPF DKIM DMARC là bộ ba bản ghi DNS gần như bắt buộc nếu bạn tự gửi email từ VPS, dùng mail server riêng, hoặc cấu hình SMTP cho website. Không có chúng, thư vẫn có thể gửi đi, nhưng khả năng vào spam, bị từ chối, hoặc bị mạo danh sẽ cao hơn nhiều.

Với người quản trị VPS, vấn đề thường không nằm ở nội dung email. Bạn có thể gửi hóa đơn, mã OTP, thông báo đơn hàng rất sạch, nhưng Gmail, Outlook, Yahoo vẫn đánh dấu spam vì thiếu bằng chứng xác thực người gửi.

Thư gửi từ VPS bị đánh dấu spam dù nội dung sạch

Khi một VPS gửi email, máy chủ nhận sẽ hỏi: IP này có được phép gửi email cho tên miền này không? Email có bị sửa nội dung trên đường đi không? Nếu xác thực fail thì tên miền muốn xử lý thế nào?

Nếu bạn chưa cấu hình SPF, DKIM, DMARC, máy chủ nhận gần như phải tự đoán. Với các nhà cung cấp lớn như Gmail, thiếu xác thực sẽ làm điểm uy tín email giảm mạnh.

Một tình huống phổ biến là bạn cài Postfix trên VPS, gửi mail từ [email protected]. Nội dung chỉ là thông báo đăng ký tài khoản, nhưng vẫn vào spam vì DNS của domain.com chưa khai báo IP VPS được phép gửi.

Tương tự, website WordPress gửi mail bằng hàm mail() mặc định. Email đi ra từ IP VPS, nhưng tên miền chưa có bản ghi xác thực, dẫn đến cảnh báo hoặc thư bị đưa vào Junk.

Bạn có thể tham khảo thêm phần cấu hình VPS cơ bản tại tài liệu VPS VSIS nếu đang tự vận hành máy chủ.

Bị mạo danh tên miền để lừa khách hàng

Nếu tên miền của bạn không có chính sách DMARC rõ ràng, kẻ khác có thể gửi email giả dạng [email protected] hoặc [email protected]. Người nhận thấy tên miền quen thuộc nên dễ tin hơn.

Kiểu mạo danh này thường dùng cho phishing, hóa đơn giả, link thanh toán giả, hoặc yêu cầu đổi mật khẩu. Thiệt hại không chỉ là mất tiền, mà còn là mất uy tín tên miền.

SPF và DKIM giúp chứng minh email hợp lệ. DMARC giúp nói với máy chủ nhận rằng nếu email không chứng minh được nguồn gốc thì nên làm gì.

Bạn không nên đợi đến khi khách hàng báo nhận email lừa đảo mới cấu hình. Với tên miền dùng cho kinh doanh, xác thực email nên làm ngay từ đầu.

Ba lớp xác thực email hoạt động cùng nhau

SPF DKIM DMARC: ba bản ghi này thực ra kiểm cái gì

SPF, DKIM và DMARC đều là bản ghi DNS TXT, nhưng mỗi bản ghi kiểm một phần khác nhau của quá trình gửi email. Hiểu đúng vai trò sẽ giúp bạn cấu hình ít lỗi hơn.

SPF giống danh sách nhân viên được phép gửi hàng thay công ty. Nếu người giao hàng không có tên trong danh sách, bên nhận có quyền nghi ngờ.

DKIM giống chữ ký niêm phong trên từng gói hàng. Nếu gói hàng bị sửa nội dung sau khi rời kho, chữ ký không còn khớp.

DMARC giống quy định nội bộ gửi cho bên nhận. Nếu người giao hàng không hợp lệ hoặc chữ ký sai, hãy vẫn nhận để theo dõi, đưa vào spam, hoặc từ chối hẳn.

Ba bản ghi này không thay thế nhau. Bạn nên cấu hình cả ba, vì mỗi bản ghi xử lý một lớp rủi ro khác nhau.

Ngoài ra, IP gửi mail cũng nên có PTR/rDNS đúng. Nếu dùng VPS, hãy kiểm tra phần quản lý IP hoặc liên hệ nhà cung cấp để trỏ reverse DNS về hostname như mail.domain.com.

Bạn có thể xem thêm các hướng dẫn DNS tại doc.vsis.net về DNS hoặc quản lý dịch vụ tại https://vsis.net/.

SPF: khai máy nào được phép gửi thay tên miền

SPF là viết tắt của Sender Policy Framework. Đây là bản ghi DNS cho biết những IP, hostname hoặc dịch vụ nào được phép gửi email với tên miền của bạn.

Ví dụ bạn có tên miền example.com và VPS gửi mail từ IP 203.0.113.10. Bạn có thể thêm bản ghi TXT cho tên miền gốc như sau:

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

Ý nghĩa cơ bản:

• v=spf1: khai báo đây là bản ghi SPF.
• ip4:203.0.113.10: IP IPv4 được phép gửi.
• -all: các nguồn khác không được phép gửi.

Nếu dùng cả IPv6, có thể thêm:

example.com. TXT "v=spf1 ip4:203.0.113.10 ip6:2001:db8::10 -all"

Nếu gửi mail qua dịch vụ bên thứ ba, họ thường yêu cầu thêm include. Ví dụ dạng tổng quát:

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

Bạn cần cẩn thận vì mỗi tên miền chỉ nên có một bản ghi SPF. Nếu tạo hai bản ghi TXT đều bắt đầu bằng v=spf1, nhiều máy chủ nhận sẽ coi SPF bị lỗi.

SPF kiểm tra đường đi của email dựa trên máy chủ gửi thực tế. Nó không ký nội dung thư, cũng không đảm bảo email không bị sửa.

Một điểm dễ nhầm là SPF thường kiểm tra domain trong envelope sender, không nhất thiết là địa chỉ hiển thị trong dòng From. Vì vậy chỉ có SPF là chưa đủ để chống giả mạo tên miền hiển thị.

Các cơ chế SPF thường gặp:

Với VPS riêng, cấu hình SPF tối thiểu thường là IP VPS cộng với chính sách cuối. Nếu mới triển khai, bạn có thể dùng ~all trong giai đoạn theo dõi, sau đó chuyển sang -all.

Ví dụ mềm hơn:

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

~all nghĩa là nguồn khác không được khuyến khích, nhưng chưa từ chối mạnh. -all nghĩa là nguồn khác không được phép.

DKIM: chữ ký số trên từng thư

DKIM là viết tắt của DomainKeys Identified Mail. Nó thêm chữ ký số vào header của từng email, để máy chủ nhận kiểm tra thư có đúng do hệ thống được ủy quyền ký hay không.

Khác với SPF, DKIM không chỉ quan tâm IP gửi. DKIM kiểm tra chữ ký tạo bằng private key trên mail server và public key công bố trong DNS.

Quy trình đơn giản:

1. Mail server tạo cặp khóa public key và private key.
2. Private key lưu trên VPS, dùng để ký email gửi đi.
3. Public key được đưa lên DNS dạng TXT.
4. Máy chủ nhận lấy public key từ DNS để kiểm tra chữ ký.

Bản ghi DKIM thường có dạng:

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

Trong đó selector là tên bộ khóa. Bạn có thể gặp các selector như default, mail, s1, google, hoặc dkim.

Ví dụ:

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

Trên VPS dùng Postfix, DKIM thường được cấu hình bằng OpenDKIM hoặc Rspamd. Tệp cấu hình có thể là opendkim.conf, KeyTable, SigningTable, tùy hệ điều hành và cách cài.

Một mô hình phổ biến:

• Postfix nhận yêu cầu gửi mail từ website hoặc ứng dụng.
• OpenDKIM ký email trước khi Postfix gửi ra Internet.
• DNS chứa public key để bên nhận xác minh.
• Gmail hoặc Outlook kiểm tra header DKIM-Signature.

DKIM đặc biệt hữu ích khi email đi qua hệ thống chuyển tiếp. Trong một số trường hợp forwarding làm SPF fail, nhưng DKIM vẫn pass nếu nội dung và header được ký không bị thay đổi.

Tuy nhiên, DKIM cũng có giới hạn. Nếu bạn ký sai domain, public key sai, hoặc mail server không gắn chữ ký, DKIM sẽ fail.

Bạn nên dùng khóa DKIM đủ mạnh, thường là 2048-bit nếu DNS provider hỗ trợ. Khóa 1024-bit hiện vẫn có nơi chấp nhận, nhưng không còn là lựa chọn tốt cho triển khai mới.

Khi đổi mail server hoặc đổi phần mềm ký mail, hãy tạo selector mới thay vì ghi đè vội selector cũ. Cách này giúp rollback dễ hơn nếu email bị lỗi xác thực.

Ví dụ bạn đang dùng default, có thể tạo thêm s2025. Sau khi kiểm tra ổn định, bạn mới gỡ selector cũ khỏi DNS.

DMARC: khi SPF hoặc DKIM fail thì làm gì

DMARC là viết tắt của Domain-based Message Authentication, Reporting, and Conformance. Nó dựa trên SPF và DKIM để quyết định cách xử lý email không đạt xác thực.

Bản ghi DMARC nằm ở subdomain đặc biệt _dmarc. Ví dụ:

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

Ý nghĩa:

• v=DMARC1: khai báo bản ghi DMARC.
• p=none: chỉ theo dõi, chưa yêu cầu chặn.
• rua=mailto:[email protected]: nơi nhận báo cáo tổng hợp.

DMARC không chỉ kiểm tra SPF pass hoặc DKIM pass. Nó còn kiểm tra alignment, tức domain xác thực có khớp với domain hiển thị trong From hay không.

Ví dụ email hiển thị From là [email protected]. Nếu SPF pass cho một domain khác không liên quan, DMARC có thể vẫn fail vì không align.

DMARC có ba chính sách chính:

Bản ghi theo dõi ban đầu nên đơn giản:

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

Sau khi ổn hơn:

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

Ở đây pct=50 nghĩa là áp dụng chính sách cho 50% email fail. Bạn có thể tăng dần lên 100%.

Khi đã chắc chắn:

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

DMARC còn có sp để áp dụng chính sách cho subdomain. Ví dụ:

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

Nếu bạn có nhiều subdomain gửi email như shop.example.com, app.example.com, mail.example.com, hãy kiểm tra kỹ trước khi đặt sp=reject.

Báo cáo DMARC thường là file XML nên khá khó đọc, nhưng rất có giá trị. Nó giúp bạn biết ai đang gửi email bằng tên miền của bạn.

Bạn có thể đọc thêm tài liệu chính thức về DMARC tại dmarc.org để nắm chuẩn gốc và các khuyến nghị triển khai.

Thứ tự triển khai an toàn: p=none rồi quarantine rồi reject

Cách an toàn nhất là không bật p=reject ngay từ đầu. Nếu làm sai, email hợp lệ của website, CRM, hệ thống hóa đơn, hoặc nhân viên có thể bị từ chối.

Bước đầu tiên là liệt kê tất cả nơi đang gửi email bằng tên miền. Với quản trị VPS, danh sách thường gồm:

• VPS chạy Postfix, Exim, Mailcow, CyberPanel, aaPanel hoặc DirectAdmin.
• Website WordPress, Laravel, Node.js, Magento, WooCommerce.
• Dịch vụ email công ty như Google Workspace hoặc Microsoft 365.
• Dịch vụ gửi mail marketing hoặc transactional.
• Hệ thống ticket, CRM, hóa đơn, giám sát server.

Sau đó bạn cấu hình SPF để bao gồm đủ nguồn gửi. Nếu VPS gửi trực tiếp, thêm IP VPS. Nếu dùng SMTP ngoài, thêm include theo hướng dẫn của dịch vụ đó.

Tiếp theo là bật DKIM cho từng hệ thống gửi. Nếu Google Workspace gửi mail, DKIM bật ở Google Admin. Nếu Postfix trên VPS gửi mail, bạn cấu hình OpenDKIM hoặc công cụ tương đương.

Khi SPF và DKIM đã có, tạo DMARC ở mức p=none. Giai đoạn này giúp bạn thu thập báo cáo mà không làm gián đoạn email.

Ví dụ:

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

Hai tham số adkim=s và aspf=s đặt alignment ở chế độ strict. Nếu chưa chắc, bạn có thể bỏ hai tham số này hoặc dùng chế độ mặc định relaxed.

Sau 1-2 tuần, bạn kiểm tra báo cáo DMARC và log mail server. Nếu thấy nguồn gửi hợp lệ đều pass, có thể chuyển sang p=quarantine.

Ví dụ:

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

Bạn tăng dần pct từ 25 lên 50, rồi 100. Cách này giảm rủi ro khi còn sót một hệ thống gửi mail chưa cấu hình đúng.

Khi mọi thứ ổn định, chuyển sang p=reject. Đây là trạng thái tốt nhất để bảo vệ tên miền khỏi bị mạo danh.

Bạn cũng nên kiểm tra bằng công cụ bên ngoài sau mỗi lần sửa DNS. Có thể dùng dig, nslookup, hoặc các dịch vụ kiểm tra header email.

Ví dụ kiểm tra SPF:

dig TXT example.com

Kiểm tra DMARC:

dig TXT _dmarc.example.com

Kiểm tra DKIM:

dig TXT default._domainkey.example.com

Nếu bạn quản lý DNS tại VSIS, có thể tham khảo khu vực hướng dẫn tại doc.vsis.net và trang dịch vụ tại vsis.net.

Sai lầm phổ biến

Tạo nhiều bản ghi SPF cho cùng một tên miền

Đây là lỗi rất hay gặp. Bạn thêm một bản ghi SPF cho VPS, sau đó thêm tiếp một bản ghi SPF cho Google Workspace, rồi thêm tiếp cho dịch vụ email marketing.

Kết quả là tên miền có nhiều TXT cùng bắt đầu bằng v=spf1. Máy chủ nhận có thể trả lỗi SPF permerror và coi email không hợp lệ.

Cách đúng là gộp vào một bản ghi duy nhất. Ví dụ:

example.com. TXT "v=spf1 ip4:203.0.113.10 include:_spf.google.com include:spf.mailservice.example -all"

Dùng +all trong SPF

Bản ghi +all gần như nói rằng ai cũng được phép gửi email thay tên miền của bạn. Đây là cấu hình rất nguy hiểm.

Ví dụ không nên dùng:

example.com. TXT "v=spf1 +all"

Nếu thấy bản ghi này, bạn nên sửa ngay. Trong đa số trường hợp, hãy dùng ~all khi thử nghiệm và -all khi đã chắc.

Bật DMARC p=reject quá sớm

p=reject rất tốt khi hệ thống đã chuẩn. Nhưng nếu chưa kiểm tra đủ nguồn gửi, bạn có thể tự chặn email hợp lệ.

Ví dụ website gửi email đơn hàng qua VPS nhưng DKIM chưa ký. Khi DMARC reject được bật, khách hàng có thể không nhận được email xác nhận.

Hãy đi theo lộ trình p=none, rồi p=quarantine, rồi mới p=reject.

Quên cấu hình DKIM cho từng nguồn gửi

Nhiều người bật DKIM cho mail server chính nhưng quên dịch vụ gửi newsletter, CRM hoặc website. Kết quả là một phần email pass, một phần fail.

Bạn cần kiểm tra từng luồng gửi. Email nhân viên, email hệ thống, email marketing và email giao dịch có thể đi qua các máy chủ khác nhau.

Nhầm giữa domain gửi và hostname VPS

Hostname VPS có thể là mail.example.com, nhưng địa chỉ From lại là [email protected]. SPF, DKIM, DMARC cần được cấu hình theo domain dùng trong email, không chỉ hostname.

PTR/rDNS cũng nên trỏ hợp lý về hostname mail. Tuy nhiên PTR không thay thế SPF, DKIM hoặc DMARC.

Không kiểm tra header email sau khi cấu hình

Sau khi cấu hình DNS, nhiều người gửi thử một email rồi chỉ nhìn xem có vào Inbox không. Cách này chưa đủ.

Bạn nên mở phần Show original trong Gmail hoặc View message source trong Outlook. Hãy tìm các dòng như spf=pass, dkim=pass, dmarc=pass.

Nếu một trong ba fail, cần đọc lý do fail trước khi chuyển DMARC sang chính sách mạnh hơn.

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

Có cần đủ cả SPF, DKIM, DMARC không?

Có. SPF kiểm nguồn gửi, DKIM kiểm chữ ký email, DMARC đặt chính sách xử lý khi xác thực fail.

Nếu chỉ có SPF, bạn vẫn thiếu lớp kiểm tra chữ ký và alignment. Nếu chỉ có DKIM, bạn chưa khai báo rõ IP nào được phép gửi.

VPS mới mua có gửi mail tốt ngay không?

Không chắc. VPS cần IP sạch, PTR/rDNS đúng, hostname hợp lý, SPF, DKIM, DMARC đầy đủ và nội dung email không spam.

Nếu IP từng bị lạm dụng, email có thể vẫn vào spam dù cấu hình đúng. Bạn nên kiểm tra blacklist và theo dõi phản hồi từ Gmail, Outlook.

SPF pass nhưng DMARC fail là vì sao?

Nguyên nhân thường là SPF không align với domain trong From. Nói đơn giản, email có thể pass SPF cho một domain kỹ thuật khác, nhưng không khớp domain người nhận nhìn thấy.

DKIM cũng tương tự. DKIM pass nhưng ký bằng domain khác thì DMARC có thể không pass.

Có nên dùng p=reject ngay để chống giả mạo không?

Không nên nếu bạn chưa kiểm kê hết nguồn gửi. p=reject mạnh nhưng dễ gây mất email hợp lệ nếu cấu hình thiếu.

Bạn nên bắt đầu bằng p=none, đọc báo cáo, sửa lỗi, rồi tăng dần lên quarantine và reject.

Một tên miền có nhiều DKIM selector được không?

Được. DKIM cho phép nhiều selector, ví dụ default, s1, google, mail2025.

Điều này hữu ích khi bạn có nhiều hệ thống gửi email hoặc muốn xoay khóa an toàn. Mỗi selector sẽ có bản ghi TXT riêng dưới _domainkey.

DNS cập nhật xong bao lâu thì có hiệu lực?

Tùy TTL và DNS cache. Thường mất vài phút đến vài giờ, đôi khi lâu hơn nếu bản ghi cũ có TTL cao.

Bạn có thể kiểm tra bằng dig TXT example.com hoặc dùng DNS checker bên ngoài. Khi kiểm tra, nhớ nhìn đúng nameserver đang authoritative cho tên miền.

Tóm tắt nhanh

• SPF DKIM DMARC là bộ ba xác thực email rất quan trọng khi gửi mail từ VPS.
• SPF khai báo IP hoặc máy chủ nào được phép gửi email thay tên miền.
• DKIM ký từng email để bên nhận kiểm tra thư có bị sửa và có đúng nguồn ký không.
• DMARC quy định cách xử lý email fail SPF hoặc DKIM, gồm none, quarantine, reject.
• Triển khai an toàn nên bắt đầu bằng p=none, theo dõi báo cáo, rồi tăng dần chính sách.
• Tránh tạo nhiều bản ghi SPF, tránh +all, và không bật p=reject khi chưa kiểm tra đủ nguồn gửi.
• Sau khi cấu hình, luôn kiểm tra header email để xác nhận spf=pass, dkim=pass, dmarc=pass.