DMARC: từ p=none lên quarantine và reject một cách an toàn

DMARC bổ sung gì cho SPF và DKIM

SPF và DKIM cho biết một thư có được xác thực hay không, nhưng không nói người nhận phải làm gì khi thư trượt. DMARC bổ sung hai thứ: một chính sách (thư không đạt thì bỏ qua, đưa vào thư rác hay từ chối) và báo cáo (ai đang gửi thư nhân danh tên miền của bạn).

Thư "đạt DMARC" khi SPF hoặc DKIM đạt và tên miền được xác thực khớp với tên miền trong From. Điều kiện khớp này là điểm mấu chốt khiến DMARC chặn được kiểu giả địa chỉ From, thứ mà riêng SPF không chặn được.

Bản ghi DMARC

Bản ghi là TXT tại _dmarc.example.vn:

v=DMARC1; p=none; rua=mailto:dmarc@example.vn

Các thẻ hay dùng:

• p: chính sách cho tên miền: none, quarantine, reject.
• sp: chính sách riêng cho tên miền con (nếu không có thì dùng p).
• pct: phần trăm thư không đạt chịu chính sách (mặc định 100). Chuẩn mới RFC 9989 (2026) đã bỏ pct, rf, ri và thêm t (chế độ thử), np (chính sách cho tên miền con không tồn tại), psd. Nhiều bên nhận có thể vẫn hỗ trợ pct, nên bài này vẫn dùng nó và nhắc lại ở bước 4.
• rua: địa chỉ nhận báo cáo tổng hợp hằng ngày.
• adkim, aspf: mức khớp tên miền, r (relaxed, mặc định) hoặc s (strict).

Nếu địa chỉ rua thuộc tên miền khác tên miền đang cấu hình, tên miền nhận phải đăng ký quyền nhận bằng một bản ghi TXT example.vn._report._dmarc.ten-mien-nhan có giá trị v=DMARC1. Nếu không, báo cáo sẽ bị từ chối.

Vì sao nên làm ngay

Từ tháng 2/2024, Google (Gmail) và Yahoo yêu cầu bên gửi hàng loạt (hơn 5000 thư mỗi ngày tới hộp thư của họ) phải có SPF, DKIM và DMARC (tối thiểu p=none); Outlook.com của Microsoft áp dụng yêu cầu tương tự từ tháng 5/2025. Tên miền doanh nghiệp nhỏ thường dưới ngưỡng đó, nhưng thư của bạn vẫn được xét theo các tín hiệu này, nên có DMARC là cách rẻ nhất để thư thật không vào mục rác và thư giả khó giả danh bạn.

Lộ trình năm bước

1. Chuẩn bị SPF và DKIM cho mọi nguồn gửi thư thật (email chính, phần mềm kế toán, CRM, công cụ gửi hàng loạt, hệ thống thông báo của website). Xem hai bài về SPF và DKIM.
2. Bắt đầu bằng p=none kèm rua. Chưa chặn gì, chỉ thu thập báo cáo. Giữ 2 đến 4 tuần.
3. Đọc báo cáo (tệp XML nén gửi mỗi ngày từ Google, Microsoft, Yahoo...). Liệt kê mọi nguồn gửi xuất hiện; nguồn hợp lệ nào trượt thì sửa SPF/DKIM cho nó, nguồn lạ thì đó chính là kẻ giả mạo. Báo cáo XML khó đọc bằng mắt, nên thường dùng một công cụ đọc báo cáo (có công cụ miễn phí, hoặc dùng tập lệnh riêng). Lưu ý báo cáo chứa địa chỉ IP và tên miền, hãy chọn nơi nhận mà bạn tin tưởng.
4. Nâng lên quarantine từng bước: p=quarantine; pct=10, sau một tuần nếu không có thư thật bị ảnh hưởng thì pct=25, 50, rồi bỏ pct (100). Các nhà cung cấp lớn hiện vẫn hiểu pct, nhưng chuẩn mới RFC 9989 đã bỏ nó và thay bằng t=y (chế độ thử), nên đừng coi việc tăng pct là cách duy nhất: bước an toàn hơn là chuyển sang quarantine đầy đủ ngay khi báo cáo đã sạch.
5. Chuyển reject khi báo cáo ổn định vài tuần. Với tên miền chính của doanh nghiệp, đây là đích đến để thư giả mạo bị từ chối ngay khi gửi.

v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@example.vn

Những bẫy làm mất thư thật

• Chuyển tiếp thư và danh sách thư (mailing list): thư được chuyển tiếp thường trượt SPF, và danh sách thư hay sửa nội dung nên trượt DKIM. Vì vậy cần quan sát đủ lâu ở p=none.
• Dịch vụ bên thứ ba gửi thay mặt bạn (gửi hoá đơn, thư quảng bá, hệ thống đặt lịch) mà chưa cấu hình DKIM theo tên miền của bạn.
• Tên miền con: nếu có sp=none, tên miền con vẫn chưa được bảo vệ dù tên miền chính đã reject.
• Chế độ strict (adkim=s, aspf=s) dễ làm trượt thư hợp lệ của dịch vụ dùng tên miền con. Chỉ bật khi hiểu rõ.

Với tên miền không dùng để gửi thư, bạn có thể khoá thẳng: SPF v=spf1 -all, DMARC v=DMARC1; p=reject; adkim=s; aspf=s và bản ghi MX 0 . (null MX, RFC 7505) để báo rõ tên miền không nhận thư. Chỉ làm khi chắc chắn tên miền đó không gửi thư, kể cả thông báo từ website.

Theo nền tảng

DMARC luôn là một bản ghi TXT tại _dmarc, nên thao tác ở đâu cũng giống nhau; khác biệt là chỗ bạn thêm bản ghi.

Cloudflare. DNS, Records, Add record: loại TXT, Name _dmarc, Content là giá trị DMARC. Nếu đã có bản ghi thì sửa, không thêm bản thứ hai.

Google Workspace. Cần SPF và DKIM đã bật (Admin console, Apps, Google Workspace, Gmail, Authenticate email). Thêm bản ghi TXT _dmarc ở nơi quản lý DNS của tên miền. Bạn có thể xem lại bản ghi bằng Google Admin Toolbox (Check MX).

Microsoft 365. DMARC cho tên miền riêng được đặt trong DNS như trên. Trong Microsoft Defender có thể xem lại cấu hình xác thực ở Email authentication settings; hãy bật DKIM cho tên miền trước khi nâng chính sách.

Zoho Mail. Bật SPF và DKIM ở Admin Console, rồi thêm TXT _dmarc ở nơi quản lý DNS.

cPanel. Vào Zone Editor, Add Record, loại TXT, tên _dmarc.example.vn., giá trị DMARC. Nếu đã có sẵn một bản ghi _dmarc, hãy sửa nó thay vì thêm bản thứ hai.

DirectAdmin. Vào DNS Management, thêm TXT với tên _dmarc. Nếu DirectAdmin không quản lý DNS của tên miền, thêm ở nhà cung cấp DNS bên ngoài.

Cách tự kiểm tra

dig +short TXT _dmarc.example.vn

Phải thấy đúng một dòng bắt đầu bằng "v=DMARC1;. Dán dòng đó vào công cụ đọc DMARC để thấy từng thẻ và các cảnh báo như p=none hay thiếu rua, hoặc dùng công cụ tạo SPF và DMARC để soạn bản ghi khởi đầu.

Kiểm tra thực tế: gửi thư từ địa chỉ của tên miền tới hộp Gmail cá nhân, chọn "Hiện thư gốc" (Show original) và tìm DMARC: 'PASS'. Sau 24 đến 48 giờ hộp thư rua bắt đầu nhận báo cáo. Nếu sau một tuần chưa có báo cáo nào, kiểm tra lại bản ghi rua và quyền nhận báo cáo nếu địa chỉ ở tên miền khác.