DMARC là gì? DMARC là bản ghi DNS cho phép chủ tên miền quy định cách máy chủ nhận xử lý email giả danh tên miền của mình (theo dõi, đưa vào spam hoặc từ chối), dựa trên kết quả kiểm tra SPF và DKIM. Gmail, Yahoo và Outlook đều yêu cầu người gửi số lượng lớn có SPF, DKIM và DMARC; thiếu các bản ghi này là lý do phổ biến khiến email công ty vào spam.
Bài viết giải thích SPF, DKIM, DMARC và cơ chế “khớp tên miền”, lý do email vào spam, cách cấu hình cho Google Workspace, Microsoft 365, Zoho Mail và các công cụ gửi bản tin, cách đọc báo cáo và lộ trình nâng chính sách an toàn. Thông tin cập nhật tháng 10/2026.
SPF là gì?
SPF (Sender Policy Framework) cho phép chủ tên miền khai báo những máy chủ nào được gửi email thay cho tên miền đó (RFC 7208) (IETF). Máy chủ nhận kiểm tra địa chỉ IP gửi đến có nằm trong danh sách này không.
Ví dụ một bản ghi SPF cho công ty dùng Google Workspace và gửi bản tin qua Amazon SES, đúng theo mẫu của Google Workspace:
example.com. TXT "v=spf1 include:_spf.google.com include:amazonses.com ~all"Phần cuối bản ghi quy định cách xử lý nguồn không có trong danh sách: -all là không được phép, ~all là “có lẽ không được phép” (Microsoft).
Hai lỗi hay gặp:
- Có nhiều bản ghi SPF: mỗi tên miền chỉ được có một bản ghi SPF. RFC 7208 quy định nếu tìm thấy nhiều hơn một bản ghi, kết quả là lỗi “permerror”. Khi dùng nhiều dịch vụ gửi email, phải gộp vào một bản ghi.
- Vượt 10 lượt tra cứu DNS: các thành phần include, a, mx, ptr, exists, redirect bị giới hạn tổng cộng 10; vượt quá sẽ báo lỗi. Các
includelồng nhau cũng được tính, cònip4,ip6vàallthì không (Microsoft).
Điểm yếu của SPF: nó chỉ kiểm tra địa chỉ “người gửi trên phong bì” (envelope from, hay Return-Path), không phải địa chỉ hiển thị ở dòng From. Đó là lý do cần DMARC.
DKIM là gì?
DKIM (DomainKeys Identified Mail) gắn chữ ký số vào email. Máy chủ nhận lấy khóa công khai trong DNS của tên miền gửi để kiểm tra email không bị sửa và đúng là do tên miền đó chịu trách nhiệm (RFC 6376) (IETF).
Mỗi khóa DKIM gắn với một “selector” (ví dụ selector1._domainkey), nên một tên miền có thể có nhiều khóa cho nhiều dịch vụ mà không xung đột.
Khác với SPF, chữ ký DKIM đi theo nội dung email nên thường vẫn còn hiệu lực khi email được chuyển tiếp (forward). Vì vậy DKIM là trụ cột quan trọng nhất để đạt DMARC khi bạn gửi qua dịch vụ bên thứ ba.
DMARC là gì?
DMARC cho phép tổ chức gửi email công bố chính sách ở cấp tên miền (RFC 7489) (IETF). Email đạt DMARC khi qua SPF hoặc DKIM và tên miền đó khớp với tên miền ở dòng “From”.
| Chính sách | Ý nghĩa |
|---|---|
| p=none | Chỉ theo dõi, nhận báo cáo, không chặn |
| p=quarantine | Email không đạt bị coi là đáng ngờ, thường vào spam |
| p=reject | Email không đạt bị từ chối |
Năm 2026, DMARC được cập nhật thành tiêu chuẩn chính thức RFC 9989; thẻ pct trong bản cũ bị bỏ nhưng các bản ghi cũ vẫn hoạt động (Mimecast). RFC 9989 được công bố tháng 5/2026, thay thế RFC 7489 và RFC 9091; phần báo cáo tổng hợp tách sang RFC 9990. Bản mới bỏ các thẻ pct, rf, ri, thêm thẻ np (chính sách cho tên miền con không tồn tại) và t (chế độ thử nghiệm) thay cho pct.
Theo báo cáo của EasyDMARC năm 2025, tỷ lệ áp dụng DMARC trong khoảng 1,8 triệu tên miền của các công ty lớn tăng từ 27,2% (2023) lên 47,7% (2025), nhưng phần lớn vẫn để chính sách p=none: 508.269 tên miền ở p=none so với 350.513 tên miền ở quarantine hoặc reject (EasyDMARC).
Cơ chế khớp tên miền (alignment)
Alignment là điểm làm DMARC khác biệt. Kẻ gian có thể gửi email đạt SPF cho tên miền rác của họ nhưng ghi dòng From là tên miền của bạn. SPF “đạt”, nhưng tên miền đạt SPF không khớp với From, nên DMARC vẫn “không đạt”.
Có hai chế độ khớp, đặt bằng thẻ adkim và aspf (RFC 9989):
- Relaxed (r, mặc định): chỉ cần cùng tên miền tổ chức. Ví dụ DKIM ký bằng
mail.example.comvẫn khớp với Fromexample.com. - Strict (s): phải trùng khớp hoàn toàn tên miền.
Gmail và Yahoo đều chấp nhận chế độ relaxed, miễn là tên miền From khớp với tên miền SPF hoặc DKIM (Google, Yahoo).
Các thẻ trong bản ghi DMARC
| Thẻ | Ý nghĩa | Mặc định / ghi chú |
|---|---|---|
| v | Phiên bản, phải là DMARC1 và đứng đầu |
Bắt buộc |
| p | Chính sách: none, quarantine, reject | Nếu thiếu, coi như none (RFC 9989) |
| rua | Địa chỉ nhận báo cáo tổng hợp, dạng mailto: |
Không có thì không nhận báo cáo |
| ruf | Địa chỉ nhận báo cáo lỗi từng email | Google không gửi loại báo cáo này |
| pct | Phần trăm email không đạt bị áp chính sách | Mặc định 100; bị bỏ trong RFC 9989 |
| sp | Chính sách cho tên miền con | Kế thừa p nếu không khai báo |
| adkim | Chế độ khớp DKIM: r hoặc s | r |
| aspf | Chế độ khớp SPF: r hoặc s | r |
Bảng tổng hợp từ Google Workspace Admin và RFC 9989.
Vì sao email công ty vào spam?
Từ năm 2024, các nhà cung cấp email lớn siết yêu cầu với người gửi:
- Gmail (từ 1/2/2024): mọi người gửi cần SPF hoặc DKIM, DNS hợp lệ, TLS và tỷ lệ bị báo spam dưới 0,3%. Người gửi trên 5.000 email/ngày cần đủ SPF, DKIM, DMARC, tên miền khớp và nút hủy đăng ký một chạm. Google cũng khuyến nghị giữ tỷ lệ spam dưới 0,1% và cho phép DMARC ở mức p=none (Google).
- Yahoo (từ 2/2024): người gửi số lượng lớn cần SPF, DKIM, DMARC tối thiểu p=none, xử lý hủy đăng ký trong 2 ngày, tỷ lệ spam dưới 0,3% (Yahoo).
- Outlook (từ 5/5/2025): người gửi trên 5.000 email/ngày tới Outlook.com, Hotmail.com, Live.com không đạt SPF, DKIM, DMARC (tối thiểu p=none, có khớp tên miền) bị từ chối với lỗi “550 5.7.515 Access denied” (dmarcian, Microsoft, Mailgun).
Doanh nghiệp nhỏ gửi ít hơn 5.000 email/ngày vẫn nên làm đủ ba bản ghi: ngưỡng này chỉ quyết định mức bắt buộc, còn bộ lọc spam vẫn chấm điểm mọi email dựa trên xác thực.
Nguyên nhân thường gặp khác: gửi từ dịch vụ email marketing chưa xác thực tên miền, danh sách nhận chất lượng thấp, nội dung giống thư rác.
Cách cấu hình SPF, DKIM, DMARC
Theo hướng dẫn của Google Workspace (Google Workspace Admin):
- Bật SPF: thêm một bản ghi TXT SPF liệt kê mọi dịch vụ gửi email của công ty (email công ty, email marketing, phần mềm CRM).
- Bật DKIM trong trang quản trị dịch vụ email và thêm bản ghi DNS được cung cấp.
- Chờ 48 giờ sau khi bật SPF, DKIM rồi mới tạo DMARC.
- Tạo hộp thư hoặc nhóm nhận báo cáo DMARC.
- Thêm bản ghi TXT tại tên
_dmarc.tenmiencuaban.vn, bắt đầu với chính sách theo dõi, ví dụ:v=DMARC1; p=none; rua=mailto:dmarc@tenmiencuaban.vn. - Đọc báo cáo, xác thực các dịch vụ còn thiếu, sau đó nâng dần lên p=quarantine rồi p=reject.
- Kiểm tra bằng công cụ kiểm tra DMARC sau mỗi lần thay đổi.
Google Workspace
Bản ghi SPF chỉ dùng Google Workspace là v=spf1 include:_spf.google.com ~all; nếu dùng thêm dịch vụ khác, thêm include của dịch vụ đó vào cùng bản ghi (Google Workspace). DKIM được tạo trong Admin console, sau đó dán bản ghi TXT vào DNS.
Microsoft 365
Bản ghi SPF chuẩn là v=spf1 include:spf.protection.outlook.com -all; Microsoft khuyến nghị dùng -all và không “làm phẳng” (flatten) bản ghi của mình vì dải IP gửi thay đổi thường xuyên (Microsoft). DKIM cho tên miền riêng được bật trong Microsoft Defender portal (Email & collaboration > Policies & rules > Threat policies > Email authentication settings > DKIM): tạo hai bản ghi CNAME selector1 và selector2 với giá trị hiển thị trong tài khoản, rồi bật ký DKIM (Microsoft).
Zoho Mail
Theo Zoho, bản ghi SPF cho Zoho Mail là v=spf1 include:zohomail.com -all; nếu dùng nhiều dịch vụ Zoho, dùng include:one.zoho.com. DKIM lấy trong mục Email Configuration của trang quản trị, thêm bản ghi TXT tại zmail._domainkey rồi bấm Verify (EasyDMARC).
Brevo, Mailchimp và công cụ gửi bản tin
Các công cụ gửi bản tin thường dùng tên miền “phong bì” của chính họ, nên SPF của bạn không khớp với From. DMARC lúc này đạt nhờ DKIM ký bằng tên miền của bạn:
- Brevo: yêu cầu một bản ghi TXT “Brevo code”, DKIM (1 TXT hoặc 2 CNAME, cần CNAME nếu muốn khóa 2048 bit) và một bản ghi DMARC. Brevo nêu rõ SPF và MX không bắt buộc để xác thực tên miền, trừ khi dùng IP riêng (Brevo).
- Mailchimp: yêu cầu 2 bản ghi CNAME cho DKIM và một bản ghi DMARC tại
_dmarc(Mailchimp).
Nguyên tắc chung: tên miền chỉ có một bản ghi DMARC và một bản ghi SPF. Nếu dịch vụ mới yêu cầu thêm SPF, hãy gộp include vào bản ghi sẵn có thay vì tạo bản ghi thứ hai.
# Sai: hai bản ghi SPF riêng lẻ trên cùng tên miền example.com. TXT "v=spf1 include:_spf.google.com ~all" example.com. TXT "v=spf1 include:amazonses.com ~all" # Đúng: một bản ghi duy nhất, gộp đủ dịch vụ example.com. TXT "v=spf1 include:_spf.google.com include:amazonses.com ~all"Lộ trình nâng chính sách DMARC
Lộ trình dưới đây theo khuyến nghị của Google Workspace:
| Giai đoạn | Bản ghi mẫu | Thời gian tối thiểu | Việc cần làm |
|---|---|---|---|
| 1. Theo dõi | v=DMARC1; p=none; rua=mailto:dmarc@example.com |
Khoảng 1 tuần | Đọc báo cáo hằng ngày, tìm nguồn gửi chưa xác thực |
| 2. Cách ly một phần | v=DMARC1; p=quarantine; pct=5; rua=mailto:dmarc@example.com |
Sau ít nhất 1 tuần không có lỗi | Tăng pct dần, tiếp tục đọc báo cáo |
| 3. Từ chối | v=DMARC1; p=reject; rua=mailto:dmarc@example.com |
Khi đã chắc chắn | Duy trì theo dõi báo cáo |
Google gợi ý mức pct khởi đầu khoảng 10% cho tổ chức nhỏ và 1% cho tổ chức lớn, và cảnh báo không dùng p=reject khi chưa chuẩn bị kỹ. Với RFC 9989, thẻ pct được thay bằng t=y (chế độ thử nghiệm: quarantine hoạt động như none, reject như quarantine); tuy vậy các nhà cung cấp vẫn chấp nhận bản ghi có pct (Mimecast).
Cách đọc báo cáo DMARC
Báo cáo tổng hợp (rua) là tệp XML, thường nén gzip. RFC 9989 khuyến nghị bên nhận gửi báo cáo ít nhất mỗi 24 giờ (RFC 9989). Mỗi báo cáo có các phần chính theo RFC 9990:
- report_metadata: tổ chức gửi báo cáo (ví dụ google.com) và khoảng thời gian.
- policy_published: chính sách DMARC mà họ đọc được từ DNS của bạn.
- record: mỗi dòng gồm
source_ip(IP gửi),count(số email), kết quả DKIM, SPF sau đánh giá DMARC vàheader_from.
Cách đọc: lọc các dòng không đạt DMARC, tra IP gửi để biết đó là dịch vụ của công ty (CRM, phần mềm hóa đơn, website) hay nguồn lạ. Dịch vụ của mình thì cấu hình DKIM, SPF; nguồn lạ chính là email giả mạo mà p=reject sẽ chặn.
Công cụ kiểm tra miễn phí
- MXToolbox DMARC Check: lấy bản ghi DMARC của tên miền, hiển thị và chạy kiểm tra lỗi (MXToolbox).
- Google Admin Toolbox Check MX: tìm lỗi cấu hình MX và DNS thường gặp (Google).
- Google Admin Toolbox Messageheader: phân tích tiêu đề đầy đủ của email để tìm lỗi chuyển phát và định tuyến.
Lỗi thường gặp khi cấu hình
| Lỗi | Hậu quả | Cách sửa |
|---|---|---|
| Hai bản ghi SPF trên cùng tên miền | SPF báo permerror | Gộp thành một bản ghi |
| Quá 10 lượt tra cứu DNS trong SPF | SPF báo permerror | Bỏ dịch vụ thừa, dùng ip4/ip6 hoặc tên miền con (Microsoft) |
| Công cụ bản tin chưa ký DKIM bằng tên miền riêng | DMARC không đạt do không khớp | Xác thực tên miền trong Brevo, Mailchimp |
| Đặt p=reject ngay từ đầu | Email thật bị chặn | Bắt đầu p=none, nâng dần |
| Dừng ở p=none nhiều năm | Không chặn được giả mạo | Lên lộ trình quarantine, reject |
Với email chuyển tiếp và danh sách thư (mailing list), SPF thường hỏng vì máy chủ trung gian gửi lại email; RFC 9989 khuyến cáo bên nhận nên xử lý các luồng gián tiếp này như quarantine thay vì reject (Mimecast). Đây thêm một lý do để ưu tiên DKIM.
Checklist cho doanh nghiệp
DMARC ở mức p=reject giúp chống kẻ gian giả mạo email công ty để lừa khách hàng, đối tác. Xem thêm an ninh mạng cho doanh nghiệp vừa và nhỏ, cuộc gọi mạo danh cơ quan thuế và 10 bài học bảo mật từ các vụ tấn công mạng doanh nghiệp Việt.
FAQ: Câu hỏi thường gặp về DMARC
DMARC là gì?
DMARC là bản ghi DNS giúp chủ tên miền quy định cách xử lý email giả danh tên miền của mình: chỉ theo dõi, đưa vào spam hoặc từ chối, dựa trên kết quả SPF, DKIM và việc khớp tên miền. Bản ghi đặt tại _dmarc.tenmien và có thể kèm địa chỉ nhận báo cáo.
SPF là gì?
SPF là bản ghi DNS khai báo những máy chủ được phép gửi email thay cho tên miền. Mỗi tên miền chỉ có một bản ghi SPF và tối đa 10 lượt tra cứu DNS.
DKIM là gì?
DKIM là chữ ký số gắn vào email, giúp máy chủ nhận kiểm tra email đúng do tên miền gửi chịu trách nhiệm và không bị sửa trên đường đi.
Vì sao email công ty vào spam?
Thường do thiếu hoặc sai SPF, DKIM, DMARC, gửi qua dịch vụ chưa xác thực tên miền, tỷ lệ bị báo spam cao hoặc danh sách nhận chất lượng thấp. Gmail, Yahoo, Outlook đều yêu cầu xác thực với người gửi số lượng lớn.
Có nên đặt DMARC p=reject ngay không?
Không nên. Hãy bắt đầu bằng p=none để nhận báo cáo, xác thực đủ mọi dịch vụ gửi email, sau đó mới nâng lên quarantine và reject để tránh chặn nhầm email thật. Google khuyến nghị theo dõi ít nhất một tuần trước khi chuyển sang quarantine.
Công ty gửi ít email có cần DMARC không?
Có. Ngưỡng 5.000 email/ngày chỉ là mức bắt buộc của Gmail, Yahoo, Outlook. DMARC còn ngăn kẻ gian dùng tên miền của bạn để gửi hóa đơn giả hoặc yêu cầu chuyển khoản, rủi ro này không phụ thuộc vào lượng email bạn gửi.
Kết luận
Tóm lại: SPF, DKIM và DMARC là bộ ba giúp email công ty vào hộp thư chính và chống giả mạo.
- SPF khai báo máy chủ được gửi, DKIM ký số email, DMARC quy định cách xử lý email không đạt.
- Gmail, Yahoo, Outlook đều yêu cầu bộ ba này với người gửi số lượng lớn.
- Bắt đầu với p=none, đọc báo cáo ít nhất một tuần rồi nâng dần lên p=reject.
