Bạn đã đặt email theo tên miền riêng, ví dụ ten@congty.vn. Nhưng ai cũng có thể gõ địa chỉ đó vào trường “người gửi” của một email giả. Không có biện pháp nào, thư giả mạo có thể đến tay khách hàng của bạn trong khi trông như do công ty gửi. SPF là một lớp bảo vệ cơ bản, miễn phí và đủ đơn giản để doanh nghiệp nhỏ tự làm với sự hỗ trợ của nhà cung cấp tên miền.
Giả mạo người gửi là gì
Giao thức gửi email cũ không bắt buộc kiểm tra người gửi có thật sự thuộc tên miền đó hay không. Kẻ xấu lợi dụng điều này để gửi thư lừa đảo mạo danh một công ty, chẳng hạn gửi “hoá đơn” hay yêu cầu đổi số tài khoản. Hậu quả là uy tín tên miền bị ảnh hưởng, và thư thật của bạn cũng có thể bị đưa vào hộp thư rác. Bài Email lừa đảo (phishing): 7 dấu hiệu để nhận ra mô tả cách người nhận phát hiện loại thư này, còn SPF là việc bạn làm ở phía người gửi.
SPF làm việc thế nào
SPF (Sender Policy Framework), được mô tả trong tài liệu chuẩn RFC 7208, là một bản ghi TXT trong DNS của tên miền. Chủ tên miền liệt kê những máy chủ được phép gửi email dưới tên miền của mình. Khi nhận được thư, máy chủ nhận tra bản ghi này và so địa chỉ IP của máy chủ gửi với danh sách. Nếu không khớp, thư có thể bị đánh dấu nghi ngờ hoặc bị từ chối.
Một điểm dễ hiểu sai: theo RFC, SPF kiểm tra địa chỉ người gửi trong phiên chuyển thư (thường gọi là MAIL FROM) và tên HELO, không kiểm tra trực tiếp địa chỉ “From” mà người đọc nhìn thấy. Vì thế SPF là một mảnh trong bộ xác thực, không phải biện pháp duy nhất. Các lớp bổ sung như DKIM và DMARC sẽ được nhắc ở phần sau của chuỗi bài.
Bản ghi SPF viết thế nào
Bản ghi bắt đầu bằng `v=spf1`, tiếp theo là các thành phần (cơ chế) và kết thúc bằng một quy tắc mặc định. Các cơ chế thường gặp:
| Thành phần | Ý nghĩa |
|---|---|
| `ip4:` | Cho phép một địa chỉ hoặc dải IPv4 |
| `mx` | Cho phép các máy chủ nhận thư (MX) của tên miền |
| `a` | Cho phép địa chỉ của tên miền |
| `include:` | Dùng danh sách của bên khác, ví dụ dịch vụ email bạn thuê |
| `all` | Áp dụng cho mọi trường hợp còn lại, đặt ở cuối |
Phía trước mỗi thành phần có thể có ký hiệu: `+` (cho phép, là mặc định), `-` (từ chối), `~` (cho qua nhưng nghi ngờ, softfail), `?` (trung lập).
Ví dụ trong hướng dẫn của Google khi bạn chỉ gửi thư bằng Google Workspace:
“` v=spf1 include:_spf.google.com ~all “`
Nếu dùng thêm một dịch vụ khác, thêm `include:` tương ứng vào cùng bản ghi. Mỗi nhà cung cấp email sẽ có đoạn `include:` riêng, nên hãy lấy từ trang hướng dẫn chính thức của họ. Google khuyến nghị dùng `~all`. Mức `-all` nghiêm ngặt hơn, nhưng dễ chặn nhầm thư thật nếu bạn quên khai báo một nguồn gửi, nên chỉ nên dùng khi bạn đã liệt kê đủ.
Bản ghi đặt ở tên miền gốc (ký hiệu @). Hướng dẫn của Google lưu ý tên miền phụ cần bản ghi SPF riêng. Sau khi thêm, DNS có thể cần đến khoảng 48 giờ mới có hiệu lực.
Lỗi hay gặp: gộp nhiều SPF
Một tên miền chỉ nên có đúng một bản ghi SPF. Theo RFC 7208, nếu tìm thấy nhiều hơn một bản ghi bắt đầu bằng `v=spf1`, kết quả là lỗi và SPF coi như không hợp lệ. Lỗi này thường xảy ra khi bạn thêm một dịch vụ mới (hệ thống bán hàng, bản tin, CRM) và tạo thêm một dòng TXT thay vì sửa dòng cũ.
Cách làm đúng là gộp mọi nguồn gửi vào một bản ghi:
“` v=spf1 include:_spf.google.com include:dich-vu-khac.example ~all “`
(`dich-vu-khac.example` chỉ là tên minh hoạ.)
Một giới hạn khác: RFC cho phép tối đa 10 lần tra cứu DNS trong một lần đánh giá (các thành phần như `include`, `a`, `mx`). Quá giới hạn sẽ gây lỗi. Vì vậy đừng “include” mọi dịch vụ mà bạn từng thử.
Kiểm tra bằng công cụ
- Dùng công cụ tra bản ghi TXT miễn phí để xem tên miền đã có SPF chưa và có đúng một bản ghi không.
- Gửi thư thử từ mọi nguồn gửi thật (hộp thư công ty, hệ thống bán hàng, phần mềm bản tin) tới một hộp thư Gmail, rồi xem phần “Hiển thị bản gốc” để biết SPF đạt hay không.
- Sau khi thêm dịch vụ gửi mới, kiểm tra lại.
- Nhờ nhà cung cấp tên miền hoặc người quản trị hỗ trợ nếu không chắc.
Việc đặt tên miền riêng cho email là bước trước đó, đã được nói trong bài Email theo tên miền riêng cho doanh nghiệp. Dữ liệu khách hàng nhận thư cũng cần được bảo vệ, như đã đề cập trong Cambridge Analytica và quyền riêng tư trong quảng cáo. Nếu cần hỗ trợ cấu hình tên miền và bảo mật, có thể liên hệ đội Công nghệ của HVSC qua trang tên miền hoặc bảo mật server và website.
Cập nhật 2026: Cùng với SPF, nhiều nhà cung cấp hộp thư lớn nay đòi hỏi thêm DKIM và DMARC khi gửi số lượng lớn. Xem DMARC cho doanh nghiệp: bắt đầu ở chế độ giám sát và Email an toàn cho doanh nghiệp 2026: SPF, DKIM, DMARC và kiểm tra định kỳ. Nên kiểm tra hướng dẫn chính thức của nhà cung cấp email của bạn, vì khuyến nghị cụ thể có thể thay đổi.
Câu hỏi thường gặp
SPF có chặn hết thư giả mạo không?
Không. SPF kiểm tra địa chỉ gửi trong phiên chuyển thư, không phải mọi dạng giả mạo, nên cần kết hợp thêm các biện pháp khác như DKIM và DMARC.
Có được tạo nhiều bản ghi SPF không?
Không nên. Một tên miền chỉ nên có một bản ghi SPF; nếu có nhiều bản ghi, kết quả kiểm tra sẽ lỗi. Hãy gộp tất cả nguồn gửi vào một bản ghi.
Nên dùng ~all hay -all?
Google khuyến nghị `~all` cho cấu hình thông thường. Mức `-all` chặt hơn nhưng chỉ nên dùng khi chắc chắn đã khai báo đủ mọi nguồn gửi thư.
Nguồn tham khảo
- IETF — RFC 7208, Sender Policy Framework (SPF) — https://www.rfc-editor.org/rfc/rfc7208
- Google Workspace — Thiết lập SPF — https://knowledge.workspace.google.com/admin/security/set-up-spf
Cần tư vấn website, phần mềm hoặc bảo mật?
Mô tả bài toán, kỹ thuật HVSC trao đổi phạm vi và phương án phù hợp với doanh nghiệp.
Câu hỏi thường gặp
SPF có chặn hết thư giả mạo không?
Không. SPF kiểm tra địa chỉ gửi trong phiên chuyển thư, không phải mọi dạng giả mạo, nên cần kết hợp thêm các biện pháp khác như DKIM và DMARC.
Có được tạo nhiều bản ghi SPF không?
Không nên. Một tên miền chỉ nên có một bản ghi SPF; nếu có nhiều bản ghi, kết quả kiểm tra sẽ lỗi. Hãy gộp tất cả nguồn gửi vào một bản ghi.
Nên dùng ~all hay -all?
Google khuyến nghị `~all` cho cấu hình thông thường. Mức `-all` chặt hơn nhưng chỉ nên dùng khi chắc chắn đã khai báo đủ mọi nguồn gửi thư.
▶
▶
▶
▶
▶