DMARC là gì, vì sao doanh nghiệp cần bật để chặn giả mạo

Tháng 2/2024, Google và Yahoo bắt đầu bắt buộc DMARC với mọi nguồn gửi trên 5.000 email/ngày vào Gmail. Doanh nghiệp nhỏ chưa nằm trong diện bắt buộc, nhưng thư giả danh tên miền công ty vẫn gửi được bình thường nếu lớp bảo vệ này chưa bật. Ai đó lấy đúng tên miền công ty, viết y hệt văn phong kế toán, gửi yêu cầu chuyển khoản, và máy chủ nhận thư không có căn cứ nào để từ chối. Đây là lớp cuối cùng ngăn chuyện đó: nó quy định máy chủ nhận thư phải làm gì khi một email tự xưng là của tên miền công ty nhưng không qua được hai lớp xác thực SPF và DKIM.

DMARC là gì

DMARC (Domain-based Message Authentication, Reporting and Conformance) là bản ghi DNS ra lệnh cho máy chủ nhận thư: nếu một email không qua được cả SPF lẫn DKIM, phải bỏ vào spam, chặn hẳn, hay vẫn cho vào hộp thư bình thường. Theo RFC 7489, cơ chế này không tự xác thực gì mới, chỉ đọc kết quả của hai lớp kia rồi quyết định hành động.

Ba mảnh ghép đứng cạnh nhau trong một email đến. SPF trả lời câu "địa chỉ IP này có được phép gửi thay tên miền không". DKIM trả lời câu "nội dung thư có bị chỉnh sửa trên đường đi không". Bản ghi thứ ba trả lời câu mà hai lớp kia bỏ ngỏ: "vậy thì làm gì khi cả hai đều thất bại". Thiếu mảnh này, tên miền công ty vẫn bị mạo danh dù SPF và DKIM đã cấu hình đúng, vì máy chủ nhận thư của đối phương không buộc phải hành động gì nếu chủ tên miền không ra lệnh rõ.

SPF DKIM và lớp xác thực thứ ba khác nhau chỗ nào

SPF khai danh sách máy chủ được phép gửi email thay tên miền, DKIM ký một chữ ký số vào từng email để chứng minh nội dung chưa bị sửa trên đường đi, còn lớp thứ ba ra lệnh xử lý khi hai lớp trên thất bại, đồng thời gửi báo cáo hàng ngày về hộp thư quản trị. Ba bản ghi đứng độc lập trong DNS nhưng phải khai đủ cả ba mới thành một hệ thống hoàn chỉnh.

Không bật lớp bảo vệ này thì rủi ro gì

Không bật bản ghi này, ai cũng có thể gửi email với địa chỉ hiển thị đúng tên miền công ty mà máy chủ nhận thư không có căn cứ nào để chặn, vì SPF/DKIM thất bại không kéo theo hành động cụ thể. Đây là kiểu tấn công giả mạo tên miền hiển thị (domain spoofing), khác với việc chiếm quyền hộp thư thật.

Kịch bản phổ biến: khách hàng nhận thư từ đúng địa chỉ ketoan@congty.vn hiển thị trên thanh gửi, yêu cầu chuyển khoản vào số tài khoản mới vì "đổi ngân hàng". Thiếu lớp bảo vệ này, thư lọt qua hầu hết bộ lọc vì dùng đúng tên miền thật ở phần hiển thị, chỉ phần kỹ thuật phía sau là giả. Người nhận không có công cụ nào để phân biệt bằng mắt thường. Thiệt hại không chỉ là tiền chuyển nhầm, còn là uy tín tên miền công ty bị lợi dụng để lừa chính khách hàng của mình.

Lộ trình bật an toàn từng bước

Lộ trình đúng bắt đầu ở chế độ giám sát thuần túy (p=none) trong hai đến bốn tuần, đọc báo cáo để xác nhận mọi nguồn gửi hợp lệ đã được SPF/DKIM công nhận, rồi mới siết dần lên quarantine và cuối cùng reject. Bật thẳng reject ngay từ đầu là sai lầm phổ biến nhất, vì dễ bỏ sót một nguồn gửi hợp lệ như hệ thống email marketing hoặc phần mềm kế toán.

1. p=none: chỉ theo dõi, không chặn gì. Máy chủ nhận thư gửi báo cáo hàng ngày về địa chỉ đã khai, cho biết nguồn nào đang gửi thay tên miền và có qua được SPF/DKIM không.
2. Đọc báo cáo, đối chiếu nguồn gửi: liệt kê hết hệ thống thật sự cần gửi thay tên miền (mailBus, phần mềm hóa đơn điện tử, công cụ email marketing), đảm bảo từng nguồn đã khai đúng SPF hoặc ký DKIM riêng.
3. p=quarantine: thư thất bại bị đẩy vào spam thay vì bị từ chối thẳng, rủi ro thấp hơn nếu còn sót nguồn gửi hợp lệ chưa khai.
4. p=reject: thư thất bại bị từ chối hoàn toàn, không tới hộp thư người nhận. Chỉ bật khi báo cáo ở bước 2 đã sạch trong ít nhất hai tuần liên tiếp.

Cách khai bản ghi trong DNS và đọc báo cáo

Bản ghi khai ở dạng TXT tại subdomain _dmarc của tên miền chính, chứa chính sách xử lý (p), phần trăm áp dụng (pct) và địa chỉ nhận báo cáo (rua). Mỗi tên miền chỉ được khai đúng một bản ghi, khai trùng khiến máy chủ nhận thư bỏ qua cả hai.

Bản ghi mẫu ở chế độ giám sát ban đầu:

_dmarc.congty.vn.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-report@congty.vn; pct=100"

Khi đã siết lên quarantine, chỉ cần đổi giá trị p:

_dmarc.congty.vn.  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc-report@congty.vn; pct=100"

Báo cáo gửi về theo định dạng XML, liệt kê từng IP đã gửi thư thay tên miền công ty trong ngày kèm kết quả SPF, DKIM của mỗi nguồn. Đọc trực tiếp file XML khó theo dõi nên phần lớn doanh nghiệp dùng công cụ đọc báo cáo chuyên dụng để chuyển thành bảng dễ nhìn. Việc cần làm: xác định IP nào gửi hợp lệ nhưng SPF thất bại (thường do quên khai trong bản ghi SPF), IP nào không liên quan gì tới doanh nghiệp (dấu hiệu có bên thứ ba đang mạo danh), và IP nào là dịch vụ hợp lệ nhưng chữ ký DKIM chưa ký đúng.

Sai lầm hay gặp khi triển khai

Sai lầm nặng nhất là bật p=reject ngay từ đầu, khiến email hợp lệ từ nguồn chưa kịp khai SPF hoặc DKIM cũng bị chặn, doanh nghiệp mất thư khách hàng mà không biết vì thư bị từ chối ở phía máy chủ nhận, không hề vào cả mục spam để còn tìm lại được.

• Quên khai cho subdomain, nghĩ rằng bản ghi ở tên miền chính tự áp dụng cho mọi subdomain đang gửi thư.
• Không khai địa chỉ nhận báo cáo (rua), bật lên nhưng không ai đọc kết quả, không biết khi nào an toàn để siết chính sách.
• Đổi nhà cung cấp email marketing hoặc phần mềm hóa đơn điện tử mà quên cập nhật SPF, làm thư hợp lệ mới đột nhiên thất bại và bị chặn oan.
• Nhầm với việc lọc thư rác gửi đến hộp thư của chính mình. Cơ chế này bảo vệ tên miền khỏi bị người khác mạo danh khi gửi đi, không lọc thư rác gửi tới.

Câu hỏi thường gặp về lớp xác thực này

Điều cần nhớ trước khi bật DMARC

Ba lớp SPF, DKIM, DMARC cùng thiếu một cái là tên miền công ty vẫn có thể bị mượn để gửi thư giả. Bắt đầu bằng chế độ giám sát, đọc báo cáo trong vài tuần, xác nhận mọi nguồn gửi hợp lệ đã qua được cả hai lớp xác thực, rồi mới siết dần lên quarantine và reject. Gói email doanh nghiệp theo tên miền riêng của BizMaC đã bật sẵn SPF và DKIM ở tầng hạ tầng, phần này doanh nghiệp tự khai theo lộ trình trên hoặc nhờ đội kỹ thuật hỗ trợ cấu hình. Công ty gửi khối lượng lớn hoặc cần kiểm soát domain reputation riêng có thể cân nhắc thêm email server riêng để chủ động toàn bộ chính sách xác thực thay vì dùng chung hạ tầng gửi thư.