RFC 8601 — Trường Tiêu đề Authentication-Results

Proposed Standard Email Authentication Obsoletes RFC 7601 Published March 2026

ELI5: Khi một lá thư đến được gửi đến bộ phận thư của một công ty, nhân viên bảo vệ kiểm tra ID của tài xế giao hàng, xác minh địa chỉ trả lại và kiểm tra dấu chống giả mạo. Sau đó, họ dán một tờ giấy nhớ vào lá thư tóm tắt những phát hiện của họ: "Driver ID verified, return address confirmed, seal intact." Tiêu đề Authentication-Results chính là tờ giấy nhớ đó — đó là một cách tiêu chuẩn để máy chủ thư nhận ghi lại kết quả của tất cả các kiểm tra xác thực để các bộ lọc hạ lưu, công cụ lọc spam và ứng dụng thư có thể sử dụng thông tin mà không cần chạy lại các kiểm tra.

Tại sao RFC này tồn tại

Xác thực email liên quan đến nhiều cơ chế độc lập: SPF, DKIM, DMARC, ARC, và những cơ chế khác. Mỗi cơ chế tạo ra kết quả riêng của nó. Nếu không có cách tiêu chuẩn để ghi lại các kết quả này, mỗi thành phần trong quy trình phân phối thư — bộ lọc nội dung, trình phân loại thư rác, ứng dụng khách hàng giao diện người dùng — sẽ cần phải độc lập đánh giá lại mỗi cơ chế xác thực.

RFC 8601 định nghĩa trường tiêu đề Authentication-Results, một cách có cấu trúc để MTA biên giới (máy chủ đầu tiên trong cơ sở hạ tầng của bạn nhận tin nhắn từ internet) ghi lại kết quả của tất cả các kiểm tra xác thực trong một tiêu đề duy nhất. Kết quả này sau đó có thể được sử dụng bởi tất cả các thành phần hạ lưu.

RFC 8601 loại bỏ RFC 7601, chính nó cũng đã loại bỏ RFC 5451. Các bản cập nhật đã tinh chỉnh cú pháp, đăng ký các từ khóa phương thức bổ sung, và làm rõ xử lý ranh giới tin cậy.

Cách thức hoạt động

Cấu trúc tiêu đề

Tiêu đề Authentication-Results có một ngữ pháp được xác định:

Authentication-Results: <authserv-id>; <method>=<result> [reason=<text>] [<property>.<type>=<value>] [; ...]

Ví dụ thực tế

Authentication-Results: mx.receiver.com;
dkim=pass header.d=example.com header.s=mtg20240101 header.b=LjIEJLN;
spf=pass (sender IP is 198.51.100.25) smtp.mailfrom=example.com;
dmarc=pass (p=reject dis=none) header.from=example.com;
arc=pass (i=1 spf=pass dkim=pass dmarc=pass)

Cách nó được tạo ra

MTA biên giới nhận một tin nhắn từ internet qua SMTP.
Nó chạy các kiểm tra SPF đối với người gửi phong bì và IP kết nối.
Nó xác thực bất kỳ chữ ký DKIM nào bằng cách truy vấn DNS để lấy khóa công khai.
Nó đánh giá chính sách và căn chỉnh DMARC.
Nó xác thực bất kỳ chuỗi ARC nào có trên tin nhắn.
Nó thêm vào trước một tiêu đề Authentication-Results tóm tắt tất cả các kết quả, được xác định bằng tên máy chủ của nó (authserv-id).
Các bộ lọc nội dung, công cụ thư rác và logic phân phối hạ lưu đọc tiêu đề này thay vì chạy lại các kiểm tra.

Chi tiết kỹ thuật chính

authserv-id

Token đầu tiên sau Authentication-Results: là authserv-id, thường là tên máy chủ của máy chủ thực hiện các kiểm tra. Điều này rất quan trọng để tin cậy: một hệ thống nhận cần chỉ tin cậy các tiêu đề Authentication-Results có authserv-id khớp với một máy chủ trong miền hành chính của nó. Các tiêu đề từ các máy chủ bên ngoài cần được loại bỏ hoặc bỏ qua.

Từ khóa phương thức

IANA duy trì một sổ đăng ký các từ khóa phương thức xác thực. Những cái được sử dụng phổ biến nhất là:

Phương thức	Nó kiểm tra cái gì	Được định nghĩa trong
`spf`	Đánh giá SPF của người gửi phong bì	RFC 7208
`dkim`	Xác minh chữ ký DKIM	RFC 6376
`dmarc`	Đánh giá căn chỉnh và chính sách DMARC	RFC 7489
`arc`	Xác thực chuỗi ARC	RFC 8617
`auth`	Thông tin xác thực SMTP AUTH (RFC 4954)	RFC 4954
`iprev`	Xác thực DNS ngược của IP kết nối	RFC 8601

Giá trị kết quả

Mỗi phương thức tạo ra một trong những giá trị kết quả này:

Kết quả	Ý nghĩa
`pass`	Xác thực thành công.
`fail`	Xác thực thất bại rõ ràng.
`softfail`	Xác thực thất bại, nhưng chính sách người gửi gợi ý coi nó là đáng ngờ thay vì từ chối (dành riêng cho SPF).
`neutral`	Người gửi không đưa ra khẳng định nào (SPF `?all`).
`none`	Không tìm thấy bản ghi xác thực nào (không có bản ghi SPF, không có chữ ký DKIM, không có chính sách DMARC).
`temperror`	Lỗi tạm thời (DNS timeout, v.v.). Thử lại sau.
`permerror`	Lỗi vĩnh viễn (bản ghi không đúng định dạng, quá nhiều truy vấn DNS, v.v.).
`policy`	Tin nhắn vượt qua xác thực nhưng không vượt qua kiểm tra chính sách cục bộ.

Loại thuộc tính

Mỗi kết quả có thể bao gồm các cặp thuộc tính/giá trị cung cấp chi tiết:

Thuộc tính	Mô tả
`header.d`	Miền ký DKIM (thẻ `d=`)
`header.s`	Bộ chọn DKIM (thẻ `s=`)
`header.b`	Hash chữ ký DKIM được cắt ngắn (8 ký tự đầu tiên)
`header.from`	Miền trong tiêu đề `From:` của tin nhắn
`smtp.mailfrom`	Miền người gửi phong bì (MAIL FROM)
`smtp.helo`	Tên máy chủ EHLO/HELO được sử dụng bởi người gửi

Nhiều kết quả

Một tiêu đề Authentication-Results duy nhất có thể chứa các kết quả từ nhiều phương thức, được phân tách bằng dấu chấm phẩy. Ngoài ra, có thể có nhiều tiêu đề Authentication-Results (ví dụ: một cho mỗi phương thức). Cả hai cách tiếp cận đều hợp lệ.

Ranh giới tin cậy

Cân nhắc bảo mật quan trọng nhất: không bao giờ tin cậy các tiêu đề Authentication-Results từ các nguồn bên ngoài. Một kẻ tấn công có thể bao gồm một tiêu đề Authentication-Results giả mạo tuyên bố dkim=pass và dmarc=pass. MTA biên giới phải hoặc loại bỏ tất cả các tiêu đề Authentication-Results hiện có khớp với authserv-id của nó, hoặc chỉ tin cậy các tiêu đề nó có thể xác minh được thêm vào trong miền hành chính của nó.

Những lỗi phổ biến

Tin cậy các tiêu đề A-R bên ngoài: Lỗi nguy hiểm nhất. Nếu hệ thống thư của bạn không loại bỏ hoặc bỏ qua các tiêu đề Authentication-Results từ bên ngoài ranh giới tin cậy của bạn, một kẻ tấn công có thể tiêm các kết quả giả mạo. Luôn loại bỏ các tiêu đề A-R đến sử dụng authserv-id của bạn.
Không ghi lại kết quả tại biên: Nếu các kiểm tra xác thực diễn ra tại MTA biên giới nhưng kết quả không được ghi lại trong tiêu đề, các hệ thống lọc nội bộ không có dữ liệu xác thực để làm việc và phải chạy lại tất cả các kiểm tra (điều này có thể tạo ra các kết quả khác nhau do vị trí mạng đã thay đổi).
authserv-id không rõ ràng: Sử dụng tên máy chủ chung chung (như "localhost") làm authserv-id làm cho không thể phân biệt giữa các tiêu đề A-R từ hệ thống của bạn và những tiêu đề từ các hệ thống khác. Sử dụng tên máy chủ MX đầy đủ của bạn.
Đọc sai kết quả DKIM: Kết quả dkim=pass một mình không có nghĩa là tin nhắn an toàn. Kiểm tra giá trị header.d để xem miền nào đã ký nó. Một pass cho d=attacker.com là vô nghĩa đối với các tin nhắn tuyên bố từ example.com. Đây là lý do tại sao căn chỉnh DMARC quan trọng.
Bỏ qua các kết quả none: Kết quả none có nghĩa là không tìm thấy bản ghi nào. Đối với SPF hoặc DMARC, điều này có nghĩa là miền chưa xuất bản chính sách xác thực. Sự vắng mặt này nên được xử lý khác với một fail rõ ràng.

Tác động khả năng giao hàng

Kho tàng chẩn đoán: Khi khắc phục sự cố khả năng giao hàng, tiêu đề Authentication-Results là nơi đầu tiên để tìm kiếm. Nó cho bạn biết chính xác những gì máy chủ nhận thấy: kiểm tra nào vượt qua, kiểm tra nào không và tại sao.
Điều khiển các quyết định lọc: Các nhà cung cấp email chính (Gmail, Microsoft, Yahoo) sử dụng các kết quả xác thực làm đầu vào chính cho lọc thư rác của họ. Một tin nhắn có spf=pass, dkim=pass và dmarc=pass có cơ hội tốt hơn nhiều để đến hộp thư đến.
Tích hợp ARC: Tiêu đề ARC-Authentication-Results trong ARC tuân theo định dạng tương tự như tiêu đề Authentication-Results tiêu chuẩn, đảm bảo báo cáo nhất quán trên các bước chuyển tiếp.
Tính minh bạch: Bằng cách expose các kết quả xác thực trong các tiêu đề tin nhắn, RFC 8601 làm cho xác thực email có thể quan sát được và có thể gỡ lỗi. Người gửi có thể yêu cầu người nhận chuyển tiếp các tiêu đề thô để chẩn đoán các lỗi xác thực.
Có thể đọc bằng máy: Định dạng có cấu trúc giúp các hệ thống tự động dễ dàng phân tích cú pháp và hành động dựa trên các kết quả xác thực, cho phép giám sát khả năng giao hàng theo chương trình.