Bảo mật email doanh nghiệp: SPF, DKIM, DMARC cấu hình trong 30 phút
Bảo mật email doanh nghiệp: SPF, DKIM, DMARC cấu hình trong 30 phút
Đối tác gọi điện hỏi: "Sao công ty anh gửi email đòi chuyển tiền vào tài khoản lạ?" — trong khi bạn chưa từng gửi email đó. Kẻ xấu đã giả mạo địa chỉ @congtycuaban.com để lừa đảo, và bạn không hay biết cho đến khi có người bị hại. Đây là kịch bản xảy ra mỗi ngày với doanh nghiệp chưa cấu hình SPF DKIM DMARC — bộ ba bản ghi DNS giúp chứng minh "email này đúng là do công ty tôi gửi".
Tin tốt: triển khai cả ba chỉ mất khoảng 30 phút nếu bạn có quyền quản trị DNS của tên miền. Bài viết này hướng dẫn từng bước, kèm lộ trình nâng dần chính sách để không chặn nhầm email hợp lệ.
Cấu hình spf dkim dmarc: email giả mạo tên miền nguy hiểm thế nào?
Giao thức email (SMTP) ra đời từ thời Internet còn sơ khai — khi mọi người mặc định tin nhau — nên không có cơ chế xác thực người gửi ở tầng giao thức. Bất kỳ ai cũng có thể gửi email với địa chỉ "From" là ketoan@congtycuaban.com mà không cần biết mật khẩu của bạn.
Kẻ tấn công khai thác điểm yếu này theo nhiều cách: giả mạo email từ ban lãnh đạo yêu cầu chuyển tiền gấp (BEC); phát tán mã độc dưới danh nghĩa phòng nhân sự, kế toán của công ty bạn; hoặc dùng tên miền của bạn gửi spam hàng loạt, khiến tên miền bị Gmail, Outlook đánh dấu xấu — email thật sau đó cũng rớt vào spam.
SPF, DKIM và DMARC sinh ra để vá đúng lỗ hổng này. Chúng là các bản ghi DNS công khai, cho phép máy chủ nhận kiểm tra: email có thực sự từ hạ tầng được ủy quyền không, nội dung có bị sửa đổi không, và nếu không đạt thì xử lý thế nào.
Cấu hình spf dkim dmarc: sPF là gì và cách cấu hình
SPF (Sender Policy Framework) là bản ghi DNS dạng TXT liệt kê những máy chủ được phép gửi email thay mặt tên miền của bạn. Khi email đến, máy chủ nhận tra cứu bản ghi SPF của tên miền trong địa chỉ "From", so sánh IP của máy gửi với danh sách — khớp thì đạt, không khớp thì trượt.
Cách cấu hình (ví dụ tên miền congty.com dùng Google Workspace để gửi mail):
- Đăng nhập trang quản trị DNS của tên miền (nơi bạn mua domain hoặc đơn vị quản lý nameserver).
- Tạo bản ghi TXT tại host
@(root domain) với giá trị:v=spf1 include:_spf.google.com ~all - Lưu và chờ DNS lan truyền (thường từ vài phút đến vài giờ).
Giải thích cú pháp: v=spf1 khai báo bản ghi SPF; include:_spf.google.com ủy quyền cho hạ tầng Google; ~all (softfail) nghĩa là nguồn khác "nên" bị đánh dấu không đạt nhưng chưa từ chối hẳn. Khi đã chắc chắn, chuyển sang -all (hard fail) để chặn triệt để.
Lưu ý quan trọng: mỗi tên miền chỉ được có một bản ghi SPF duy nhất. Thêm dịch vụ gửi mail mới thì gộp include:... vào bản ghi hiện tại, không tạo bản ghi thứ hai.
Cấu hình spf dkim dmarc: dKIM là gì và cách cấu hình
DKIM (DomainKeys Identified Mail) dùng chữ ký số để đảm bảo email không bị sửa đổi trên đường truyền. Mỗi email gửi đi được "ký" bằng khóa bí mật (private key) trên máy chủ gửi; máy chủ nhận lấy khóa công khai (public key) công bố trong DNS của bạn để kiểm tra chữ ký. Chữ ký hợp lệ nghĩa là nội dung nguyên vẹn và đúng là do hạ tầng của bạn ký.
Cách cấu hình:
- Tạo cặp khóa DKIM trên hệ thống mail. Với Google Workspace: Admin Console → Gmail → Xác thực email → tạo khóa DKIM mới (2048-bit). Với Zimbra: lệnh
zmdkimkeyutil -a -d tenmien.com. - Công bố public key lên DNS: tạo bản ghi TXT tại
<selector>._domainkeyvới giá trị dạngv=DKIM1; k=rsa; p=MIIBIjANBg...do hệ thống cung cấp. - Bật ký DKIM cho tên miền trên hệ thống mail.
DKIM mạnh hơn SPF ở chỗ nó gắn với nội dung email chứ không chỉ IP máy gửi — email bị chuyển tiếp qua nhiều hệ thống trung gian vẫn giữ được chữ ký hợp lệ, trong khi SPF có thể trượt trong trường hợp forwarding. Đó là lý do cần cả hai song song.
DMARC là gì và cách cấu hình
DMARC (Domain-based Message Authentication, Reporting and Conformance) là "nhạc trưởng" đứng trên SPF và DKIM. Nó làm hai việc mà hai chuẩn kia không làm:
- Quy định hành động khi email trượt kiểm tra: bỏ qua (none), đưa vào spam (quarantine), hay từ chối hẳn (reject).
- Yêu cầu báo cáo: các máy chủ nhận gửi báo cáo tổng hợp (aggregate report) về cho bạn — nhờ đó bạn biết được ai đang gửi mail "nhân danh" tên miền mình, kể cả kẻ giả mạo.
Cách cấu hình bản ghi DMARC đầu tiên (an toàn nhất):
- Tạo bản ghi TXT tại host
_dmarcvới giá trị:v=DMARC1; p=none; rua=mailto:bao-cao@congty.com - Trong đó
p=nonenghĩa là "chỉ theo dõi, chưa chặn";rualà địa chỉ nhận báo cáo tổng hợp hàng ngày từ các nhà cung cấp email lớn.
Tuyệt đối không bắt đầu với p=reject khi chưa chắc chắn mọi luồng mail hợp lệ (mail marketing, mail từ CRM, mail từ máy scan...) đều đã đạt SPF/DKIM. Bắt đầu bằng none, theo dõi báo cáo 1–2 tuần, rồi mới nâng dần — lộ trình chi tiết ở mục sau.
Lộ trình 30 phút: từng bước thực hiện
Giả sử bạn đã có quyền quản trị DNS và biết hệ thống nào đang gửi mail cho tên miền (mail server chính, Google Workspace/Microsoft 365, dịch vụ gửi mail marketing...). Bắt đầu bấm giờ:
Phút 0–5: Kiểm tra hiện trạng. Dùng MXToolbox (mxtoolbox.com) xem tên miền đã có bản ghi SPF, DKIM, DMARC nào chưa. Ghi lại các hệ thống đang gửi mail (hỏi đội IT/marketing, kiểm tra log mail server).
Phút 5–15: Cấu hình SPF. Tạo/gộp bản ghi TXT SPF bao gồm đầy đủ mọi nguồn gửi hợp lệ. Dùng ~all ở giai đoạn đầu.
Phút 15–25: Cấu hình DKIM. Tạo khóa DKIM trên từng hệ thống gửi mail chính, công bố public key lên DNS, bật ký DKIM.
Phút 25–30: Cấu hình DMARC ở chế độ theo dõi. Tạo bản ghi TXT tại _dmarc với p=none và địa chỉ nhận báo cáo rua. Xong — từ hôm nay bạn bắt đầu nhận báo cáo về mọi email "nhân danh" tên miền mình.
Sau 30 phút, tên miền của bạn đã có đủ bộ ba. Nhưng công việc chưa xong — 2 tuần tiếp theo mới là giai đoạn quan trọng: đọc báo cáo DMARC để nâng chính sách.
Lộ trình nâng chính sách DMARC: none → quarantine → reject
| Giai đoạn | Chính sách | Thời gian | Mục tiêu |
|---|---|---|---|
| 1. Theo dõi | p=none |
1–2 tuần | Thu thập báo cáo, liệt kê mọi nguồn gửi hợp lệ |
| 2. Cách ly | p=quarantine; pct=25 → tăng dần 100 |
2–4 tuần | Email giả mạo vào spam, phát hiện nguồn hợp lệ bị sót |
| 3. Từ chối | p=reject |
Duy trì | Chặn triệt để email giả mạo tên miền |
Cách đọc báo cáo ở giai đoạn 1: file XML liệt kê từng nguồn IP đã gửi mail nhân danh tên miền bạn, kèm kết quả SPF/DKIM. Nguồn hợp lệ nhưng trượt → bổ sung vào SPF hoặc bật DKIM cho nó. Nguồn IP lạ → đó chính là kẻ đang giả mạo (hoặc đã từng thử).
Khi chuyển sang quarantine, dùng tham số pct để áp dụng dần: pct=25 nghĩa là chỉ 25% email trượt bị cách ly, còn lại vẫn cho qua — giúp phát hiện sai sót mà không gây gián đoạn lớn. Tăng dần lên 100 rồi mới chuyển sang reject.
Mục tiêu cuối cùng là p=reject: mọi email giả mạo tên miền bị từ chối ngay tại cổng. Đây là mức bảo vệ mà các tổ chức tài chính, ngân hàng thường áp dụng.
5 lỗi cấu hình phổ biến cần tránh
1. Hai bản ghi SPF trên một tên miền. Chuẩn SPF chỉ cho phép một bản ghi TXT bắt đầu bằng v=spf1. Hai bản ghi khiến kết quả kiểm tra không xác định (permerror). Luôn gộp mọi nguồn vào một dòng duy nhất.
2. Quên nguồn gửi phụ. Rất nhiều doanh nghiệp cấu hình xong cho mail server chính nhưng quên dịch vụ gửi mail marketing, CRM gửi mail tự động, máy in/scan gửi mail... Những email này sẽ trượt SPF khi lên reject. Liệt kê đầy đủ mọi nguồn trước khi nâng chính sách.
3. Vượt giới hạn 10 lần tra cứu DNS của SPF. Mỗi include có thể kéo theo nhiều lần tra cứu lồng nhau; chuẩn SPF giới hạn 10 lần. Gộp quá nhiều dịch vụ dễ vượt ngưỡng → SPF lỗi. Giải pháp: dùng ip4: trực tiếp cho nguồn có IP cố định thay vì include.
4. Bắt đầu DMARC với p=reject ngay. Sai lầm kinh điển gây gián đoạn email hợp lệ trên diện rộng. Luôn đi theo lộ trình none → quarantine → reject.
5. Tạo bản ghi xong rồi... quên luôn. DNS có thể bị sửa nhầm khi đổi nhà cung cấp, chuyển nameserver, hoặc ai đó "dọn dẹp" bản ghi TXT. Kiểm tra định kỳ bằng MXToolbox và theo dõi báo cáo DMARC thường xuyên.
Kiểm tra và giám sát sau khi cấu hình
Cấu hình xong không có nghĩa là xong mãi mãi. Bộ công cụ giám sát nên duy trì:
- MXToolbox (mxtoolbox.com): kiểm tra nhanh SPF, DKIM, DMARC của tên miền bất kỳ lúc nào, miễn phí. Nên kiểm tra lại sau mỗi lần thay đổi DNS hoặc đổi nhà cung cấp dịch vụ mail.
- Báo cáo DMARC (rua): đọc định kỳ để phát hiện nguồn gửi lạ — đây là "radar" phát hiện giả mạo.
- Kiểm tra gửi thử: gửi email test tới Gmail và xem header — Gmail hiển thị rõ
SPF: PASS,DKIM: PASS,DMARC: PASS.
Khi đổi nhà cung cấp email (ví dụ chuyển từ Google Workspace sang mail server riêng), nhớ cập nhật cả ba bản ghi tương ứng — đây là thời điểm nhiều doanh nghiệp làm "rơi" cấu hình cũ.
Vai trò của mail server riêng trong bảo mật email
SPF/DKIM/DMARC bảo vệ tên miền của bạn khỏi bị giả mạo — nhưng bản thân hệ thống mail cũng cần được bảo vệ: chống spam/virus inbound, mã hóa kết nối, backup email, phân quyền truy cập.
Với doanh nghiệp có yêu cầu cao về kiểm soát dữ liệu (không muốn email nội bộ nằm trên hạ tầng nước ngoài, cần tuân thủ quy định lưu trữ trong nước), mail server riêng là lựa chọn đáng cân nhắc. SunCloud cung cấp SunMail — Cloud Email Server riêng với số lượng tài khoản không giới hạn, tùy chỉnh dung lượng hộp thư, sao lưu định kỳ, dùng thử 10 ngày (có gói Free miễn phí 1 năm). Khi dùng mail server riêng, đội ngũ kỹ thuật sẽ hỗ trợ cấu hình đầy đủ SPF, DKIM, DMARC ngay từ đầu.
Kết luận
Cấu hình SPF DKIM DMARC là việc bảo mật email có tỷ lệ hiệu quả trên công sức cao nhất: khoảng 30 phút thao tác DNS để có SPF, DKIM và DMARC ở chế độ theo dõi. Sau đó dành 2–4 tuần đọc báo cáo và nâng dần chính sách lên quarantine rồi reject — chặn đứng gần như toàn bộ email giả mạo tên miền.
Đừng để đến khi đối tác gọi điện hỏi về email lừa đảo "từ công ty bạn" mới bắt đầu. Kiểm tra ngay hôm nay trên MXToolbox xem tên miền của mình đã có đủ bộ ba chưa — nếu chưa, 30 phút cuối giờ chiều nay là đủ.
Nếu bạn đang dùng email doanh nghiệp và muốn rà soát toàn diện bảo mật email (từ SPF/DKIM/DMARC đến chống spam, backup và phương án mail server riêng), đội ngũ SunCloud hỗ trợ tư vấn miễn phí. Liên hệ hotline 083 979 3434 hoặc truy cập suncloud.vn để được hỗ trợ.
Câu hỏi thường gặp
Chỉ cấu hình SPF thôi có đủ không?
Không. SPF chỉ kiểm tra IP máy gửi và dễ trượt khi email bị chuyển tiếp. DKIM bảo vệ tính toàn vẹn nội dung, DMARC quy định hành động khi trượt và cung cấp báo cáo giám sát. Cần cả ba để bảo vệ hoàn chỉnh.
Cấu hình DMARC có ảnh hưởng email đang gửi bình thường không?
Nếu bắt đầu với p=none thì không — chế độ này chỉ theo dõi. Chỉ khi nâng lên quarantine/reject mà còn sót nguồn gửi hợp lệ chưa cấu hình thì email đó mới bị ảnh hưởng. Vì vậy lộ trình nâng dần là bắt buộc.
Bao lâu thì bản ghi DNS mới có hiệu lực?
Tùy TTL của bản ghi và nhà cung cấp DNS, thường từ vài phút đến vài giờ, tối đa khoảng 24–48 giờ trong trường hợp xấu. Khi cấu hình, đặt TTL thấp (300 giây) để dễ sửa sai, sau khi ổn định mới tăng lên.
Dùng Google Workspace/Microsoft 365 thì có cần tự cấu hình không?
Có. Các nền tảng này tự sinh giá trị bản ghi, nhưng bạn vẫn phải tự thêm vào DNS của tên miền mình — họ không thể sửa DNS thay bạn. Đây là bước nhiều doanh nghiệp bỏ sót.
Báo cáo DMARC gửi về quá nhiều, xử lý thế nào?
Dùng công cụ phân tích DMARC để gom báo cáo XML thành dashboard trực quan thay vì đọc thủ công từng file. Chỉ cần chú ý hai nhóm: nguồn hợp lệ nhưng trượt kiểm tra (cần sửa cấu hình) và nguồn IP lạ (dấu hiệu giả mạo).
Tên miền không dùng để gửi email có cần DMARC không?
Cần — thậm chí rất cần. Tên miền "đắp chiếu" là mục tiêu giả mạo lý tưởng vì chủ sở hữu không theo dõi. Hãy đặt bản ghi DMARC với p=reject và SPF v=spf1 -all (không cho phép bất kỳ ai gửi) để khóa hoàn toàn.
