SPF, DKIM, DMARC là gì? Cách cài 3 bản ghi xác thực email cho tên miền

SPF, DKIM, DMARC là gì

Giao thức email ra đời từ thời chưa ai nghĩ đến giả mạo, nên bất kỳ máy chủ nào cũng có thể ghi “người gửi: tin@onic.vn” lên một lá thư. Ba bản ghi xác thực sinh ra để vá lỗ hổng đó. Chúng nằm trong DNS của tên miền, nơi chỉ chủ tên miền mới sửa được, nên hộp thư nhận có thể tra cứu và tin vào câu trả lời.

SPF (Sender Policy Framework) là danh sách máy chủ được phép gửi thư thay tên miền. Khi thư đến, hộp thư nhận xem máy chủ gửi có nằm trong danh sách không. DKIM (DomainKeys Identified Mail) là chữ ký số: máy chủ gửi ký lên thư bằng khóa bí mật, hộp thư nhận lấy khóa công khai trong DNS để kiểm chữ ký, nhờ đó biết thư không bị sửa trên đường đi. DMARC (Domain-based Message Authentication, Reporting and Conformance) đứng trên hai bản ghi kia, yêu cầu tên miền đã qua SPF hoặc DKIM phải khớp với tên miền ở địa chỉ người gửi mà khách nhìn thấy.

Ba bản ghi này là phần xác thực trong bài toán lớn hơn: làm sao để chuỗi email tự động của shop thật sự đến được hộp thư khách. Thiếu chúng, email chào mừng hay email nhắc giỏ hàng gửi đúng lúc đến đâu cũng có thể nằm trong thư mục rác.

Ba bản ghi phối hợp với nhau thế nào

Hộp thư nhận kiểm tra lần lượt. Thư đến, nó tra SPF để xem máy chủ gửi có hợp lệ, kiểm chữ ký DKIM, rồi đọc DMARC để biết cần ít nhất một trong hai kết quả trên khớp với tên miền người gửi. Thư đạt thì tiếp tục qua các bộ lọc uy tín và nội dung; thư không đạt thì bị xử lý theo chính sách DMARC.

Điểm hay bị hiểu sai là DMARC không đòi cả SPF lẫn DKIM cùng đạt. Chỉ cần một trong hai đạt và khớp tên miền là DMARC đạt. Tuy vậy SPF dễ gãy khi thư bị chuyển tiếp, còn DKIM giữ được chữ ký qua chuyển tiếp, nên tôi luôn cài đủ cả hai để có đường dự phòng.

Vì sao Gmail, Yahoo, Outlook bắt buộc xác thực

Tháng 10/2023, Google và Yahoo cùng công bố yêu cầu mới cho người gửi, áp dụng từ tháng 2/2024. Theo hướng dẫn dành cho người gửi email của Google, mọi người gửi tới Gmail phải có SPF hoặc DKIM; người gửi trên 5.000 thư mỗi ngày phải có cả SPF, DKIM và DMARC tối thiểu ở chính sách none, kèm hủy đăng ký một chạm và tỷ lệ báo spam thấp. Từ tháng 11/2025, Gmail tăng mức xử lý với thư không đạt, từ làm chậm đến từ chối thư (Red Sift, 14/11/2025).

Microsoft áp dụng yêu cầu tương tự cho Outlook.com, Hotmail và Live.com từ ngày 5/5/2025 với tên miền gửi trên 5.000 thư mỗi ngày (Microsoft Tech Community, cập nhật 29/04/2025). Shop nhỏ chưa tới mốc 5.000 thư vẫn nên cài đủ ba bản ghi, vì thư đã xác thực luôn được tin hơn thư chưa xác thực, và một ngày gửi chiến dịch lớn có thể vượt mốc lúc nào không hay.

Phần cơ bản: cài 3 bản ghi cho tên miền

Mọi thao tác làm trong trang quản lý DNS ở nơi anh em mua tên miền, hoặc nơi đang trỏ nameserver. Trước khi bắt đầu, liệt kê tất cả dịch vụ đang gửi email bằng tên miền: hộp thư công ty, hosting gửi email của website, nền tảng gửi bản tin.

Thêm bản ghi SPF

Tạo một bản ghi TXT tại tên miền gốc (ô tên để trống hoặc ghi @). Giá trị bắt đầu bằng v=spf1, tiếp theo là các dịch vụ được phép gửi, kết thúc bằng ~all hoặc -all. Mỗi dịch vụ gửi email đều ghi rõ phần include cần thêm trong trang hướng dẫn của họ.

Loại: TXT
Tên: @
Giá trị: v=spf1 ip4:[IP máy chủ hosting] include:[SPF của dịch vụ email] include:[SPF của nền tảng gửi bản tin] ~all
Ví dụ với Google Workspace:
v=spf1 include:_spf.google.com ~all

Bật DKIM ở dịch vụ gửi

DKIM không tự gõ được, vì khóa do dịch vụ gửi email tạo ra. Vào phần quản trị của dịch vụ (email hosting, Google Workspace, Microsoft 365, nền tảng gửi bản tin), tìm mục DKIM hoặc xác thực tên miền, tạo khóa rồi sao chép tên và giá trị bản ghi sang DNS. Mỗi dịch vụ gửi có khóa DKIM riêng với selector riêng, nên ba dịch vụ là ba bản ghi DKIM.

Loại: TXT
Tên: [selector]._domainkey   (ví dụ: google._domainkey, default._domainkey)
Giá trị: v=DKIM1; k=rsa; p=[khóa công khai dài do dịch vụ cấp]

Thêm DMARC ở chính sách none

Tạo bản ghi TXT tại _dmarc. Lúc mới cài, đặt p=none: hộp thư chỉ theo dõi, chưa chặn thư nào, và gửi báo cáo tổng hợp về địa chỉ ở phần rua. Nên dùng một hộp thư riêng để nhận báo cáo, vì mỗi ngày có thể có nhiều báo cáo từ các nhà cung cấp hộp thư.

Loại: TXT
Tên: _dmarc
Giá trị: v=DMARC1; p=none; rua=mailto:dmarc@[tên miền]; adkim=r; aspf=r

Phần nâng cao: báo cáo DMARC và nâng chính sách

Cài xong ba bản ghi mới là nửa chặng. Nửa còn lại là đọc báo cáo để biết thư nào đang gửi bằng tên miền của mình, rồi siết chính sách để chặn thư giả mạo.

Đọc báo cáo DMARC

Báo cáo tổng hợp là file XML gửi về địa chỉ rua, liệt kê các máy chủ đã gửi thư bằng tên miền và kết quả SPF, DKIM của từng nguồn. File XML khó đọc bằng mắt, nên anh em dùng các công cụ đọc báo cáo DMARC có gói miễn phí để xem dạng bảng. Việc cần làm là tìm nguồn hợp lệ nhưng đang trượt, ví dụ phần mềm hóa đơn gửi thư mà chưa có trong SPF, và bổ sung trước khi siết chính sách.

Nâng chính sách từ none lên quarantine rồi reject

Khi báo cáo cho thấy mọi nguồn hợp lệ đều đạt, nâng chính sách theo từng bậc. Mỗi bậc giữ vài tuần và đọc báo cáo trước khi lên bậc sau.

Tên miền dùng nhiều dịch vụ gửi

Một shop thường có hộp thư công ty, website WooCommerce gửi email đơn hàng và một nền tảng gửi bản tin. SPF gộp cả ba vào một bản ghi, nhưng giới hạn 10 lượt tra cứu DNS, mỗi include tính ít nhất một lượt. Khi gần chạm giới hạn, có hai cách: bỏ các dịch vụ không còn dùng, hoặc cho nền tảng bản tin gửi từ một tên miền con như news.[tên miền] với SPF và DKIM riêng.

Cách kiểm tra 3 bản ghi đã hoạt động

Bản ghi DNS thường có hiệu lực sau vài phút đến vài giờ, tùy thời gian lưu đệm (TTL), có trường hợp tới 48 giờ. Sau đó kiểm tra theo hai cách. Cách thứ nhất là gửi một email thử tới mail-tester.com, trang sẽ báo SPF, DKIM, DMARC có hợp lệ không. Cách thứ hai là gửi tới Gmail của mình, mở thư, bấm dấu ba chấm, chọn “Hiển thị bản gốc” và xem ba dòng SPF, DKIM, DMARC đều ghi PASS.

Nếu dòng SPF ghi FAIL, máy chủ gửi chưa có trong bản ghi hoặc có hai bản ghi SPF. Nếu DKIM ghi FAIL, thường là chưa bật ký DKIM ở dịch vụ gửi hoặc dán thiếu khóa. Nếu DMARC FAIL dù SPF và DKIM đều PASS, nghĩa là chúng đạt cho một tên miền khác chứ không khớp tên miền người gửi; thường gặp khi website gửi qua máy chủ của hosting mà chưa cấu hình gửi bằng tên miền riêng. Khi cả ba đã PASS mà thư vẫn vào hộp thư rác, nguyên nhân nằm ở uy tín và danh sách, phần này có trong bài email vào spam.

Ví dụ thực tế: Onic xác thực tên miền onic.vn

Tên miền onic.vn mua ở Mắt Bão, website chạy trên hosting iNET. Email của website gồm thư đơn hàng WooCommerce, thư đặt lại mật khẩu và bản tin, tất cả đi qua WP Mail SMTP bằng địa chỉ tin@onic.vn. Onic làm theo đúng thứ tự trong bài.

Đầu tiên Onic liệt kê nguồn gửi: dịch vụ email của tên miền và máy chủ SMTP mà website dùng. Bản ghi SPF được gộp thành một dòng TXT duy nhất trong trang quản lý DNS ở Mắt Bão. Tiếp theo Onic lấy khóa DKIM trong trang quản trị của dịch vụ email, dán vào bản ghi _domainkey tương ứng. Cuối cùng là bản ghi _dmarc với chính sách none và địa chỉ nhận báo cáo riêng.

Sau khi bản ghi có hiệu lực, Onic vào Công cụ, Kiểm tra Email của WP Mail SMTP, gửi một email thử tới địa chỉ mail-tester và tới Gmail, rồi mở “Hiển thị bản gốc” để chắc ba dòng đều PASS. Đây cũng là cách Onic làm mọi việc kỹ thuật: kiểm tra trước, kiểm tra sau, giống cách công cụ seo tự động của Onic kiểm tra bài trước khi đưa vào bản nháp cho người duyệt.

Tiêu chuẩn biên tập nội dung tại Onic.vn (E-E-A-T)

Các bài kiến thức và hướng dẫn trên Onic.vn được viết theo bộ Brand Context do Hồ Đình Thắng trực tiếp thiết lập, và luôn qua kiểm duyệt con người (human-in-the-loop) trước khi xuất bản.

• Nội dung dựa trên kinh nghiệm thực chiến (Experience) và số liệu xác minh được (Ahrefs, Google Analytics, Google Search Console), không phóng đại kết quả hay hứa hẹn “chắc chắn lên Top”.
• Chuyên môn (Expertise) đến từ 14+ năm hành nghề liên tục và 4 sản phẩm AI SEO tự tay xây dựng, không phải kiến thức lý thuyết sao chép.
• Tính thẩm quyền (Authoritativeness) thể hiện qua vai trò founder duy nhất đứng sau toàn bộ hệ sinh thái Onic.vn, một thực thể nhất quán, không rời rạc.
• Độ tin cậy (Trustworthiness) được đảm bảo bằng thông tin liên hệ thật, hồ sơ công khai, số liệu có nguồn xác minh và minh bạch về giới hạn (phần nào AI hỗ trợ, phần nào cần con người quyết định).
• Mọi bài viết được đối chiếu với dữ liệu chính thức trên onic.vn/huong-dan trước khi xuất bản, tránh trùng lặp intent, và được cập nhật khi có thay đổi về tính năng hoặc dữ liệu GSC.

Câu hỏi thường gặp