SPF, DKIM, DMARC: xác thực tên miền gửi email để thư vào được hộp thư

Email marketing và email giao dịch (xác nhận đơn, đặt lại mật khẩu, hóa đơn) đều đi ra từ tên miền của doanh nghiệp, nhưng hộp thư nhận chỉ tin tên miền đó khi nó chứng minh được người gửi là chủ thật. SPF, DKIM và DMARC là 3 cơ chế làm việc này, và từ tháng 2/2024 Google và Yahoo đòi chúng với người gửi số lượng lớn.

Bài dựa trên tiêu chuẩn IETF (RFC 7208, RFC 6376, RFC 9989) và trang trợ giúp chính thức của Google, Yahoo, Microsoft, đối chiếu đến ngày 22/10/2026. Bài trả lời: mỗi cơ chế làm gì, vì sao thư vẫn trượt dù SPF hoặc DKIM báo đạt, nên đi lộ trình DMARC thế nào và kiểm tra ra sao.

Điểm chính

• SPF nêu máy chủ nào được gửi thư dưới một tên miền, DKIM gắn chữ ký mật mã vào thư, còn DMARC chỉ đạt khi SPF hoặc DKIM xác thực một tên miền khớp với tên miền trong dòng From.
• Căn chỉnh (alignment) là chỗ hay bị bỏ qua: SPF hay DKIM có thể báo "pass" mà DMARC vẫn "fail" nếu tên miền xác thực khác tên miền From.
• SPF chỉ được có 1 bản ghi v=spf1 cho mỗi tên miền và tối đa 10 lần tra cứu DNS; vượt giới hạn hoặc có 2 bản ghi thì kết quả là permerror (RFC 7208).
• Người gửi hơn 5.000 thư mỗi ngày tới Gmail cá nhân cần SPF, DKIM, DMARC (tối thiểu p=none), hủy đăng ký một cú nhấp cho thư marketing và tỷ lệ báo thư rác dưới 0,30%. Yahoo yêu cầu tương tự, không công bố ngưỡng.
• RFC 9989 (tháng 5/2026) thay RFC 7489, bỏ thẻ pct, thêm thẻ t và np. Lộ trình an toàn là p=none kèm rua, sửa mọi nguồn gửi hợp lệ, rồi mới quarantine và reject.
• Kiểm tra bằng Google Postmaster Tools (chỉ Gmail cá nhân, cập nhật trong khoảng 24 giờ) và dòng Authentication-Results trong header thư nhận.

SPF, DKIM và DMARC khác nhau thế nào

Theo RFC 7208 (tháng 4/2014), SPF (Sender Policy Framework) cho chủ tên miền công bố danh sách máy chủ được phép gửi thư. Bên nhận kiểm tra tên miền trong lệnh MAIL FROM (Return-Path, nơi nhận thư trả về) và cả tên miền HELO.

Theo RFC 6376 (tháng 9/2011), DKIM gắn vào thư 1 chữ ký mật mã. Tên miền chịu trách nhiệm nằm ở thẻ d=, selector (nhãn chọn khóa) ở thẻ s=, khóa công khai nằm ở bản ghi TXT tại selector._domainkey.tên-miền.

Theo RFC 9989 (tháng 5/2026), DMARC đòi SPF hoặc DKIM phải xác thực một tên miền khớp với tên miền trong dòng From, rồi cho chủ tên miền nêu cách xử lý thư không đạt và nơi nhận báo cáo.

Vì sao cần cả 3? Theo Microsoft Learn (cập nhật 3/7/2026), SPF không so tên miền MAIL FROM với dòng From, nên kẻ xấu đăng ký tên miền riêng, cấu hình SPF đạt rồi gắn From giả; DKIM cũng vậy. DMARC khép khoảng trống bằng căn chỉnh.

Căn chỉnh tên miền From: chỗ nhiều thư trượt

Căn chỉnh nghĩa là tên miền đã xác thực phải khớp tên miền trong dòng From. Theo RFC 9989, chế độ relaxed (mặc định) chấp nhận cùng tên miền tổ chức, chế độ strict đòi giống hệt nhau.

Với SPF, DMARC chỉ xét tên miền MAIL FROM. Dịch vụ gửi thư bên thứ ba thường đặt Return-Path về tên miền của họ: SPF đạt nhưng không căn chỉnh với From của doanh nghiệp. Khi đó chỉ còn DKIM gánh DMARC, nên chữ ký phải có d= là tên miền của doanh nghiệp.

Thư đạt DMARC khi ít nhất 1 danh tính căn chỉnh; RFC 9989 khuyến nghị có cả hai. Google cảnh báo strict có thể khiến thư từ tên miền con bị từ chối hoặc vào thư rác, còn relaxed thường đủ (Set up DMARC, cập nhật 20/10/2026).

SPF: 1 bản ghi, tối đa 10 lần tra cứu DNS

Theo RFC 7208, tên miền có hơn 1 bản ghi bắt đầu bằng v=spf1 cho kết quả permerror (lỗi vĩnh viễn). RFC cũng giới hạn ở 10 thành phần gây truy vấn DNS: include, a, mx, ptr, exists và redirect. Các thành phần ip4, ip6, all không tính; vượt 10 là permerror.

Cách đếm hay gây nhầm: trang Set up SPF của Google (20/10/2026) viết "tối đa 10 thẻ include", nhưng RFC đếm cả các include lồng bên trong mỗi dịch vụ. Microsoft Learn nói mỗi include cần ít nhất 1 lần tra cứu và có thể nhiều hơn.

Khi chạm giới hạn: bỏ dịch vụ không dùng nữa, thay include bằng ip4 hoặc ip6 nếu nhà cung cấp cam kết IP cố định, và tách luồng gửi sang tên miền con. Microsoft Learn khuyên dùng tên miền con cho dịch vụ gửi thư hàng loạt không do mình kiểm soát.

Google khuyến nghị kết thúc bằng ~all (softfail); Microsoft Learn gợi ý bắt đầu bằng ~all rồi chuyển -all khi biết hết nguồn gửi. Vì SPF thường hỏng khi chuyển tiếp, RFC 9989 dặn tên miền dùng p=reject không được dựa riêng vào SPF.

DKIM: khóa đủ dài, mỗi dịch vụ 1 selector

Theo RFC 8301 (tháng 1/2018), người ký không được dùng rsa-sha1, phải dùng khóa RSA từ 1024 bit và nên dùng từ 2048 bit. Google và Yahoo cũng yêu cầu từ 1024 bit và khuyến nghị 2048 bit khi gửi tới họ.

Mỗi dịch vụ gửi thư (marketing, CRM, hóa đơn) nên ký bằng khóa và selector riêng dưới tên miền của doanh nghiệp, để thay khóa của một dịch vụ không động đến dịch vụ khác.

Yêu cầu của Google, Yahoo và Microsoft cho người gửi hàng loạt

Google. Trang Email sender guidelines (không ghi ngày, đọc 22/10/2026) đặt yêu cầu từ 1/2/2024. Mọi người gửi tới Gmail cần SPF hoặc DKIM, DNS xuôi và ngược (PTR) hợp lệ, TLS, định dạng RFC 5322 và tỷ lệ báo thư rác dưới 0,3%.

Người gửi hơn 5.000 thư mỗi ngày cần thêm cả SPF và DKIM, DMARC (chính sách có thể là none), From căn chỉnh với SPF hoặc DKIM, và hủy đăng ký một cú nhấp kèm liên kết hủy rõ trong thân thư cho thư marketing. Google khuyên giữ tỷ lệ báo thư rác dưới 0,10%.

Theo FAQ của Google (không ghi ngày), yêu cầu áp dụng cho thư tới Gmail cá nhân, không áp cho tài khoản Workspace. Người gửi gần 5.000 thư trở lên trong 24 giờ bị xếp là người gửi hàng loạt, thư của tên miền con cộng vào tên miền chính, và trạng thái này không hết hạn. Từ tháng 11/2025 Google siết thực thi, gồm từ chối tạm thời và vĩnh viễn.

Hủy đăng ký một cú nhấp chỉ bắt buộc với thư marketing; thư giao dịch như đặt lại mật khẩu được loại trừ, và Google khuyến nghị xử lý trong 48 giờ. Theo RFC 8058 (tháng 1/2017), thư cần header List-Unsubscribe và List-Unsubscribe-Post, và chữ ký DKIM phải bao cả hai.

Yahoo. Trang Sender Requirements & Recommendations (không ghi ngày) tương tự: SPF và DKIM, DMARC tối thiểu p=none và phải đạt, căn chỉnh From, hủy đăng ký một cú nhấp xử lý trong 2 ngày, tỷ lệ báo thư rác dưới 0,3%. FAQ của Yahoo cho biết áp dụng cả AOL, không công bố ngưỡng khối lượng, và khuyên tách thư marketing khỏi thư giao dịch.

Microsoft. Bài thông báo của Microsoft về người gửi khối lượng lớn tới Outlook.com chặn công cụ của Click Star (lỗi 403), nên chưa đọc nguyên văn. Theo tóm tắt kết quả tìm kiếm của trang đó, ngưỡng là hơn 5.000 thư mỗi ngày và cần SPF, DKIM, DMARC. Nguồn thứ cấp mâu thuẫn về hậu quả khi không đạt, nên bài không khẳng định.

Lộ trình DMARC: p=none, quarantine, reject và báo cáo

RFC 9989 mô tả thứ tự: SPF và DKIM căn chỉnh, hộp thư nhận báo cáo, bản ghi DMARC p=none kèm rua (chế độ giám sát), đọc báo cáo, sửa mọi luồng thư hợp lệ chưa đạt, rồi mới cân nhắc thực thi. Việc sửa phải xong trước khi thực thi (chữ MUST trong RFC), và có thể mất nhiều tháng tùy nhịp gửi.

Với tên miền có người dùng gửi vào danh sách thư công cộng, RFC khuyên không dùng p=reject; nếu vẫn dùng thì p=none ít nhất 1 tháng, rồi quarantine tương đương. Google nhanh hơn: p=none khoảng 1 tuần, rồi quarantine cho tỷ lệ nhỏ (ví dụ 10% hoặc 1%) và tăng dần, sau khi SPF, DKIM chạy ít nhất 48 giờ.

RFC 9989 thay RFC 7489 (tháng 3/2015) và RFC 9091 (thử nghiệm): bỏ thẻ pct; thẻ t=y báo bên nhận áp chính sách thấp hơn 1 bậc khi thử nghiệm; đưa thẻ np của RFC 9091, dành cho tên miền con không tồn tại, vào chuẩn; tìm tên miền tổ chức bằng DNS Tree Walk. Báo cáo tách sang RFC 9990 (tổng hợp) và RFC 9991 (từng thư lỗi).

Google (Recommended DMARC rollout, 20/10/2026) và Microsoft Learn (Set up DMARC, 17/7/2026) vẫn viết pct trong bản ghi mẫu, Yahoo FAQ vẫn dẫn RFC 7489. Click Star suy luận chuyển tiếp sẽ kéo dài.

Báo cáo rua là tệp XML, thường theo 1 ngày UTC, nên nén gzip (RFC 9990). Nếu địa chỉ nhận ở tên miền khác, tên miền đó phải đăng bản ghi cho phép dạng _report._dmarc. Báo cáo ruf có thể chứa nội dung thư thật, Gmail không hỗ trợ ruf (theo Google), nên rua là chính.

Bản ghi DNS minh họa với example.com

3 bản ghi mẫu với tên miền example.com và dịch vụ giả định, khóa công khai rút gọn; hãy thay bằng giá trị do nhà cung cấp gửi thư cấp.

example.com.                TXT "v=spf1 ip4:203.0.113.10 include:spf.mailer.example.net ~all"
s1._domainkey.example.com.  TXT "v=DKIM1; k=rsa; p=MIIBIjANBg...(rút gọn)"
_dmarc.example.com.         TXT "v=DMARC1; p=none; rua=mailto:[email protected]"

SPF cho phép 1 địa chỉ IP và 1 dịch vụ gửi thư, DKIM đặt khóa tại selector s1, DMARC ở chế độ giám sát.

Cách kiểm tra: Postmaster Tools và Authentication-Results

Google Postmaster Tools có bảng Compliance status, Spam rate, Authentication, Delivery errors. Dữ liệu chỉ cho thư tới Gmail cá nhân, không thời gian thực (thường trong 24 giờ) và có thể thiếu vào ngày gửi ít thư; bảng Compliance cần tới 7 ngày để phản ánh thay đổi.

Để thêm tên miền, chọn tên miền d= của DKIM hoặc tên miền SPF (Return-Path), rồi xác minh bằng bản ghi TXT hoặc CNAME. Google cho biết bảng Domain và IP Reputation sẽ ngừng.

Với từng thư, mở trong Gmail, chọn "Show original" để xem header (theo Google), rồi tìm dòng Authentication-Results. RFC 8601 định nghĩa header này để ghi kết quả spf, dkim, dmarc mà bên nhận đã tính.

Ý nghĩa với doanh nghiệp Việt Nam

Click Star không tìm thấy số đo công khai về tỷ lệ doanh nghiệp Việt Nam đã cấu hình DMARC. Suy luận kỹ thuật: doanh nghiệp nhỏ và vừa thường gửi thư từ nhiều nơi (hộp thư công ty, CRM, email marketing, biểu mẫu website, kế toán), mỗi nơi cần có trong SPF và có chữ ký DKIM căn chỉnh.

Yêu cầu của Google và Yahoo gắn với người nhận, không gắn với nơi đặt máy chủ: danh sách vài chục nghìn người nhận gửi theo đợt có thể chạm 5.000 thư trong 24 giờ.

Đánh giá của Click Star. Xác thực email là hạ tầng, không phải tính năng của một công cụ marketing. Nếu chỉ cấu hình trong từng công cụ, mỗi lần đổi nhà cung cấp là một lần thư có thể rơi vào spam mà không ai hay.

Click Star cho rằng nên giữ bản kiểm kê nguồn gửi, tách luồng marketing và giao dịch sang tên miền con, đọc rua đều, và chỉ siết lên reject khi báo cáo sạch qua nhiều chu kỳ. Công khai lợi ích: Click Star làm digital marketing, CRM và tích hợp hệ thống.

Lộ trình 30 ngày cho doanh nghiệp bắt đầu từ đầu

Khung tham khảo của Click Star, không lấy từ nguồn ngoài; thứ tự bám RFC 9989, số ngày có thể kéo dài theo nhịp gửi thư.

• Ngày 1 đến 3: liệt kê mọi hệ thống gửi thư dưới tên miền và tên miền From mỗi hệ thống dùng.
• Ngày 4 đến 7: gộp thành 1 bản ghi SPF (không quá 10 lần tra cứu), bật DKIM khóa 2048 bit cho từng hệ thống với d= là tên miền của doanh nghiệp.
• Ngày 8 đến 14: đăng DMARC p=none kèm rua về hộp thư riêng, gửi thử từ từng hệ thống và đọc Authentication-Results.
• Ngày 15 đến 30: đọc rua hằng ngày, sửa luồng chưa căn chỉnh, thêm hủy đăng ký một cú nhấp, thêm tên miền vào Postmaster Tools.
• Sau ngày 30: khi báo cáo đã sạch mới chuyển quarantine và theo dõi; chuyển reject khi mọi nguồn hợp lệ đều đạt.

Những sai lầm thường gặp

1. Đăng 2 bản ghi SPF cho cùng một tên miền (thường do thêm dịch vụ ở bản ghi riêng), khiến kết quả là permerror.
2. Quên dịch vụ gửi thư bên thứ ba như CRM, biểu mẫu website, hệ thống hóa đơn, nên thư của chúng rớt khi chuyển sang quarantine hoặc reject.
3. Chồng nhiều include khiến SPF vượt 10 lần tra cứu mà không đếm lại sau mỗi lần thêm dịch vụ.
4. Coi "SPF pass" hoặc "DKIM pass" là đủ trong khi tên miền xác thực khác tên miền From, nên DMARC vẫn fail.
5. Chuyển DMARC sang reject quá sớm, khi báo cáo chưa phủ hết luồng thư hoặc người dùng còn gửi vào danh sách thư công cộng.
6. Trộn thư marketing và thư giao dịch chung một tên miền hoặc IP, nên một đợt bị báo thư rác kéo theo thư xác nhận đơn.
7. Đặt rua về hộp thư cá nhân rồi không ai đọc; Google khuyên dùng hộp thư riêng hoặc dịch vụ phân tích.

Điều chưa biết

Click Star chưa có số đo về tỷ lệ doanh nghiệp Việt Nam dùng DMARC, chưa đọc được bài của Microsoft và chưa biết nhà cung cấp thư trong nước xử lý thư không đạt ra sao. Xác thực không bảo đảm thư vào hộp thư chính; Google chỉ nói thư đã xác thực ít bị từ chối hoặc đánh dấu thư rác hơn.

Trang sender guidelines, FAQ của Google và trang của Yahoo không ghi ngày cập nhật. Ngưỡng của Google viết là "hơn 5.000" ở một chỗ và "gần 5.000 hoặc hơn" ở chỗ khác. Chưa rõ bên nhận triển khai DNS Tree Walk của RFC 9989 đến đâu và xử lý thẻ pct cũ ra sao.