Trả lời nhanh
Làm sao thiết lập DMARC cho tên miền của tôi?
Công bố một bản ghi TXT tại _dmarc.yourdomain với nội dung v=DMARC1; p=none; rua=mailto:you@yourdomain, đọc các báo cáo tổng hợp trong khoảng một tháng, rồi nâng chính sách lên quarantine và cuối cùng là reject. DMARC được định nghĩa bởi RFC 9989 từ tháng 5 năm 2026. Postelva lưu bản ghi trong trình soạn DNS miễn phí của họ.
Ba chính sách DMARC và tác dụng của từng cái
| Chính sách | Bản ghi | Tác động lên thư không đạt DMARC | Khi nào dùng |
|---|---|---|---|
| Giám sát | v=DMARC1; p=none; rua=mailto:[email protected] | Vẫn được giao như thường; báo cáo được gửi cho bạn | Vài tuần đầu, để thấy mọi người gửi |
| Cách ly (quarantine) | v=DMARC1; p=quarantine; rua=mailto:[email protected] | Bị coi là đáng ngờ, thường bị đưa vào thư rác | Sau khi SPF và DKIM đạt trên mọi thư hợp lệ của bạn |
| Từ chối (reject) | v=DMARC1; p=reject; rua=mailto:[email protected] | Bị máy chủ nhận từ chối | Khi báo cáo không còn lỗi hợp lệ nào |
Thiết lập DMARC trong sáu bước
Xác nhận SPF và DKIM trước
DMARC cần ít nhất một trong hai đạt và khớp với tên miền From của bạn. Hãy công bố cả hai trước khi DMARC, theo các hướng dẫn về SPF và DKIM.
Chọn một hộp thư cho báo cáo
Tạo một địa chỉ như dmarc@yourdomain. RFC 9989 nói chủ sở hữu phải thiết lập một hộp thư để nhận và phân tích báo cáo tổng hợp.
Công bố bản ghi giám sát
Thêm một bản ghi TXT với host _dmarc và giá trị v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.
Đọc báo cáo trong khoảng một tháng
Báo cáo đến khoảng mỗi ngày một lần từ các bên nhận gửi chúng. Tìm thư hợp lệ không đạt căn chỉnh SPF và DKIM, rồi sửa những người gửi đó.
Chuyển sang cách ly (quarantine)
Đổi p=none thành p=quarantine. Giữ trong khoảng thời gian tương tự và so sánh cách các thư được xử lý trong báo cáo.
Chuyển sang reject, hoặc dừng ở quarantine
Đổi sang p=reject khi báo cáo sạch. Nếu bạn đăng thư lên danh sách gửi thư từ tên miền này, hãy giữ ở quarantine.
; stage 1: monitor
_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:[email protected]"
; stage 2: quarantine
_dmarc.example.com. IN TXT "v=DMARC1; p=quarantine; rua=mailto:[email protected]"
; stage 3: reject
_dmarc.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:[email protected]"Một bản ghi DMARC chứa gì?
Bản ghi DMARC là một bản ghi TXT tại _dmarc.yourdomain, bắt đầu bằng v=DMARC1 và liệt kê các thẻ cách nhau bằng dấu chấm phẩy. Thẻ phiên bản đứng đầu và phân biệt chữ hoa chữ thường. RFC 9989 định nghĩa các thẻ này: p (chính sách cho tên miền), sp (chính sách cho các tên miền con đã có), np (chính sách cho tên miền con không tồn tại), adkim và aspf (căn chỉnh, r cho nới lỏng hoặc s cho nghiêm ngặt, mặc định là nới lỏng), rua (địa chỉ báo cáo tổng hợp), ruf (địa chỉ báo cáo lỗi), fo (tùy chọn lỗi), t (chế độ thử, y hoặc n) và psd.
Nếu thiếu p, người nhận coi chính sách là none. Nếu thiếu sp, chính sách p bao phủ các tên miền con. Nếu thiếu rua, không có báo cáo tổng hợp nào được tạo. Vì vậy một bản ghi hữu ích tối thiểu có ba phần: phiên bản, một chính sách và một địa chỉ báo cáo.
Thẻ pct, mà nhiều hướng dẫn cũ vẫn hiển thị, đã bị RFC 9989 loại bỏ vì hiếm khi được áp dụng chính xác ngoài 0 và 100. Thẻ t thay thế nó: t=y hoạt động như pct=0 và t=n như pct=100, và n là mặc định. Hãy bỏ pct khỏi các bản ghi cũ. Bối cảnh rộng hơn nằm trong SPF vs DKIM vs DMARC.
Căn chỉnh trong DMARC nghĩa là gì?
Căn chỉnh nghĩa là tên miền được xác thực bởi SPF hoặc DKIM khớp với tên miền trong địa chỉ From hiển thị. Ở chế độ nới lỏng, mặc định, hai bên chỉ cần cùng tên miền tổ chức, nên mail.example.com khớp với example.com. Ở chế độ nghiêm ngặt, chúng phải giống hệt nhau. RFC 9989 lưu ý gần như mọi chủ sở hữu tên miền thấy căn chỉnh nới lỏng là đủ.
Một thư đạt DMARC khi SPF hoặc DKIM đạt và được căn chỉnh. Chỉ cần một trong hai. Một nhà cung cấp hộp thư như Proton Mail hay Fastmail ký bằng tên miền của bạn thông qua các bản ghi CNAME DKIM, nên căn chỉnh được đảm bảo mà không cần thêm việc. Bẫy là một dịch vụ bên thứ ba ký bằng tên miền riêng của họ: DKIM của họ đạt nhưng không căn chỉnh cho đến khi bạn thiết lập một tên miền ký tùy chỉnh cho nó.
RFC 9989 tìm tên miền tổ chức bằng cách duyệt cây DNS, với tối đa tám truy vấn, thay vì dùng danh sách hậu tố công cộng. Với một tên miền thông thường trên .com hay .me, điều này không thay đổi việc bạn phải làm.
Tôi nên ở p=none bao lâu?
Ở p=none ít nhất một tháng, rồi ở p=quarantine trong khoảng thời gian tương tự, trước khi chuyển sang p=reject. Đây là thứ tự RFC 9989 khuyên trong hướng dẫn triển khai, và nó khớp với các trang trợ giúp của nhà cung cấp. Mailbox.org bắt đầu bản ghi mẫu ở p=none và cảnh báo rằng một chính sách nghiêm ngặt đặt quá sớm có thể làm thư hợp lệ bị trả lại. Proton khuyến nghị p=quarantine và chuyển sang p=reject khi thư hợp lệ đã đạt.
Theo cách Postelva đọc hướng dẫn DMARC ngày 12 tháng 11 năm 2026 của 3 nhà cung cấp công bố nó (Proton Mail, Mailbox.org và Mailfence), 2 bắt đầu ở p=none và 1 khuyến nghị p=quarantine.
Có hai lưu ý với p=reject. RFC 9989 nói một tên miền dùng nó không được dựa chỉ vào SPF và phải ký bằng DKIM, vì SPF hỏng khi chuyển tiếp. Nó cũng nói các tên miền mà người dùng đăng lên danh sách thư không nên công bố p=reject. Danh sách thường sửa đổi thư, làm hỏng chữ ký.
Báo cáo DMARC đi đâu và chúng hiển thị gì?
Báo cáo tổng hợp được gửi tới địa chỉ mailto: trong rua, thường mỗi ngày một lần từ mỗi bên nhận, và liệt kê các nguồn đã gửi thư mang tên miền của bạn trong dòng From. RFC 9989 yêu cầu bên nhận hỗ trợ địa chỉ mailto: và khuyến nghị gửi báo cáo tổng hợp ít nhất mỗi 24 giờ. Báo cáo tổng hợp được định nghĩa trong RFC 9990.
Báo cáo lỗi, yêu cầu bằng ruf, là các bản sao theo từng thư. Nhiều bên nhận giữ lại hoặc che chúng vì quyền riêng tư, nên đừng trông chờ vào chúng. Nếu địa chỉ rua nằm ngoài tên miền của bạn, chủ sở hữu tên miền kia phải cho phép bằng một bản ghi TXT tại yourdomain._report._dmarc.otherdomain chứa v=DMARC1;, một quy tắc ngăn lạm dụng hộp thư của bên thứ ba. Với một tên miền cá nhân nhỏ, danh sách nguồn ngắn: nhà cung cấp của bạn, và rất ít thứ khác.
Để đọc những gì DNS của bạn công bố trước và sau mỗi giai đoạn, dùng các lệnh kiểm tra bản ghi MX, SPF, DKIM và DMARC.
Tên miền cá nhân của tôi có cần DMARC không?
Có, với mọi tên miền gửi thư: nó tốn một bản ghi TXT và chặn các thư giả mạo dùng tên bạn. Google yêu cầu DMARC, với chính sách none là đủ, từ người gửi trên 5.000 thư mỗi ngày tới tài khoản Gmail, và Microsoft áp dụng cùng ngưỡng cho Outlook.com. Một hộp thư cá nhân nằm xa dưới các giới hạn đó. Bản ghi vẫn cho bên nhận biết bạn muốn xử lý thư giả mạo thế nào.
Với một tên miền không gửi gì, đặt ngay p=reject cùng SPF -all và MX rỗng. Postelva có mẫu "không email" cho trường hợp đó. Với một tên miền có hộp thư, bắt đầu ở none. Khía cạnh vận chuyển của cùng biện pháp bảo vệ, mã hóa giữa các máy chủ, được bao quát trong cách thiết lập MTA-STS và TLS-RPT.
Một định nghĩa có thể trích dẫn: DMARC là chính sách DNS cho bên nhận biết phải làm gì với thư mà kết quả SPF và DKIM không khớp với tên miền From, và gửi báo cáo về điều đó đến đâu.
Câu hỏi về thiết lập DMARC
RFC 9989 có bắt buộc p=reject không?
Không. Tiêu chuẩn định nghĩa ba chính sách và để chủ sở hữu tên miền tự chọn. Nó khuyên một lộ trình từng bước và cảnh báo chống p=reject với các tên miền mà người dùng đăng lên danh sách thư.
RFC 9989 có thay đổi bản ghi DMARC hiện có của tôi không?
Các bản ghi vẫn bắt đầu bằng v=DMARC1, nên bản ghi đang chạy tiếp tục chạy. Thẻ ri đã bị bỏ, pct đã bị loại bỏ, và t, np và psd được thêm vào.
Điều gì xảy ra nếu tôi công bố p=reject quá sớm?
Thư hợp lệ không đạt căn chỉnh, như một công cụ bản tin bị quên, sẽ bị bên nhận từ chối. Các báo cáo ở p=none tồn tại để tìm những người gửi đó trước.
Tôi có thể dùng một hộp thư miễn phí cho báo cáo không?
Có, bất kỳ hộp thư nào bạn đọc được. Một địa chỉ hoặc bí danh riêng giữ các tệp báo cáo hằng ngày khỏi hộp thư chính.
Một tên miền có thể có bao nhiêu bản ghi DMARC?
Một bản ghi cho mỗi tên, tại _dmarc.yourdomain. Tên miền con có thể có bản ghi riêng hoặc kế thừa chính sách của cha qua sp.
Tóm lại
- DMARC là một bản ghi TXT tại _dmarc.yourdomain bắt đầu bằng v=DMARC1.
- RFC 9989 (tháng 5 năm 2026) là đặc tả hiện hành; nó thay thế RFC 7489 và loại bỏ pct.
- Bắt đầu với p=none kèm địa chỉ rua, đọc báo cáo trong khoảng một tháng.
- Rồi p=quarantine trong khoảng thời gian tương tự, sau đó p=reject.
- Một thư đạt khi SPF hoặc DKIM đạt và khớp với tên miền From; căn chỉnh nới lỏng là mặc định.
- Một tên miền ở p=reject không được dựa chỉ vào SPF và không nên dùng với danh sách thư.
- Postelva lưu bản ghi trong DNS miễn phí; một .com tốn 12,49 US$/năm mỗi năm.
Nguồn (6)
- RFC 9989, Domain-based Message Authentication, Reporting, and Conformance (DMARC) — RFC Editor (đọc 2026-11-12)
- RFC 7489, DMARC (đã bị thay thế) — RFC Editor (đọc 2026-11-12)
- SPF, DKIM và DMARC cho tên miền riêng — Mailbox.org (đọc 2026-11-12)
- Tên miền riêng và chống giả mạo — Proton (đọc 2026-11-12)
- Hướng dẫn cho người gửi email — Google Workspace Admin Help (đọc 2026-11-12)
- Tăng cường bảo mật email: yêu cầu mới cho người gửi khối lượng lớn — Microsoft Tech Community (đọc 2026-11-12)