Cách đọc kết quả SPF, DKIM và DMARC trong tiêu đề email

Tiêu đề email thường chứa kết quả SPF, DKIM và DMARC. Các cơ chế này cung cấp bằng chứng về các lĩnh vực và hệ thống liên quan đến việc phân phối. Họ không kiểm tra mọi hình thức lừa dối và không chứng minh rằng tin nhắn, người gửi hoặc liên kết là an toàn.

Hướng dẫn này giải thích tóm tắt kết quả do Once Email bộ phân tích tiêu đề email tạo ra. Máy phân tích đọc văn bản được dán cục bộ trong trình duyệt. Nó không thực hiện tra cứu DNS, danh tiếng, phần mềm độc hại hoặc chính sách trực tiếp.

SPF: hệ thống này có được cấp phép cho miền bao không?

Khung chính sách người gửi cho phép miền xuất bản hệ thống nào được phép gửi bằng cách sử dụng danh tính SPF. Hệ thống nhận so sánh người gửi kết nối với chính sách đã xuất bản đó và ghi lại kết quả như pass, fail, softfail, neutral hoặc none.

SPF không chỉ đơn giản là kiểm tra địa chỉ mà một người nhìn thấy trong trường Từ hiển thị. DMARC sử dụng kết quả SPF cho nhận dạng SMTP MAIL FROM rồi đánh giá xem miền của nó có phù hợp với miền tác giả hiển thị hay không.

Việc chuyển tiếp có thể làm phức tạp SPF vì máy chủ chuyển tiếp trở thành hệ thống kết nối với người nhận cuối cùng. Do đó, kết quả SPF không thành công cần có ngữ cảnh; bản thân nó không phải là một phán quyết hoàn chỉnh về thông điệp.

DKIM: phần đã ký của tin nhắn có hợp lệ không?

Thư được xác định bằng khóa miền thêm chữ ký mật mã được liên kết với miền ký. Người nhận lấy khóa chung từ DNS và kiểm tra xem các trường tiêu đề và nội dung đã ký có còn hợp lệ hay không.

Thẻ DKIM là bằng chứng cho thấy tài liệu đã ký được xác thực cho miền ký. Nó không chứng minh rằng tên hiển thị là trung thực, mọi thành phần hiển thị đều được ký tên hoặc trang web được liên kết là an toàn. Hệ thống gửi thư cũng có thể sửa đổi tin nhắn một cách hợp pháp theo cách phá vỡ chữ ký.

DMARC: danh tính được xác thực có phù hợp với miền tác giả hiển thị không?

DMARC xây dựng trên SPF và DKIM. Nó so sánh miền SPF hoặc DKIM đã xác thực với miền trong địa chỉ Từ hiển thị và áp dụng chính sách đã công bố của chủ sở hữu miền cũng như chính sách người nhận.

Thông số kỹ thuật hiện tại của IETF, RFC 9989, giải thích rằng DMARC xác thực số nhận dạng cấp miền và không giải quyết các cuộc tấn công tên hiển thị hoặc phân tích nội dung thư. Nó thay thế RFC 7489 cũ hơn vào tháng 5 năm 2026.

Những gì đã thay đổi trong bản sửa đổi DMARC 2026

RFC 9989 không phải là bằng chứng cho thấy mọi hệ thống thông báo đột ngột thay đổi hành vi vào năm 2026. Nó củng cố định nghĩa giao thức hiện tại, lỗi thời rõ ràng với RFC 7489 và RFC 9091, đồng thời tách các định dạng tổng hợp và báo cáo lỗi thành các thông số kỹ thuật đồng hành. Quy tắc đọc thực tế vẫn ổn định: thẻ DMARC có nghĩa là danh tính SPF hoặc DKIM được căn chỉnh được phép sử dụng miền tác giả hiển thị. Đó không phải là điểm danh tiếng, kiểm tra danh tính người viết tin nhắn hay quét các liên kết và tệp đính kèm.

Sự khác biệt này rất quan trọng khi diễn giải “các yêu cầu DMARC mới” trong thông báo sản phẩm. Nhà cung cấp có thể thay đổi chính sách gửi hoặc yêu cầu gửi hàng loạt một cách độc lập với giao thức cơ sở. Ví dụ: nguyên tắc dành cho người gửi của Gmail áp dụng các yêu cầu xác thực khác nhau bằng cách gửi số lượng. Hãy coi chính sách của nhà cung cấp, xác thực giao thức và an toàn thư là ba lớp riêng biệt.

Thẻ DMARC có nghĩa là ít nhất một đường dẫn xác thực được hỗ trợ được chuyển với sự căn chỉnh bắt buộc. Điều đó không có nghĩa là tác giả đã được xác minh cá nhân, tài khoản không bị xâm phạm hoặc tin nhắn vô hại.

Đọc kết quả xác thực

Tiêu đề được đơn giản hóa có thể trông như thế này:

Authentication-Results: mx.example;
  spf=pass smtp.mailfrom=mailer.example;
  dkim=pass header.d=mailer.example;
  dmarc=pass header.from=mailer.example

Cùng nhau xem lại các giá trị này:

1. Máy chủ nào đã viết trường Authentication-Results?
2. Tên miền nào đạt SPF?
3. Domain nào đã ký với DKIM?
4. Tên miền nào xuất hiện trong địa chỉ Từ hiển thị?
5. DMARC có báo cáo sự phù hợp, thất bại hoặc không có chính sách không?
6. Lộ trình giao hàng có phù hợp với người gửi mà bạn mong đợi không?

Tiêu đề có thể chứa một số trường kết quả vì nhiều hệ thống đã xử lý thông báo. Kết quả của người nhận đáng tin cậy mới nhất thường phù hợp nhất nhưng việc quyết định xem bên trung gian nào đáng tin cậy đòi hỏi phải có kiến ​​thức về nhà cung cấp hộp thư và đường dẫn gửi.

Tại sao thẻ vượt qua không phải là sự đảm bảo an toàn

Kẻ tấn công có thể xác thực miền mà chúng kiểm soát. Tài khoản của người gửi hợp pháp có thể bị xâm phạm. Thư được xác thực chính xác vẫn có thể chứa yêu cầu gây hiểu lầm, tệp đính kèm độc hại hoặc liên kết nguy hiểm.

Nguyên tắc dành cho người gửi Gmail yêu cầu các biện pháp kiểm soát xác thực khác nhau tùy thuộc vào khối lượng gửi và mô tả xác thực như một biện pháp chống lạm dụng và khả năng gửi. Chúng không biến việc xác thực thành một phán quyết chung về an toàn nội dung.

Nếu một tin nhắn yêu cầu thông tin xác thực, tiền, hành động khẩn cấp hoặc các tệp nhạy cảm, hãy xác minh yêu cầu thông qua kênh liên hệ đã biết. Đừng chỉ dựa vào tên Người gửi hoặc kết quả xác thực màu xanh lá cây.

Sử dụng máy phân tích một cách thận trọng

Chỉ dán các trường tiêu đề, không dán nội dung thư hoặc tệp đính kèm. So sánh bản tóm tắt của máy phân tích với bối cảnh mà tin nhắn được gửi đến. Hãy coi bằng chứng bị thiếu, không đúng định dạng hoặc mâu thuẫn là lý do để xác minh bổ sung chứ không phải là bằng chứng tự động của gian lận.

Để ứng phó sự cố, cấu hình miền hoặc các quyết định có tác động lớn, hãy sử dụng chế độ xem thư gốc của nhà cung cấp hộp thư của bạn và tham khảo ý kiến ​​của quản trị viên email hoặc chuyên gia bảo mật có trình độ.