Cơ chế hoạt động của Trình kiểm tra bản ghi DMARC
Công cụ phân tích cú pháp bản ghi DMARC TXT do người dùng cung cấp để đánh giá các chính sách, thiết lập căn chỉnh, địa chỉ nhận báo cáo và các giá trị phần trăm kế thừa. Trình kiểm tra giúp xác định các thẻ không hợp lệ, đồng thời đưa ra các ghi chú chi tiết về cú pháp và cấu trúc chính sách. Qua đó, quản trị viên hệ thống thư điện tử có thể hiểu rõ cách bản ghi DMARC được cấu trúc và cách các máy chủ nhận thư diễn giải bản ghi đó.
Quá trình xử lý dữ liệu diễn ra trực tiếp và chỉ được thực hiện trong trình duyệt của người dùng. Hệ thống không tải lên hoặc lưu trữ bản ghi này, không ghi dữ liệu vào bộ nhớ lưu trữ của trình duyệt, và không gửi bất kỳ yêu cầu mạng nào ra ngoài liên quan đến nội dung bản ghi.
Cấu trúc và các thành phần của bản ghi DMARC
Một bản ghi DMARC hoàn chỉnh được cấu thành từ nhiều thẻ (tag) khác nhau, mỗi thẻ đảm nhận một vai trò riêng biệt trong việc định hình quy tắc xử lý thư điện tử giả mạo.
Vai trò quyết định của thẻ v=DMARC1
Bản ghi DMARC bắt buộc phải bắt đầu bằng giá trị phân biệt chữ hoa chữ thường v=DMARC1. Đây là điều kiện tiên quyết để các hệ thống nhận thư nhận diện chuỗi TXT là một bản ghi DMARC hợp lệ. Thẻ v=DMARC1 phải luôn là mục đầu tiên trong bản ghi. Nếu không đáp ứng điều kiện này, bản ghi sẽ bị coi là không hợp lệ.
Các chính sách miền (p, sp, np)
Chính sách DMARC xác định hành động mà máy chủ nhận thư nên thực hiện khi một email không vượt qua các bước kiểm tra SPF hoặc DKIM.
- Chính sách miền chính (p): Xác định quy tắc xử lý cho tên miền chính. Nếu không có thẻ
pxuất hiện trong bản ghi, chính sách miền sẽ tự động áp dụng giá trị mặc định lànone. Chính sáchp=nonechỉ có tác dụng giám sát các lỗi bảo mật và gửi báo cáo, chứ không yêu cầu máy chủ nhận thư cách ly (quarantine) hoặc từ chối (reject) thư hỏng. - Chính sách miền phụ (sp): Áp dụng riêng cho các miền phụ trực thuộc miền chính.
- Chính sách miền phụ không tồn tại (np): Áp dụng cho các miền phụ không có thực trên hệ thống DNS.
Khi thiếu các thẻ cụ thể, chính sách dành cho miền phụ sẽ tự động áp dụng cơ chế dự phòng (fallback) theo thứ tự từ np chuyển sang sp, và cuối cùng là lấy theo chính sách p của miền chính.
Căn chỉnh định danh (Identifier Alignment)
Cơ chế căn chỉnh định danh kiểm tra tính nhất quán giữa miền trong địa chỉ người gửi (Header From) với các miền được xác thực bởi SPF (thẻ aspf) và DKIM (thẻ adkim). Sự căn chỉnh này đảm bảo rằng thư được gửi đi thực sự xuất phát từ nguồn được ủy quyền.
Cấu hình báo cáo DMARC (rua và ruf)
Hệ thống DMARC cung cấp cơ chế phản hồi thông tin thông qua hai loại báo cáo chính, giúp quản trị viên theo dõi lưu lượng thư gửi đi.
- Báo cáo tổng hợp (rua): Địa chỉ nhận báo cáo tổng hợp định kỳ. Nếu không có địa chỉ
ruahợp lệ nào được khai báo, hệ thống sẽ không yêu cầu gửi báo cáo tổng hợp. - Báo cáo sự cố (ruf): Địa chỉ nhận báo cáo chi tiết về các trường hợp thư không vượt qua kiểm tra bảo mật.
Các quy tắc xử lý báo cáo đặc biệt bao gồm:
- Thẻ fo: Thẻ cấu hình tùy chọn báo cáo sự cố (
fo) sẽ bị các máy chủ nhận thư bỏ qua nếu không có địa chỉ nhận báo cáo sự cốrufhợp lệ nào được thiết lập. - Hậu tố!size: Hậu tố giới hạn kích thước
!sizeđính kèm trên URI báo cáo hiện đã lỗi thời và sẽ bị các hệ thống nhận thư hiện đại bỏ qua.
Các thẻ kế thừa và chế độ thử nghiệm
Trong quá trình phát triển của tiêu chuẩn DMARC, một số thẻ đã thay đổi vai trò hoặc trở thành thẻ cũ (historic).
- Giá trị phần trăm (pct): Thẻ
pctdùng để giới hạn tỷ lệ phần trăm thư áp dụng chính sách DMARC. Hiện nay, giá trịpctđược coi là thông tin kế thừa và chỉ có tác dụng giới hạn phạm vi áp dụng chính sách đối với các máy chủ nhận thư vẫn đang vận hành theo đặc tả DMARC cũ. - Chế độ thử nghiệm (t=y): Khi kích hoạt chế độ thử nghiệm bằng thẻ
t=y, mức độ nghiêm ngặt của chính sách sẽ tạm thời được hạ xuống trong quá trình kiểm tra. Cụ thể, chính sáchrejectsẽ hạ xuống thànhquarantine, và chính sáchquarantinesẽ hạ xuống thànhnone.
Các lỗi cú pháp và cảnh báo thường gặp
Khi phân tích bản ghi DMARC, công cụ sẽ đối chiếu dữ liệu với các quy tắc tiêu chuẩn để phát hiện lỗi cấu trúc. Dưới đây là danh sách các thông báo lỗi và cảnh báo chi tiết từ giao diện hệ thống:
| Mã lỗi / Cảnh báo trên giao diện | Ý nghĩa và nguyên nhân kỹ thuật |
|---|---|
Hãy dán bản ghi DMARC trước. |
Người dùng chưa nhập dữ liệu vào ô phân tích. |
Bản ghi này lớn bất thường. Hãy giữ dưới 20.000 ký tự. |
Chuỗi ký tự vượt quá giới hạn xử lý 20.000 ký tự của công cụ. |
Bản ghi phải bắt đầu bằng v=DMARC1. |
Bản ghi thiếu khai báo phiên bản hoặc viết sai cú pháp phân biệt chữ hoa chữ thường. |
Mục ‹position›: v=DMARC1 phải là mục đầu tiên. |
Thẻ phiên bản nằm sai vị trí trong chuỗi bản ghi. |
×2: ‹tag› (‹position›) |
Một thẻ cấu hình xuất hiện nhiều hơn một lần trong bản ghi. |
name=value ✕ (‹position›) |
Thẻ tại vị trí được chỉ định bị lỗi định dạng, không tuân thủ cấu trúc cặp tên=giá trị ngăn cách bằng dấu chấm phẩy. |
‹tag›=∅ (‹position›) |
Thẻ được khai báo nhưng bỏ trống giá trị. |
‹tag›=‹detail› ✕ (‹position›) |
Giá trị gán cho thẻ không hợp lệ hoặc không nằm trong danh sách khóa được hỗ trợ. |
URI ✕: ‹tag› (‹position›) |
Địa chỉ email nhận báo cáo tổng hợp hoặc báo cáo sự cố không đúng định dạng URI. |
Không xác định: ‹tag› (‹position›) |
Thẻ không nằm trong danh sách đăng ký tiêu chuẩn và sẽ bị các máy chủ nhận thư bỏ qua. |
RFC 7489 → RFC 9989: ‹tag› (‹position›) |
Thẻ được khai báo là thẻ cũ (historic) theo tiêu chuẩn DMARC hiện hành. |
p → none |
Bản ghi thiếu thẻ p, hệ thống tự động áp dụng chính sách mặc định là none. |
p=none |
Cảnh báo chính sách none chỉ có tác dụng giám sát, không yêu cầu cách ly hay từ chối thư lỗi. |
t=y: reject → quarantine; quarantine → none |
Hệ thống đang chạy thử nghiệm, các chính sách thực tế bị hạ một cấp. |
rua=∅ |
Không có địa chỉ nhận báo cáo tổng hợp hợp lệ, máy chủ sẽ không gửi báo cáo. |
fo → ∅ (ruf=∅) |
Thẻ fo bị vô hiệu hóa do thiếu địa chỉ nhận báo cáo sự cố ruf. |
pct=‹detail›% (RFC 7489) |
Cảnh báo sử dụng giá trị phần trăm cũ, chỉ có hiệu lực với các hệ thống nhận thư đời cũ. |
Các đoạn DNS TXT trong dấu ngoặc kép đã được ghép trước khi phân tích. |
Hệ thống tự động phát hiện và nối các chuỗi DNS TXT được bao quanh bởi dấu ngoặc kép trước khi chạy phân tích. |
!size → ∅ (RFC 9989) |
Hậu tố giới hạn kích thước báo cáo đã lỗi thời và bị bỏ qua theo tiêu chuẩn RFC 9989. |
Câu hỏi thường gặp (FAQ)
Ghi chú về cú pháp và chính sách: p / sp / np?
Các thẻ này đại diện cho chính sách xử lý thư lỗi. Thẻ p áp dụng cho miền chính, sp cho miền phụ, và np cho miền phụ không tồn tại. Nếu thiếu thẻ cụ thể, hệ thống sẽ áp dụng cơ chế dự phòng tự động theo thứ tự ưu tiên từ np chuyển tiếp sang sp, rồi cuối cùng lấy theo p. Khi chạy thử nghiệm với t=y, chính sách reject sẽ hạ xuống thành quarantine, và quarantine sẽ hạ xuống thành none.
RFC 9989: pct / rf / ri?
Không. Theo tiêu chuẩn RFC 9989 hiện hành, các thẻ như pct, rf, và ri được phân loại là thẻ cũ (historic). Ngược lại, các thẻ như np, psd, và t được phân loại là thẻ hoạt động (active).
Kết quả không có lỗi có chứng minh cấu hình DMARC hoạt động không? Không. Trang này chỉ kiểm tra văn bản bạn dán. Trang không truy vấn DNS, không mở rộng bản ghi của nhà cung cấp, không kiểm tra IP người gửi hoặc xác nhận phản hồi của máy chủ thư nhận. Do đó, kết quả phân tích cú pháp sạch không đồng nghĩa với việc toàn bộ hệ thống gửi nhận thư của bạn đã được cấu hình chính xác trên thực tế.