SPF, DKIM và DMARC là ba cơ chế bổ sung nhau để xác thực email của tên miền. SPF kiểm tra máy chủ được phép gửi theo miền envelope/Return-Path; DKIM kiểm tra chữ ký số của email; DMARC yêu cầu miền xác thực SPF hoặc DKIM phải khớp (alignment) với miền hiển thị ở trường From và cho phép đặt chính sách xử lý thư không đạt.
Cách triển khai an toàn: liệt kê tất cả hệ thống gửi → cấu hình SPF/DKIM theo từng nhà cung cấp → gửi email thử và đọc header → bật DMARC quan sát → xử lý nguồn gửi sai → chỉ chuyển sang quarantine/reject khi biết chắc những email hợp lệ vẫn vượt kiểm tra. Đừng chép nguyên record mẫu cho domain thật.
SPF, DKIM và DMARC khác nhau như thế nào?
| Cơ chế | Máy chủ nhận kiểm tra | Cần chú ý |
|---|---|---|
| SPF | IP gửi có được miền Return-Path ủy quyền? | Chỉ một SPF TXT record hiệu lực cho miền; kiểm tra include và đường trả về |
| DKIM | Chữ ký có hợp lệ với khóa công khai DNS? | Selector, khóa riêng, nhà cung cấp đã bật ký chưa |
| DMARC | SPF hoặc DKIM pass và cùng miền tổ chức với From? | Alignment, chính sách p= và báo cáo aggregate |
Ví dụ minh họa: thư hiển thị From: support@example.com nhưng hệ thống marketing gửi với Return-Path của dịch vụ khác. SPF có thể pass cho miền dịch vụ mà không khớp miền example.com. Nếu DKIM ký với miền phù hợp thì DMARC vẫn có thể pass. Muốn biết phải đọc Authentication-Results của thư thật, không chỉ tra DNS.
Bước 1: Liệt kê các hệ thống gửi email trước khi sửa DNS
Một doanh nghiệp thường có Google Workspace/Microsoft 365, WordPress gửi form, CRM, công cụ email marketing, hóa đơn, helpdesk và dịch vụ OTP. Mỗi hệ thống có thể dùng From, Return-Path và DKIM khác nhau; bỏ sót một nguồn dễ làm email hợp lệ bị phân loại spam sau khi tăng chính sách DMARC.
| Nguồn gửi | Miền From / Return-Path | Người phụ trách / cách kiểm tra |
|---|---|---|
| Email nhân viên | Địa chỉ thương hiệu / hệ thống thư | IT xác nhận SPF, DKIM qua header |
| Form WordPress | Tên miền website / SMTP relay | Quản trị web gửi thử form thật |
| CRM / marketing | Miền gửi đã cấu hình / bounce domain | Marketing và nhà cung cấp xác nhận alignment |
| Hóa đơn / giao dịch | Miền thông báo / dịch vụ ứng dụng | Kế toán, kỹ thuật xác nhận bằng giao dịch thử |
Nếu dùng email từ website, đọc thêm Email Deliverability cho website. Hãy phân biệt email nhận được máy chủ chấp nhận với email thực sự xuất hiện trong inbox; ba cơ chế này không bảo đảm inbox placement hay chống mọi hình thức giả mạo.
Bước 2: Thiết lập SPF và DKIM đúng nguồn gửi
- SPF: tổng hợp các nguồn gửi được ủy quyền, không tạo nhiều bản ghi SPF riêng cho cùng một tên miền. Kiểm tra giới hạn DNS lookup, cơ chế include và IP của hệ thống thực.
- DKIM: tạo khóa/selector theo hướng dẫn chính xác của nhà cung cấp, xuất bản TXT/CNAME đúng tên, sau đó bật tính năng ký ở phía hệ thống gửi.
- Thư thử: gửi từ từng dịch vụ tới hộp thư kiểm tra và xem SPF, DKIM, DMARC trong header. Tránh xem “DNS đã có record” là bằng chứng email đã xác thực thành công.
- Đổi nhà cung cấp: gỡ nguồn không còn sử dụng khi chắc chắn, rà mọi luồng quan trọng trước khi sửa production domain.
Bước 3: Cấu hình DMARC bắt đầu từ chế độ giám sát
DMARC được công bố qua DNS TXT tại tên như _dmarc.example.com. Một ví dụ có tính minh họa là v=DMARC1; p=none; rua=mailto:dmarc@example.com. Đây không phải record dùng nguyên cho domain thật: địa chỉ báo cáo phải tồn tại, quyền nhận báo cáo phải rõ, và cần xác nhận yêu cầu của đơn vị nhận báo cáo nếu dùng miền khác.
p=none giúp theo dõi kết quả xác thực mà chưa yêu cầu nơi nhận áp dụng quarantine/reject. Sau khi đọc báo cáo, tìm các sender chưa được quản lý, sửa DKIM, SPF và alignment, rồi mới cân nhắc p=quarantine hoặc p=reject. Google và Cloudflare đều khuyến nghị bắt đầu bằng chế độ quan sát và chuyển chính sách từ từ.
Báo cáo DMARC tổng hợp giúp quan sát miền/IP đang gửi và xu hướng pass/fail, nhưng không phải bằng chứng tất cả email cụ thể đã tới inbox. Phân tích theo nhà cung cấp, nhóm mail và luồng có tác động như đơn hàng, OTP, báo giá; tránh lưu hoặc chia sẻ dữ liệu nhạy cảm không cần thiết.
Yêu cầu Gmail cho người gửi thông thường và người gửi hàng loạt
| Nhóm gửi tới Gmail cá nhân | Yêu cầu xác thực chính |
|---|---|
| Tất cả người gửi | SPF hoặc DKIM; DNS hợp lệ, TLS và các điều kiện định dạng/vận hành |
| Bulk sender khoảng 5.000 thư/ngày trở lên | SPF và DKIM và DMARC, alignment với From và các yêu cầu vận hành bổ sung |
| Thư marketing/đăng ký từ bulk sender | Hỗ trợ hủy đăng ký một lần nhấp và link hủy dễ thấy |
Gmail tính ngưỡng bulk sender theo miền tổ chức, bao gồm các subdomain, và khi đã được phân loại là bulk sender thì trạng thái này không tự hết. Chính sách cụ thể cần kiểm tra trên Gmail Email sender guidelines và FAQ; đây là yêu cầu gửi đến Gmail cá nhân, không nên suy diễn thành một điều luật áp dụng mọi máy chủ thư.
Bước 4: Kiểm tra và đổi DNS an toàn
- Chụp cấu hình DNS cũ và lưu bản sao trước khi sửa, ghi TTL và người phê duyệt.
- Chỉnh đúng record do nhà cung cấp yêu cầu, không tạo thêm SPF trùng cho cùng tên.
- Chờ DNS cập nhật và dùng công cụ kiểm tra TXT/CNAME.
- Gửi thư thử từ từng hệ thống quan trọng; đọc header và xem alignment, không dựa riêng vào trang kiểm tra record.
- Theo dõi báo cáo/khả năng gửi và có phương án khôi phục cấu hình cũ khi phát hiện mail hợp lệ bị ảnh hưởng.
Chi tiết về việc ghi snapshot, thay đổi, xác minh và rollback có trong DNS Change Management. Nếu có nhiều hệ thống email hoặc người phụ trách khác nhau, nên quản lý tập trung trong Domain, DNS & Email Infrastructure Operations.
Các lỗi thường gặp và cách xử lý
| Hiện tượng | Nên kiểm tra |
|---|---|
| SPF pass nhưng DMARC fail | Return-Path/From không align và DKIM có align không |
| DNS có DKIM nhưng thư vẫn fail | Nhà cung cấp chưa bật signing, selector hoặc nội dung đã bị sửa |
| Đặt nhiều SPF record | Hợp nhất cấu hình theo sender hợp lệ; tránh sửa mù |
| Mail hợp lệ bị reject sau bật DMARC | Rà report, nguồn gửi thiếu, điều kiện alignment; cân nhắc giảm enforcement tạm thời có kiểm soát |
| WordPress gửi nhưng khách không nhận | SMTP relay, log gửi, spam, bounce và header phía nhận |
Checklist nghiệm thu SPF, DKIM và DMARC
- Đã kiểm kê Google/Microsoft, WordPress, CRM, marketing, giao dịch và các công cụ gửi.
- Không có bản ghi SPF chồng chéo; chính sách thể hiện nguồn hợp lệ.
- DKIM ký thực và pass trong header với từng nhóm gửi chính.
- DMARC pass/alignment qua email thử thật, không chỉ record valid.
- Đã đọc báo cáo và xử lý các nguồn gửi chưa rõ trước khi tăng enforcement.
- Có owner, ngày rà tiếp và snapshot DNS để rollback.
- Đã thử email quan trọng như form liên hệ, đơn hàng, reset mật khẩu.
Kết luận: Xác thực email là một quy trình vận hành liên tục, không chỉ thêm ba bản ghi DNS. Hãy giữ source inventory, header test, báo cáo và quyền kiểm soát thay đổi trước khi bật chính sách mạnh. Nguồn tham khảo chính: Google Workspace – Recommended DMARC rollout và hướng dẫn Gmail ở trên.
Đoàn Trình Dục là Giảng viên Khoa Công nghệ Thông tin tại Đại học Công nghệ Sài Gòn (STU), với hơn 10 năm kinh nghiệm thực chiến trong các lĩnh vực Mạng máy tính, Marketing Online, SEO và Bảo mật hệ thống.
Với nền tảng sư phạm và kinh nghiệm tư vấn cho nhiều doanh nghiệp, thầy chuyên sâu vào việc xây dựng các giải pháp kỹ thuật số toàn diện và hiệu quả.