Bạn gửi email từ địa chỉ tên miền công ty nhưng khách hàng không thấy gì, hoặc email nằm chờ trong thư mục spam của họ. Một trong những nguyên nhân phổ biến nhất là tên miền chưa khai báo SPF đúng cách. SPF là bản ghi DNS cho phép máy chủ nhận email biết ai được phép gửi thư nhân danh tên miền của bạn. Thiếu nó, ngay cả email thật của bạn cũng có thể bị máy chủ đích nghi ngờ.
SPF là gì, dùng để xác thực điều gì
SPF (Sender Policy Framework, khung chính sách người gửi) là một chuẩn xác thực email, được mô tả trong RFC 7208. Nguyên lý của nó khá đơn giản: bạn tạo một bản ghi TXT trong DNS của tên miền, liệt kê danh sách các máy chủ mail được phép gửi email từ tên miền đó.
Khi ai đó nhận email có địa chỉ gửi là [email protected], máy chủ email của họ sẽ tra bản ghi SPF của congty.vn để kiểm tra máy chủ vừa gửi thư có trong danh sách cho phép không.
SPF ra đời để giải quyết một lỗ hổng lâu đời của giao thức SMTP (Simple Mail Transfer Protocol, giao thức truyền email): SMTP nguyên bản không có cơ chế xác minh người gửi. Về kỹ thuật, bất kỳ ai cũng có thể gửi email với địa chỉ người gửi là tên miền của người khác mà không cần sự cho phép nào. SPF là lớp đầu tiên ngăn chặn hành vi này bằng cách công khai danh sách nguồn hợp lệ.
Bạn sẽ gặp SPF ngay khi kết nối tên miền công ty với Google Workspace, Microsoft 365, hay bất kỳ dịch vụ email tên miền nào. Nhà cung cấp sẽ yêu cầu thêm một bản ghi TXT vào DNS của tên miền, và đó chính là bản ghi SPF. (Nếu bạn chưa rõ bản ghi DNS là gì và cách thêm vào, xem trước bài DNS là gì và các loại bản ghi phổ biến sẽ giúp nhiều hơn.)
SPF hoạt động ra sao khi một email được gửi đi
Khi bạn ấn gửi, email đi qua chuỗi kiểm tra sau. Hiểu đúng luồng này sẽ giúp bạn biết SPF can thiệp ở điểm nào và vì sao nó không phải giải pháp duy nhất cần có.
- Email rời khỏi máy chủ gửi với một địa chỉ IP nguồn cụ thể
- Máy chủ nhận email đọc địa chỉ Return-Path của email đó (còn gọi là envelope sender hoặc MAIL FROM, khác với địa chỉ “From” bạn nhìn thấy trong hộp thư)
- Máy chủ nhận tra bản ghi SPF của tên miền trong Return-Path qua DNS
- So sánh IP đang gửi với danh sách cho phép trong bản ghi SPF
- Trả về kết quả rồi quyết định: nhận, từ chối, hoặc đánh dấu nghi ngờ
Điểm mấu chốt: SPF kiểm tra địa chỉ Return-Path, không phải địa chỉ “From” người dùng nhìn thấy. Đây là lý do SPF bị vô hiệu khi email bị chuyển tiếp (forward), lúc đó Return-Path thay đổi thành địa chỉ của người chuyển tiếp, còn IP gửi cũng khác, khiến SPF của người gửi gốc fail dù email hoàn toàn hợp lệ.
Đây cũng là lý do SPF không đứng một mình. DKIM được tạo ra để bổ sung cho đúng chỗ SPF yếu, và DMARC điều phối kết quả của cả hai. Bộ ba này không phải lựa chọn, mà là quy trình tuần tự.
Bản ghi SPF thật trông như thế nào và đọc ra sao
Bản ghi SPF là một bản ghi TXT trong DNS của tên miền. Một ví dụ thực tế cho tên miền dùng Google Workspace:
v=spf1 include:_spf.google.com ~allGiải mã từng thành phần:
- v=spf1: khai báo đây là bản ghi SPF phiên bản 1, bắt buộc phải có ở đầu
- include:_spf.google.com: cho phép tất cả máy chủ có trong danh sách SPF của Google gửi email nhân danh tên miền này
- ~all: với IP không có trong danh sách, áp dụng SoftFail, nhận email nhưng đánh dấu nghi ngờ
Nếu công ty vừa dùng Google Workspace vừa dùng thêm dịch vụ gửi email marketing như SendGrid hay Mailchimp, cần khai báo cả hai trong một bản ghi duy nhất:
v=spf1 include:_spf.google.com include:sendgrid.net ~allBảng dưới đây tóm tắt các giá trị của phần all và ý nghĩa thực tế:
| Giá trị | Ký hiệu | Ý nghĩa khi không khớp | Khi nào dùng |
|---|---|---|---|
| SoftFail | ~all | Nhận nhưng đánh dấu nghi ngờ | Khi chưa chắc đã khai báo hết nguồn gửi; dùng để thử nghiệm |
| Fail (hard fail) | -all | Từ chối hoàn toàn | Khi đã xác nhận danh sách nguồn gửi đầy đủ và ổn định |
| Neutral | ?all | Không có hành động, để server nhận tự quyết | Hiếm dùng trong thực tế |
| Pass | +all | Cho phép mọi IP gửi email | Không bao giờ dùng, vô nghĩa về bảo mật |
Một giới hạn cần biết: SPF chỉ cho phép tối đa 10 lần tra DNS khi xử lý bản ghi. Khai báo quá nhiều include:, mỗi cái lại trỏ sang nhiều domain khác, số lần tra vượt 10 thì SPF trả về PermError và bị xem như không hợp lệ. Đây là lỗi hay gặp ở công ty dùng nhiều dịch vụ email cùng lúc (email nội bộ, email marketing, email transactional từ website).
SPF một mình chưa đủ, nó đứng ở đâu trong bộ ba xác thực email
SPF xác nhận máy chủ gửi có được ủy quyền không, nhưng không bảo vệ được nội dung email khỏi bị chỉnh sửa trên đường đi. Nó cũng không ngăn được kẻ giả mạo dùng địa chỉ From hợp lệ kết hợp Return-Path khác. Đây là lý do bộ ba ra đời:
| Chuẩn | Kiểm tra cái gì | Điểm mạnh | Điểm yếu |
|---|---|---|---|
| SPF | Máy chủ gửi có được ủy quyền không | Triển khai đơn giản, không cần thay đổi ở phía gửi | Fail khi email forward; chỉ kiểm tra Return-Path |
| DKIM | Nội dung email có bị sửa không | Bảo toàn qua forward; ký số từng email | Không biết IP nào được phép gửi |
| DMARC | Điều phối SPF và DKIM; quyết định xử lý email fail | Báo cáo tập trung; chính sách rõ ràng cho người nhận | Cần SPF và DKIM đã chạy trước mới hoạt động được |
Khi đã khai báo SPF xong, bước tiếp theo là thêm DKIM để ký số nội dung email, sau đó mới đến DMARC để thiết lập chính sách xử lý email fail và nhận báo cáo. Đây là thứ tự chuẩn, không thể bỏ bước.
Một xu hướng đáng chú ý: từ đầu năm 2024, Google và Yahoo Mail yêu cầu tất cả người gửi email hàng loạt phải có đủ SPF, DKIM, và DMARC. Tên miền thiếu bất kỳ cái nào sẽ thấy tỷ lệ email vào hộp thư chính giảm đáng kể, nhất là với danh sách lớn.
Câu hỏi thường gặp về SPF
SPF có ngăn chặn hoàn toàn email giả mạo không?
Không. SPF giảm đáng kể nguy cơ nhưng không bịt được mọi hướng tấn công. Kẻ giả mạo vẫn có thể dùng địa chỉ From hiển thị khác với Return-Path mà SPF kiểm tra. DMARC ra đời để vá lỗ hổng này, bằng cách đối chiếu cả SPF và DKIM với tên miền trong địa chỉ From thực sự.
Một tên miền có thể có nhiều bản ghi SPF không?
Không. Mỗi tên miền chỉ được có một bản ghi SPF duy nhất. Nếu cần khai báo nhiều nguồn gửi email, gộp tất cả vào một bản ghi bằng nhiều include: hoặc nhiều ip4:.
Tôi đã có SPF nhưng email vẫn vào spam, vì sao?
SPF chỉ là một trong nhiều tín hiệu mà bộ lọc spam dùng để đánh giá. Nội dung email, IP reputation, tỷ lệ bị đánh dấu spam, bounce rate, cài đặt DKIM và DMARC đều tác động. Có SPF giảm rủi ro nhưng không đảm bảo email chắc chắn vào hộp thư chính.
Làm sao kiểm tra bản ghi SPF hiện tại của tên miền?
Dùng công cụ MXToolbox SPF Checker tại mxtoolbox.com/spf.aspx, nhập tên miền, công cụ hiển thị bản ghi SPF đang khai báo, kiểm tra cú pháp và đếm số DNS lookup. Đây là cách nhanh nhất để kiểm tra mà không cần truy cập vào bảng quản lý DNS của nhà cung cấp.
Chuyển email sang dịch vụ khác có cần cập nhật SPF không?
Có, và đây là lỗi hay bị bỏ quên. Khi chuyển từ nhà cung cấp email này sang nhà cung cấp khác, cần cập nhật bản ghi SPF để phản ánh đúng máy chủ mới đang dùng. Giữ nguyên bản ghi SPF cũ sẽ khiến email từ dịch vụ mới bị fail SPF.
SPF là bước đầu và cũng là bước đơn giản nhất trong chuỗi xác thực email. Khi đã có SPF đúng cú pháp và ổn định, tiếp tục với DKIM rồi DMARC để hoàn thiện bộ ba. Nếu bạn đang trong giai đoạn đầu tìm hiểu hạ tầng tên miền và email, xem thêm bài tên miền là gì và những thứ cần biết khi mới bắt đầu.