← RFC Reference

DMARC — Xác thực Tin nhắn dựa trên Tên miền, Báo cáo và Tuân thủ

Tại Sao RFC Này Tồn Tại

SPF và DKIM mạnh mẽ, nhưng mỗi cái đều có một lỗ hổng quan trọng. SPF xác thực miền người gửi phong bì, điều mà người dùng không bao giờ thấy. DKIM xác thực bất kỳ miền nào mà người ký chọn, có thể là miền của ESP chứ không phải người gửi hiển thị. Cả hai riêng lẻ đều không ngăn chặn kẻ tấn công giả mạo tiêu đề From: mà người dùng thực sự đọc.

DMARC đóng lỗ hổng này bằng cách giới thiệu hai khái niệm:

1. Căn chỉnh định danh: Ít nhất một trong SPF hoặc DKIM phải vừa vượt qua và có miền được xác thực phù hợp với miền tiêu đề From:.
2. Chính sách chủ sở hữu miền: Chủ sở hữu miền công bố bản ghi DNS khai báo những gì người nhận nên làm khi căn chỉnh thất bại: giám sát (p=none), cách ly (p=quarantine), hoặc từ chối (p=reject).

DMARC cũng định nghĩa cơ chế báo cáo tổng hợp, cho phép chủ sở hữu miền nhận báo cáo XML hàng ngày cho thấy miền của họ đang được sử dụng (và bị lạm dụng) như thế nào trên toàn internet.

Cách Nó Hoạt Động

Luồng Đánh Giá DMARC

1. Một tin nhắn đến với From: user@example.com.
2. Người nhận kiểm tra SPF với miền người gửi phong bì. Nếu SPF vượt qua và miền phong bì khớp với example.com (hoặc miền con, tùy thuộc vào chế độ căn chỉnh), SPF được "căn chỉnh."
3. Người nhận kiểm tra DKIM. Nếu chữ ký hợp lệ có d=example.com (hoặc miền con), DKIM được "căn chỉnh."
4. Nếu ít nhất một trong SPF hoặc DKIM vừa vượt qua vừa được căn chỉnh, DMARC vượt qua.
5. Nếu DMARC thất bại, người nhận truy vấn _dmarc.example.com để lấy chính sách và áp dụng nó.

Bản Ghi DNS DMARC

Căn Chỉnh Trong Thực Tế

Chi Tiết Kỹ Thuật Chính

Thẻ Chính Sách

Chế Độ Căn Chỉnh

Căn chỉnh nослабленное (mặc định, adkim=r / aspf=r): Miền được xác thực và miền From: chia sẻ cùng miền tổ chức. Ví dụ, mail.example.com căn chỉnh với example.com.

Căn chỉnh nghiêm ngặt (adkim=s / aspf=s): Miền được xác thực phải khớp chính xác với miền From:. mail.example.com không căn chỉnh với example.com.

Báo Cáo Tổng Hợp (rua)

Các người nhận hỗ trợ DMARC gửi báo cáo tổng hợp hàng ngày ở định dạng XML tới địa chỉ rua. Những báo cáo này chứa:

• Các địa chỉ IP gửi đã sử dụng miền của bạn
• Kết quả vượt qua/thất bại của SPF và DKIM cho mỗi nguồn
• Chính sách DMARC được áp dụng và tính năng xử lý (không có, cách ly, từ chối)
• Số lượng tin nhắn trên mỗi IP nguồn

Những báo cáo này là vô giá để phát hiện những người gửi trái phép, xác định những nguồn hợp pháp được định cấu hình không chính xác, và xây dựng sự tự tin trước khi siết chặt chính sách của bạn từ none thành reject.

Xác Minh Điểm Đến Bên Ngoài

Nếu địa chỉ rua hoặc ruf của bạn nằm ở miền khác (ví dụ: rua=mailto:reports@analytics.com), miền nhận phải công bố bản ghi DNS để cấp phép nó:

Không có bản ghi này, những người gửi báo cáo sẽ không gửi báo cáo tới địa chỉ bên ngoài, như một biện pháp bảo vệ chống lại việc sử dụng báo cáo DMARC như một vectơ từ chối dịch vụ.

Những Sai Lầm Phổ Biến

• Nhảy thẳng tới p=reject: Triển khai chính sách từ chối mà không giám sát trước với p=none có thể âm thầm chặn thư hợp pháp từ những nguồn bị quên (nền tảng tiếp thị, hệ thống CRM, ứng dụng SaaS gửi thay bạn). Luôn bắt đầu với p=none, phân tích báo cáo, khắc phục vấn đề căn chỉnh, rồi tăng cấp.
• Quên chính sách miền con: Không có sp=, miền con kế thừa chính sách của miền. Nếu bạn đặt p=reject nhưng có miền con gửi thư mà không xác thực thích hợp, những tin nhắn đó sẽ bị từ chối. Sử dụng sp= để kiểm soát chính sách miền con độc lập.
• Không thiết lập rua: DMARC mà không có báo cáo tổng hợp là đang bay mù. Báo cáo cho bạn biết ai đang gửi thư với tư cách miền của bạn và liệu xác thực có hoạt động không. Luôn định cấu hình rua.
• Hiểu sai căn chỉnh: Một sai lầm phổ biến là nghĩ rằng SPF và DKIM vượt qua là đủ. Chúng cũng phải căn chỉnh với miền tiêu đề From:. Nếu ESP của bạn sử dụng bounce@esp.com làm người gửi phong bì và ký DKIM là d=esp.com, cả hai đều không căn chỉnh với tiêu đề From:, và DMARC thất bại.
• Sử dụng pct=0 là "chỉ giám sát": Mặc dù pct=0 về mặt kỹ thuật có nghĩa là "áp dụng chính sách cho 0% thất bại," một số người nhận diễn giải nó khác nhau. Sử dụng p=none để giám sát, không phải pct=0 với chính sách nghiêm ngặt hơn.
• Phá vỡ danh sách gửi thư: Danh sách gửi thư truyền thống viết lại người gửi phong bì nhưng bảo toàn tiêu đề From:, phá vỡ cả căn chỉnh SPF và đôi khi DKIM (nếu danh sách sửa đổi tin nhắn). Đây là vấn đề được biết đến; ARC được tạo để giải quyết nó.

Tác Động Khả Năng Gửi

• Bắt buộc cho người gửi hàng loạt: Kể từ tháng 2 năm 2024, Gmail yêu cầu các miền gửi 5.000+ tin nhắn mỗi ngày phải có chính sách DMARC (tối thiểu p=none). Yahoo có yêu cầu tương tự. Điều này làm cho DMARC trở thành bắt buộc cho bất kỳ người gửi nghiêm túc nào.
• Bảo vệ thương hiệu: Chính sách p=reject ngăn chặn kẻ tấn công giả mạo miền của bạn trong các chiến dịch lừa đảo. Điều này bảo vệ khách hàng của bạn và danh tiếng miền của bạn.
• Cải thiện vị trí hộp thư: Các miền có chính sách DMARC mạnh mẽ (cách ly hoặc từ chối) thể hiện sự trưởng thành xác thực. Nhiều người nhận tính đến điều này trong điểm số danh tiếng.
• Khả năng đủ điều kiện BIMI: Brand Indicators for Message Identification (BIMI) yêu cầu chính sách DMARC của p=quarantine hoặc p=reject. BIMI hiển thị logo thương hiệu của bạn bên cạnh tin nhắn trong các ứng dụng thư hỗ trợ.
• Khả năng hiển thị vào hệ thống thư điện tử của bạn: Báo cáo tổng hợp tiết lộ mọi IP gửi thư với tư cách miền của bạn. Chính khả năng hiển thị này một mình làm cho việc triển khai DMARC được đáng giá, ngay cả ở p=none.

Related RFCs