Giải thích SPF, DKIM và DMARC bằng ngôn ngữ dễ hiểu (kèm ví dụ)

Vì sao email lại cần những thứ này?

Sự thật hơi khó nghe về email là thế này: nó được thiết kế từ đầu những năm 1980 cho một mạng lưới nhỏ gồm những người tin tưởng lẫn nhau. Mặc định, bất kỳ ai cũng có thể gửi một email tự nhận là từ [email protected]. Không có gì trong giao thức cơ bản ngăn được họ.

SPF, DKIM và DMARC được bổ sung sau này để khắc phục điều đó. Kết hợp lại, chúng giúp phía nhận như Gmail, Outlook hay Yahoo trả lời một câu hỏi: email này có thực sự đến từ tên miền mà nó tự nhận không? Nếu câu trả lời là không, email sẽ vào thư mục spam hoặc bị từ chối. Còn nếu tên miền của chính bạn chưa thiết lập chúng, email thật của bạn có thể bị đối xử như email giả.

Một phép so sánh nhanh sẽ giúp bạn dễ hình dung:

• SPF là danh sách khách mời: những máy chủ nào được phép gửi email thay cho tên miền của bạn.
• DKIM là con dấu sáp: một chữ ký chứng minh email không bị thay đổi trên đường đi.
• DMARC là lời dặn cho bảo vệ: phải làm gì khi một email không vượt qua được bước kiểm tra, và cần báo cho ai.

SPF: danh sách khách mời

SPF (Sender Policy Framework) là một dòng văn bản duy nhất mà bạn khai báo trong DNS của tên miền. Nó liệt kê các máy chủ và dịch vụ được phép gửi email thay mặt bạn. Khi Gmail nhận được email từ tên miền của bạn, nó sẽ tra danh sách đó và kiểm tra xem máy chủ đã gửi email có nằm trong danh sách không.

Một bản ghi SPF điển hình trông như thế này:

v=spf1 include:_spf.google.com include:sendgrid.net ~all

Đọc từ trái sang phải:

• v=spf1: "đây là một bản ghi SPF".
• include:_spf.google.com: Google Workspace được phép gửi email thay mình.
• include:sendgrid.net: SendGrid cũng vậy (chẳng hạn cho email từ ứng dụng của mình).
• ~all: mọi thứ khác có lẽ không phải mình, nên hãy nghi ngờ. (-all nghĩa là "chắc chắn không phải mình, từ chối luôn".)

Ngoài ra còn có giới hạn 10 lượt tra cứu DNS trong một bản ghi SPF. Mỗi include: đều được tính, và cả các include lồng bên trong chúng cũng vậy. Nếu bạn dùng nhiều dịch vụ, bạn có thể vượt giới hạn mà không hề hay biết, và khi đó SPF sẽ thất bại với tất cả mọi người.

DKIM: con dấu sáp

SPF kiểm tra email đến từ đâu. DKIM (DomainKeys Identified Mail) kiểm tra xem bản thân email có bị can thiệp hay không. Dịch vụ email của bạn ký mọi thư gửi đi bằng một khóa riêng mà chỉ nó biết. Bạn khai báo khóa công khai tương ứng trong DNS. Máy chủ nhận dùng khóa công khai đó để kiểm tra chữ ký.

Nếu ai đó sửa email trên đường đi, dù chỉ một chữ trong nội dung, chữ ký sẽ không còn khớp nữa. Giống như con dấu sáp trên những lá thư ngày xưa: nếu dấu bị vỡ, bạn biết đã có người mở thư.

Bản ghi DKIM được khai báo ở một tên đặc biệt, ví dụ google._domainkey.yourdomain.com, và giá trị của nó trông đại khái như thế này:

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAu1...

Tin vui là bạn không bao giờ phải tự viết cái này. Nhà cung cấp email sẽ tạo nó, bạn chỉ cần chép vào DNS. Từ đứng trước ._domainkey (ở đây là google) được gọi là selector. Nó chỉ đơn giản giúp bạn có nhiều khóa, mỗi dịch vụ một khóa.

DMARC: lời dặn cho bảo vệ

SPF và DKIM cung cấp dữ kiện cho máy chủ nhận. DMARC (Domain-based Message Authentication, Reporting and Conformance) cho nó biết phải làm gì với những dữ kiện đó. Nó còn thêm một quy tắc quan trọng gọi là alignment (căn chỉnh): tên miền vượt qua SPF hoặc DKIM phải trùng với tên miền mà người đọc thực sự nhìn thấy ở dòng "Từ". Nếu không có quy tắc này, kẻ lừa đảo có thể vượt qua SPF bằng tên miền của chính họ trong khi lại hiển thị tên miền của bạn.

Bản ghi DMARC nằm ở _dmarc.yourdomain.com và trông như thế này:

v=DMARC1; p=none; rua=mailto:[email protected]

• p=none: chỉ theo dõi, chưa chặn gì cả. Rất hợp để bắt đầu.
• p=quarantine: đưa các email không đạt vào thư mục spam.
• p=reject: từ chối hoàn toàn các email không đạt. Mức bảo vệ mạnh nhất.
• rua=mailto:...: nơi các bên nhận gửi báo cáo tổng hợp hằng ngày cho bạn.

Những báo cáo đó chính là viên ngọc ẩn. Chúng cho bạn thấy mọi máy chủ đang gửi email bằng tên miền của bạn, kể cả những dịch vụ bạn đã quên mất và bất kỳ ai đang cố mạo danh bạn.

Thiết lập từng bước

Giả sử bạn sở hữu myshop.com, dùng Google Workspace cho hộp thư và một dịch vụ như SendGrid hoặc Mailgun để gửi xác nhận đơn hàng. Đây là thứ tự mà mình sẽ làm:

1. Liệt kê mọi thứ gửi email dưới tên miền của bạn: nhà cung cấp hộp thư, website hoặc ứng dụng, công cụ gửi bản tin, hệ thống hỗ trợ khách hàng, phần mềm xuất hóa đơn. Đây là bước mọi người hay bỏ qua, và cũng là bước gây ra nhiều rắc rối nhất về sau.
2. Tạo một bản ghi SPF duy nhất trong DNS (một bản ghi TXT trên myshop.com) bao gồm tất cả các dịch vụ đó, kết thúc bằng ~all.
3. Bật DKIM trong từng dịch vụ. Mỗi dịch vụ sẽ cho bạn một bản ghi để chép vào DNS. Sau đó bấm "verify" hoặc "start authenticating" trong dịch vụ đó.
4. Thêm bản ghi DMARC với p=none và một địa chỉ nhận báo cáo, trên _dmarc.myshop.com.
5. Đợi một đến hai tuần rồi đọc các báo cáo. Sửa những nguồn gửi hợp lệ nào đang không đạt.
6. Siết chặt chính sách lên p=quarantine, rồi sau đó là p=reject, khi bạn đã chắc chắn mọi email thật của mình đều đạt.

Cách kiểm tra trên bất kỳ email nào bạn nhận được

Bạn không cần công cụ nào cả. Ứng dụng email của bạn đã hiển thị sẵn kết quả:

• Gmail: mở email, bấm vào biểu tượng ba chấm, rồi chọn Hiển thị bản gốc. Ở phía trên bạn sẽ thấy các dòng như SPF: PASS, DKIM: PASS và DMARC: PASS.
• Outlook: mở thư, chọn View rồi View message details (hoặc Message source), sau đó tìm header Authentication-Results.
• Apple Mail: View, rồi Message, rồi All Headers.

Một header thật trông đại khái như thế này:

Authentication-Results: mx.google.com;
  dkim=pass header.d=myshop.com;
  spf=pass smtp.mailfrom=myshop.com;
  dmarc=pass (p=QUARANTINE) header.from=myshop.com

Ba lần pass và các tên miền khớp nhau: email đó là thật. Nếu bạn thấy fail, hoặc các tên miền không khớp với người gửi mà bạn nhìn thấy, hãy cẩn thận. Đó là một trong những dấu hiệu cảnh báo mà mình đã nói đến trong bài cách nhận biết email phishing.

Nếu bạn đang thiết lập tên miền của riêng mình, một cách kiểm tra nhanh là gửi một email đến hộp thư tạm thời và một địa chỉ Gmail, rồi xem header trên bản nhận được ở Gmail. Chỉ mất hai phút, và bạn sẽ thấy chính xác những gì thế giới bên ngoài nhìn thấy.

Các lỗi thường gặp và cách sửa nhanh

• "SPF: softfail" hoặc "neutral": máy chủ gửi email không có trong bản ghi SPF của bạn. Hãy thêm dịch vụ đó bằng dòng include: mà họ cung cấp.
• "SPF permerror": thường là do có hai bản ghi SPF, hoặc vượt quá 10 lượt tra cứu. Gộp lại thành một bản ghi và bỏ những dịch vụ bạn không còn dùng.
• "DKIM: fail" sau khi sửa mẫu email: có thứ gì đó đã sửa email sau khi nó được ký (một số dịch vụ chuyển tiếp và phần chân email làm vậy). Hãy gửi trực tiếp rồi kiểm tra lại.
• DMARC thất bại dù SPF đã đạt: vấn đề nằm ở alignment. SPF đạt cho tên miền của dịch vụ gửi email, chứ không phải của bạn. Hãy bật DKIM với tên miền của chính bạn trong dịch vụ đó, hoặc thiết lập một tên miền return-path tùy chỉnh.
• Email vẫn vào spam dù mọi thứ đều đạt: xác thực chứng minh bạn là ai, chứ không chứng minh người ta muốn nhận email của bạn. Nội dung, uy tín gửi thư và tỷ lệ bị báo cáo cũng rất quan trọng. Mình đã viết thêm về chuyện này trong bài vì sao email từ ứng dụng lại vào spam.

Bạn có thực sự cần cả ba không?

Có. Từ năm 2024, Gmail và Yahoo yêu cầu SPF, DKIM và một bản ghi DMARC đối với bất kỳ ai gửi email với số lượng lớn, và ngay cả những người gửi nhỏ cũng có tỷ lệ gửi thành công tốt hơn hẳn khi có đủ cả ba. Quan trọng hơn, DMARC với p=reject chính là thứ ngăn kẻ lừa đảo gửi email giả mạo dưới tên bạn đến chính khách hàng của bạn.

Việc thiết lập chỉ mất một buổi chiều. Sau đó, nó âm thầm bảo vệ tên miền của bạn mỗi ngày. Nếu bạn có tên miền và cứ trì hoãn mãi chuyện này, thì đây chính là lời nhắc dành cho bạn. Hãy bắt đầu với p=none ngay hôm nay. Bạn có thể siết chặt sau.