SPF, DKIM và DMARC: Xây lớp xác thực cho email tên miền doanh nghiệp

Một địa chỉ From mang tên doanh nghiệp không tự chứng minh thư thật sự được doanh nghiệp gửi. SMTP được thiết kế trong thời kỳ niềm tin cao, nên kẻ xấu có thể giả mạo domain hiển thị để phishing khách hàng và nhân viên. SPF, DKIM và DMARC tạo ba lớp bổ sung: công bố nguồn gửi hợp lệ, ký nội dung thư và đưa ra chính sách dựa trên sự liên kết danh tính.

Triển khai đúng không chỉ là thêm ba bản ghi DNS. Doanh nghiệp cần lập danh sách mọi hệ thống gửi thư, cấu hình alignment, thu thập báo cáo và tăng mức enforcement theo từng bước. Bật p=reject quá sớm có thể chặn hóa đơn, ticket hỗ trợ hoặc chiến dịch marketing hợp lệ.

1. Ba cơ chế giải quyết ba phần khác nhau

DMARC không yêu cầu cả SPF và DKIM cùng aligned để pass; chỉ cần ít nhất một đường xác thực pass và aligned. Trong vận hành, nên cấu hình cả hai để tăng độ bền.

2. SPF: danh sách nguồn gửi được ủy quyền

SPF là TXT record ở domain dùng cho MAIL FROM hoặc HELO. Record mô tả server, IP hoặc nhà cung cấp được phép gửi thay domain. Ví dụ minh họa:

example.com. TXT "v=spf1 ip4:203.0.113.20 include:_spf.mail-provider.example -all"

Doanh nghiệp chỉ nên có một SPF record bắt đầu bằng v=spf1 cho mỗi tên miền. Khi thêm dịch vụ, hãy hợp nhất cơ chế vào record hiện có thay vì tạo record thứ hai. SPF có giới hạn số DNS lookup trong quá trình đánh giá; chuỗi include lồng nhau quá sâu có thể gây permerror.

SPF thường thất bại khi thư được forward vì IP forwarder không nằm trong policy của sender gốc. Đây là lý do không nên phụ thuộc duy nhất vào SPF. Ngoài ra, +all cho phép mọi nguồn gửi và làm mất ý nghĩa bảo vệ; -all chỉ nên dùng khi inventory đã đầy đủ.

3. DKIM: chữ ký sống cùng thông điệp

Mail server ký một tập header và body bằng private key. Bên nhận đọc selector s= và signing domain d= trong DKIM-Signature, rồi truy vấn public key tại:

selector._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=PUBLIC_KEY_MATERIAL"

Private key phải nằm trong mail platform, không đưa vào DNS hay source code. Selector cho phép duy trì nhiều key và rotate mà không gián đoạn: xuất bản key mới, chuyển hệ thống sang selector mới, chờ thư cũ hết thời gian lưu, sau đó mới gỡ key cũ.

DKIM có thể sống sót qua forwarding nếu thư không bị sửa phần đã ký. Mailing list, gateway hoặc disclaimer chèn vào body có thể làm signature fail. Hãy kiểm tra từng tuyến gửi thay vì chỉ test mailbox nội bộ.

4. DMARC alignment mới gắn xác thực với From

Người nhận nhìn địa chỉ trong header From:, còn SPF kiểm tra envelope domain và DKIM dùng signing domain. DMARC yêu cầu domain xác thực phải aligned với Author Domain trong From. Ở chế độ relaxed, subdomain cùng organizational domain thường được coi là aligned; chế độ strict yêu cầu khớp chính xác hơn.

Ví dụ: thư hiển thị billing@example.com, DKIM pass với d=example.com thì đường DKIM aligned. Nếu SPF pass cho envelope domain của một nhà cung cấp không thuộc example.com, SPF có thể pass riêng nhưng không giúp DMARC pass. Nhà cung cấp cần hỗ trợ custom return-path hoặc DKIM ký bằng domain của doanh nghiệp.

5. Bản ghi DMARC và ba mức policy

_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

• p=none: theo dõi và nhận report, không yêu cầu xử lý thư fail.
• p=quarantine: đề nghị bên nhận đưa thư fail vào vùng nghi ngờ, thường là spam.
• p=reject: đề nghị từ chối thư fail DMARC.
• rua: nơi nhận aggregate report; mailbox phải được bảo vệ và đủ sức xử lý file XML nén.
• sp: policy dành cho subdomain khi cần khác domain gốc.

Năm 2026, DMARC core và reporting được chuẩn hóa trong RFC 9989, RFC 9990 và RFC 9991, thay thế đặc tả RFC 7489 cũ. Các triển khai legacy vẫn phổ biến, vì vậy đội vận hành cần kiểm tra khả năng tương thích của nhà cung cấp và công cụ phân tích report.

6. Lập inventory trước khi thay DNS

Nguồn gửi thường nhiều hơn dự kiến. Ngoài hệ thống email chính còn có CRM, helpdesk, hóa đơn, máy scan, ứng dụng web, HR, marketing automation, cảnh báo giám sát và nhà cung cấp thay mặt gửi thư. Mỗi nguồn cần một owner và quyết định kỹ thuật.

7. Lộ trình rollout an toàn

1. Kiểm kê domain, subdomain và mọi nguồn gửi.
2. Hợp nhất SPF; xác nhận lookup, cú pháp và kết quả thực tế.
3. Bật DKIM cho từng nền tảng, ưu tiên signing domain aligned.
4. Xuất bản DMARC ở chế độ quan sát và nhận aggregate report.
5. Theo dõi đủ chu kỳ kinh doanh: lương, hóa đơn tháng, chiến dịch và cảnh báo hiếm.
6. Sửa nguồn hợp lệ chưa aligned; loại bỏ dịch vụ không còn dùng.
7. Tăng enforcement từng bước, theo dõi bounce và ticket hỗ trợ.
8. Chỉ tiến tới reject khi luồng hợp lệ đã được nhận diện và owner chấp thuận.

8. Đọc aggregate report đúng cách

Aggregate report cho biết IP nguồn, lượng thư, kết quả SPF/DKIM, alignment và disposition theo từng nhóm. Nó giúp phát hiện shadow IT, cấu hình sai và nguồn giả mạo. Report không phải danh sách người nhận chi tiết và không tự kết luận mọi IP lạ là attacker.

Hãy nhóm theo source, domain ký, envelope domain và xu hướng theo thời gian. Một IP mới có volume nhỏ có thể là dịch vụ SaaS hợp lệ vừa được kích hoạt. Ngược lại, hàng nghìn thư fail từ nhiều quốc gia có thể là chiến dịch spoofing. Luôn đối chiếu với inventory và owner.

9. Những lỗi triển khai phổ biến

• Nhiều SPF record cho cùng domain, dẫn tới kết quả lỗi.
• Quên hệ thống gửi hiếm như cảnh báo thiết bị hoặc hóa đơn cuối tháng.
• DKIM pass nhưng d= thuộc domain nhà cung cấp, không aligned với From.
• Đăng public key sai selector hoặc xóa key cũ quá sớm.
• Dùng p=reject trước khi đọc report và sửa nguồn hợp lệ.
• Cho phép nhà cung cấp dùng From của domain chính nhưng không có quy trình offboarding.
• Đưa báo cáo vào mailbox không được giám sát hoặc bị đầy.
• Nhầm authentication với reputation: SPF/DKIM/DMARC pass không bảo đảm thư vào inbox.

10. Forwarding, mailing list và ARC

Forwarding có thể làm SPF fail; mailing list có thể sửa subject hoặc body làm DKIM fail. Một số hệ thống dùng ARC để truyền kết quả xác thực quan sát được qua chuỗi trung gian, nhưng receiver vẫn áp policy và mức tin cậy riêng. ARC không sửa cấu hình SPF, DKIM hay DMARC của sender.

Khi doanh nghiệp vận hành mailing list hoặc gateway, hãy test với các mailbox lớn, bảo toàn DKIM khi có thể và tránh rewrite không cần thiết. Với luồng phức tạp, theo dõi Authentication-Results trên message mẫu là cách chẩn đoán thực tế.

11. Vận hành lâu dài

• Gắn owner và ngày review cho từng nguồn gửi.
• Rotate DKIM key theo chính sách, dùng selector mới thay vì ghi đè mù quáng.
• Giám sát SPF lookup, DNS error và tỷ lệ DMARC pass/alignment.
• Review nhà cung cấp mới trước khi họ gửi bằng domain doanh nghiệp.
• Tách subdomain cho marketing hoặc hệ thống rủi ro cao khi phù hợp.
• Duy trì quy trình thu hồi quyền gửi khi kết thúc hợp đồng.
• Kết hợp TLS, reverse DNS, unsubscribe và kiểm soát spam/reputation.

Checklist trước khi enforcement

• Chỉ có một SPF record hợp lệ và mọi include đều cần thiết.
• Mỗi nguồn quan trọng có ít nhất một đường DMARC aligned.
• DKIM private key được bảo vệ và có kế hoạch rotate.
• Aggregate report được phân tích liên tục, không chỉ lưu trữ.
• Đã kiểm thử forwarding, mailing list và các SaaS quan trọng.
• Có rollback plan, owner và kênh nhận sự cố gửi mail.
• Domain không gửi mail cũng có policy phù hợp để giảm spoofing.

Tài liệu tham khảo

• RFC 7208: Sender Policy Framework
• RFC 6376: DKIM Signatures
• RFC 9989: DMARC
• RFC 9990: DMARC Aggregate Reporting
• Google: Email sender guidelines

Kết luận

SPF công bố nguồn gửi, DKIM gắn chữ ký với thông điệp và DMARC buộc kết quả xác thực liên kết với domain người nhận nhìn thấy. Giá trị thật đến từ quy trình: inventory đầy đủ, alignment đúng, report được đọc và enforcement tăng có kiểm soát. Khi được vận hành như một chương trình liên tục thay vì dự án DNS một lần, bộ ba này giảm giả mạo domain mà không hy sinh luồng email hợp lệ.