Cách Đọc Chính Sách DMARC của Một Công Ty trong Mười Giây (Và Những Gì Nó Không Cho Bạn Biết)

Một lần tra cứu DNS cho bạn biết công ty đã yêu cầu các máy chủ thư trên toàn thế giới làm gì với thư giả mạo được gửi dưới tên của họ. Bản ghi là công khai, và lệnh chỉ có một dòng: dig +short TXT _dmarc.example.com. Kết quả trả về là một chuỗi cài đặt ngắn, và bên trong nó là một lệnh — p=none, p=quarantine hoặc p=reject — cho biết tùy chọn của chủ sở hữu miền khi một thư sử dụng miền đó không vượt qua xác thực.

Quy cách hiện tại, RFC 9989, được xuất bản vào tháng 5 năm 2026 như một tài liệu IETF Standards Track, thay thế RFC 7489 cũ hơn. Nó định nghĩa ba giá trị gần như ngắn gọn:

• p=none — "Chủ sở hữu miền không bày tỏ bất kỳ tùy chọn nào."
• p=quarantine — "Chủ sở hữu miền coi thư đó là đáng ngờ. Có thể thư là hợp lệ, mặc dù sự cố không vượt qua xác thực tạo ra một mối quan tâm đáng kể."
• p=reject — "Chủ sở hữu miền coi tất cả những cố không vượt qua xác thực đó là một dấu hiệu rõ ràng rằng việc sử dụng tên miền là không hợp lệ."

Đọc lại những từ đó, vì chúng yếu hơn hầu hết các giải thích về DMARC thừa nhận. Một chính sách là một tùy chọn, được công bố bởi người gửi để những người nhận cân nhắc. Đó không phải là một lệnh mà người nhận phải tuân theo. RFC 9989 nói như vậy trong một câu: "Xử lý cuối cùng của bất kỳ thư nào luôn là vấn đề của chính sách địa phương và được để cho quyết định của Người Nhận Thư." Phần cùng đó cũng nêu cả hai khía cạnh của hệ quả — những người nhận "CÓ THỂ chọn từ chối hoặc cách ly một thư ngay cả khi nó vượt qua kiểm tra xác thực DMARC," và họ "KHÔNG NÊN từ chối thư chỉ vì một chính sách được công bố là 'reject'," chính xác vì vậy thư hợp lệ được gửi theo những cách mà DMARC không thể mô tả, và danh sách gửi thư, không bị hủy trong quá trình này.

Vậy p=none thực sự thú nhận điều gì? Ít hơn so với những gì nó thường bị buộc tội. Theo các điều khoản của quy cách, đó là Chế Độ Giám Sát: chủ sở hữu miền đang thu thập các báo cáo tổng hợp và "không bày tỏ bất kỳ tùy chọn xử lý nào cho các thư không vượt qua xác thực DMARC," trong khi một người nhận triển khai DMARC "vẫn có thể" xác thực việc sử dụng miền. Điều nó không làm là tắt bất cứ thứ gì ở cuối nhận. Bộ lọc thư rác của nhà cung cấp của bạn, ghi điểm danh tiếng, kiểm tra URL và phân tích tệp đính kèm là máy móc riêng biệt chạy bất kể người gửi công bố gì. Một thư giả mạo đến từ một miền p=none không được đưa lên hộp thư của bạn bằng bản ghi; nó chỉ được chuyển giao cho người nhận mà không có tùy chọn được nêu rõ, và người nhận quyết định.

Nửa kia của sự hiểu lầm chạy theo cách khác. DMARC không đọc phần nguy hiểm của một email lừa đảo. Quy cách của chính nó liệt kê những gì được cố ý nằm ngoài phạm vi, và "phân tích nội dung" nằm trong danh sách đó, theo những từ đó. Nó cũng nêu rằng DMARC "không giải quyết việc sử dụng các tên miền trông giống nhau về mặt hình ảnh hoặc lạm dụng tên hiển thị có thể đọc được RFC5322.From" — hai thủ đoạn mang theo hầu hết thư giả mạo thương hiệu. Và về giá trị của một lần vượt qua: "một lần vượt qua DMARC theo tự nó không đảm bảo rằng việc gửi đến hộp thư của người nhận sẽ an toàn hoặc mong muốn." Một thư được xác thực đúng cách từ một miền dùng một lần vượt qua DMARC một cách sạch sẽ. DMARC trả lời ai được phép sử dụng miền trong tiêu đề From:. Không có gì khác.

Đây là nơi các quy tắc người gửi hàng loạt năm 2024 thường bị báo cáo sai, kể cả trong phiên bản đầu tiên của bài viết này. Các hướng dẫn người gửi của Google yêu cầu những người gửi 5000 hoặc nhiều thư hơn mỗi ngày tới các tài khoản Gmail phải "Thiết lập xác thực email DMARC cho miền gửi của bạn," và sau đó nói, trong cùng một hơi thở: "Chính sách thực thi DMARC của bạn có thể được đặt thành none." Sender Hub của Yahoo, phải được đọc riêng biệt thay vì được coi là sao chép Google, nêu yêu cầu là "Công bố chính sách DMARC hợp lệ với ít nhất p=none - DMARC phải vượt qua," và không công bố ngưỡng khối lượng số học nào cả. Cả hai bộ yêu cầu đã có hiệu lực từ tháng 2 năm 2024. Không ai buộc ai phải rời khỏi p=none. Những gì cả hai thực sự buộc là xác thực được căn chỉnh: Google yêu cầu "miền trong tiêu đề From: của người gửi phải được căn chỉnh với miền SPF hoặc miền DKIM," và Yahoo nói căn chỉnh được nới lỏng là chấp nhận được. Căn chỉnh, không phải mức độ nghiêm trọng, là cổng vào.

Điều đó để lại lý do thực sự tại sao các miền ngồi ở chế độ giám sát, và nó là hoạt động hơn là hèn nhát. Chuyển đến quarantine hoặc reject có nghĩa là trước tiên phải tìm mọi dịch vụ gửi thư dưới tên của bạn — bảng lương, vé, tiếp thị, bàn hỗ trợ không ai ghi chép — và xác thực từng cái để nó căn chỉnh. Bản thân tiêu chuẩn thừa nhận những nguy hiểm làm cho điều này chậm: những người gửi bên thứ ba không được giới thiệu hoặc loại trừ bởi DMARC, chuyển tiếp và danh sách gửi thư có thể phá vỡ căn chỉnh mà không có lỗi của người gửi, và quy cách hướng những người nhận đến RFC 7960 chính xác cho các chế độ lỗi đó. Một tổ chức công bố p=none và đọc các báo cáo của nó đang thực hiện công việc theo thứ tự mà quy cách mô tả. Cái công bố p=none và bỏ qua các báo cáo không. Từ bên ngoài, bản ghi một mình không thể cho bạn biết cái nào trong hai cái bạn đang nhìn.

Bạn không cần một terminal để tìm kiếm. Các công cụ tra cứu miễn phí — trình kiểm tra miền của dmarcian, kiểm tra DMARC của MXToolbox — tìm nạp bản ghi và in chính sách cho bạn. Hãy làm điều này cho ngân hàng của bạn, nhà cung cấp bảng lương của bạn, hãng hàng không bạn bay. Chỉ đọc câu trả lời cho những gì nó là: một tuyên bố ý định của chủ sở hữu miền, một đầu vào trong số nhiều đầu vào thành một quyết định mà nhà cung cấp thư của bạn thực hiện theo ý của mình, về một loại giả mạo cụ thể. Đó là một điều thực sự hữu ích có thể đọc trong mười giây. Nó không phải là một phán quyết về liệu tin nhắn tiếp theo tuyên bố từ thương hiệu đó có an toàn hay không.

Sửa lỗi, 20 tháng 10 năm 2026. Một phiên bản trước của bài viết này mô tả p=none như gửi các thư giả mạo đến hộp thư và p=reject như cài đặt duy nhất chặn một thư giả mạo, nói rằng các quy tắc người gửi hàng loạt năm 2024 của Google và Yahoo buộc những người gửi rời khỏi p=none, và trích dẫn một số liệu khoảng một trong ba miền ở thực thi. Các mô tả chính sách đã được sửa lỗi so với RFC 9989; cả Google và Yahoo thực tế đều chấp nhận p=none, được trích dẫn ở trên từ tài liệu của chính họ; và số liệu thực thi đã được loại bỏ vì báo cáo cơ bản không công bố mẫu hoặc mẫu số của nó. Bài viết bây giờ cũng nêu những gì DMARC không kiểm tra.

@@END@@