Tạo Bản Ghi SPF Online

Bản Ghi SPF Là Gì?

Bản ghi SPF (Sender Policy Framework, RFC 7208) là một bản ghi TXT trên tên miền của bạn, liệt kê các máy chủ được phép gửi email thay cho tên miền đó. Khi thư đến, máy chủ nhận tra cứu bản ghi SPF của tên miền người gửi phong bì (Return-Path, không phải địa chỉ From hiển thị) và kiểm tra xem IP gửi có nằm trong danh sách hay không.

Một tên miền chỉ được có một bản ghi SPF. Hai bản ghi cùng bắt đầu bằng v=spf1 khiến mọi lần kiểm tra SPF đều thất bại với PermError, vì vậy khi thêm dịch vụ mới, bạn sửa bản ghi hiện có thay vì thêm bản ghi khác. Từ tháng 2 năm 2024, Gmail và Yahoo yêu cầu mọi người gửi dùng SPF hoặc DKIM, còn người gửi số lượng lớn phải dùng đồng thời SPF, DKIM và DMARC.

Cách Tạo Bản Ghi SPF

Giải Thích Cú Pháp Bản Ghi SPF

Bản ghi SPF là danh sách các thành phần (term) được đọc từ trái sang phải. Thành phần đầu tiên khớp với IP gửi sẽ quyết định kết quả.

~all và -all: Soft Fail Hay Fail?

-all cho máy chủ nhận biết thư từ bất kỳ máy chủ nào không có trong danh sách sẽ fail SPF, và nhiều máy chủ sẽ từ chối thư đó. ~all đánh dấu thư là soft fail: máy chủ nhận không nên từ chối thư chỉ vì lý do này, nhưng có thể coi nó là đáng ngờ. ?all là trung lập (neutral) và không mang lại sự bảo vệ nào.

Hướng dẫn của Google cho Workspace dùng ~all, còn ví dụ của Microsoft cho Microsoft 365 dùng -all. Cả hai đều hoạt động. Khi bạn đã công bố DMARC, chính sách DMARC (p=quarantine hoặc p=reject) sẽ quyết định cách xử lý thư không đạt, nên nhiều tên miền giữ ~all để tránh từ chối thư chuyển tiếp hợp lệ và để DMARC lo việc thực thi. Nếu tên miền hoàn toàn không gửi email, hãy công bố v=spf1 -all.

Ví Dụ Bản Ghi SPF

Sao chép mẫu gần nhất với cấu hình của bạn, hoặc tự tạo bằng công cụ ở trên. Mỗi mẫu là một bản ghi TXT duy nhất tại tên miền của bạn.

Giới Hạn 10 Lần Tra Cứu DNS

RFC 7208 giới hạn mỗi lần kiểm tra SPF ở 10 lần tra cứu DNS. Mỗi include, a, mx, ptr, exists và redirect tốn một lần, và mọi cơ chế như vậy bên trong các bản ghi bạn include cũng thế. ip4, ip6 và all thì không tốn lần nào. Một lần kiểm tra cần đến lần tra cứu thứ 11 sẽ dừng lại với PermError, và DMARC coi đó là SPF thất bại. Máy chủ nhận cũng chỉ nên cho phép tối đa 2 void lookup (tên không tồn tại hoặc không trả về bản ghi nào).

Không phải nhà cung cấp nào cũng tốn như nhau. Chúng tôi đã đếm từng include vào ngày 5 tháng 10 năm 2026, tính cả các lần tra cứu lồng nhau:

Cách Sửa Bản Ghi SPF Có Quá Nhiều Lần Tra Cứu

• Gỡ các dịch vụ bạn không còn dùng. Công cụ gửi bản tin cũ và các tài khoản dùng thử thường là thủ phạm.

• Thay `a` và `mx` bằng `ip4`/`ip6` khi máy chủ riêng của bạn có địa chỉ cố định.

• Chuyển thư gửi hàng loạt sang subdomain như news.example.com, với bản ghi SPF riêng và 10 lần tra cứu riêng.

• Kiểm tra xem dịch vụ có thực sự cần include không. Nhiều dịch vụ gửi dùng tên miền bounce của riêng họ, nên SPF đạt trên tên miền của họ và DMARC alignment đến từ DKIM.

• Cẩn thận với SPF flattening. Thay include bằng danh sách IP sao chép sẵn chỉ hoạt động cho đến khi nhà cung cấp đổi IP, sau đó thư bắt đầu thất bại mà không có cảnh báo nào.

Các Lỗi SPF Thường Gặp

• Hai bản ghi SPF trên cùng một tên miền, ví dụ mỗi nhà cung cấp một bản ghi. Hãy gộp chúng thành một.

• Dùng +all, tức là cấp quyền cho toàn bộ internet.

• Công bố bản ghi sai tên. SPF được kiểm tra trên tên miền người gửi phong bì, và subdomain không kế thừa bản ghi đó.

• Thêm cơ chế phía sau all. Máy chủ nhận không bao giờ đánh giá chúng, nên các nguồn gửi đó không được cấp quyền.

• Quên một nguồn gửi, chẳng hạn web server gửi thư từ biểu mẫu liên hệ.

• Dùng loại bản ghi SPF cũ (type 99). RFC 7208 đã ngừng sử dụng nó: chỉ công bố bản ghi TXT.

SPF, DKIM và DMARC Hoạt Động Cùng Nhau

Riêng SPF không ngăn được ai đó giả mạo địa chỉ From mà người đọc nhìn thấy. DKIM ký từng thư, còn DMARC gắn cả hai với tên miền From hiển thị và cho máy chủ nhận biết phải làm gì khi chúng thất bại. Hãy thiết lập cả ba: