Công cụ phổ biến

Giao diện

Kiểm Tra SPF — Xác Minh Bản Ghi SPF Online

Check SPF cho bất kỳ tên miền nào giống cách máy chủ thư nhận làm: mỗi include với chi phí tra cứu DNS riêng, tổng đang chạy so với giới hạn 10, các lượt tra cứu rỗng, và kết quả cho mọi IP gửi, kèm term đã quyết định nó.

Nguồn: các bản ghi TXT của tên miền và mọi include, qua Google Public DNS (phía sau là Cloudflare 1.1.1.1) · check_host theo RFC 7208, chạy trên máy chủ của chúng tôi · không lưu gì

Đúng tên bạn nhập: SPF không có kế thừa, nên mail.example.com cần bản ghi riêng.

Thử

Bản ghi SPF là gì?

Bản ghi SPF là một bản ghi TXT liệt kê các máy chủ được phép gửi thư cho một tên miền. Nó bắt đầu bằng v=spf1, rồi nêu từng máy chủ gửi theo từng term, và kết thúc bằng điều máy chủ nhận nên làm với mọi máy chủ còn lại (RFC 7208, tháng 4 năm 2014, vẫn là chuẩn hiện hành).

Máy chủ nhận đối chiếu nó với địa chỉ của máy chủ đang kết nối và tên miền của người gửi trong phong bì, tức MAIL FROM hay Return-Path, không phải dòng From: mà người đọc nhìn thấy. Gắn SPF với From: là việc của DMARC.

Một bản ghi chỉ áp dụng cho đúng tên mà nó nằm tại đó: SPF không có kế thừa, nên mail.example.com cần bản ghi riêng. Tên miền không gửi thư nên công bố v=spf1 -all.

Một bản ghi SPF, từng term mộtgoogle.com · TXT · ghi lại ngày 24 tháng 10, 2026 · TTL 5 phút
v=spf1Phiên bảninclude:_spf.google.comMechanism · 1 lượt tra cứu~allQualifier ~ · mechanism all cuối

Include trỏ tới _spf.google.com · 8 dải, không tra cứu thêm

ip4:74.125.0.0/16ip4:209.85.128.0/17ip6:2001:4860:4864::/56ip6:2404:6800:4864::/56ip6:2607:f8b0:4864::/56ip6:2800:3f0:4864::/56ip6:2a00:1450:4864::/56ip6:2c0f:fb50:4864::/56~all

Phiên bảnĐúng v=spf1, đứng đầu: bản ghi bắt đầu theo cách khác không phải bản ghi SPF.
Mechanisminclude, a, mx, ip4, ip6, exists, ptr và all, thử từ trái sang phải: lần khớp đầu tiên quyết định.
Qualifier+ pass (mặc định), - fail, ~ softfail, ? neutral, viết trước một mechanism.
Modifierredirect= giao lần kiểm tra cho một bản ghi khác; exp= giải thích một fail.
Toàn bộ bản ghi của google.com chỉ có ba term: máy chủ nhận lấy include, đối chiếu IP gửi với các dải của nó, hoặc tới ~all. Ghi lại qua Google Public DNS ngày 24 tháng 10, 2026.

Cách kiểm tra bản ghi SPF

Hãy nhập một tên miền ở trên, công cụ sẽ đọc các bản ghi TXT của nó, chọn bản ghi bắt đầu bằng v=spf1, rồi lần theo mọi include và redirect như một máy chủ nhận, đếm từng lượt tra cứu DNS trên đường đi.

Làm thủ công thì hãy hỏi các bản ghi TXT: dig TXT example.com +short hoặc nslookup -type=TXT example.com. Câu trả lời gồm mọi bản ghi TXT tại tên đó; bản ghi SPF là bản ghi bắt đầu bằng v=spf1, và một bản ghi dài sẽ đến dưới dạng nhiều chuỗi trong dấu ngoặc kép mà SPF nối lại không thêm dấu cách. Mỗi include là thêm một truy vấn, và bạn phải tự đếm chúng.

Để biết một máy chủ cụ thể có được gửi thư hay không, hãy chuyển sang Thử một IP: chế độ này chạy cùng lần kiểm tra cho địa chỉ đó và cho thấy term đã khớp.

dig TXT example.com +short

Mọi bản ghi TXT tại tên đó, như bộ phân giải của bạn đang có; bản ghi SPF là bản ghi bắt đầu bằng v=spf1. Hãy chạy lại cho từng include.

Những gì dig cho thấy, và những gì khônggithub.com · dig TXT · ghi lại ngày 24 tháng 10, 2026
cửa sổ lệnh1 trên 24 bản ghi TXT
$ dig TXT github.com @dns1.p08.nsone.net +norec +noall +answer
github.com.  300  IN  TXT  "v=spf1 ip4:192.30.252.0/22 include:spf.protection.outlook.com include:_netblocks.google.com include:_netblocks2.google.com include:mail.zendesk.com include:_spf.salesforce.com include:servers.mcsv.net include:mktomail.com include:sendgrid.net ip4:62.253.2" "27.114 ip4:166.78.69.169 ip4:166.78.69.170 ip4:166.78.71.131 ~all"

# rồi từng include, mỗi lần một truy vấn:
$ dig +short TXT _spf.salesforce.com
"v=spf1 exists:%{i}._spf.mta.salesforce.com -all"
  1. Một bản ghi bắt đầu bằng v=spf1. 23 bản ghi TXT khác bên cạnh (mã xác minh và những thứ tương tự) không ảnh hưởng tới SPF, trừ kích thước của câu trả lời.
  2. 2 chuỗi, nối lại không có dấu cách. Chỗ tách ở 255 byte nằm bên trong ip4:62.253.227.114: máy chủ nhận nối các chuỗi lại, nên không sao.
  3. TTL 5 phút. Bộ phân giải được giữ bản sao này bao lâu sau khi có thay đổi. Máy chủ của chính vùng nói 5 phút; bộ phân giải hiện phần còn lại của bản sao của nó.
  4. Mỗi include là một truy vấn riêng. Lần theo bản ghi của github.com tốn 10 lượt tra cứu, kể cả các include lồng nhau. dig chỉ cho thấy một tên mỗi lần: con số tới 10 là do bạn tự cộng.
Windows
$ nslookup -type=TXT github.com 8.8.8.8
PowerShell
# mọi bản ghi TXT tại tên đó, từ Google Public DNS
PS> Resolve-DnsName -Name github.com -Type TXT -Server 8.8.8.8
Trang này
/vi/spf-checker?domain=github.com
Câu trả lời TXT của github.com từ chính nameserver của nó: bản ghi SPF đến thành hai chuỗi, nối lại không có dấu cách, giữa các bản ghi TXT khác của tên miền.

Đọc kết quả: cây include

Kết luận cho biết máy chủ nhận nhận được gì với một máy chủ gửi mà bản ghi không liệt kê: hợp lệ kèm phần kết (softfail với ~all, fail với -all), hoặc một permerror kèm nguyên nhân, hoặc "không kiểm tra được" khi DNS không trả lời.

Cột màu xanh đậm là hạn mức tra cứu: mỗi lượt tra cứu DNS là một ô, tô màu theo include đã dùng nó, tổng đang chạy so với 10, và các lượt tra cứu rỗng là các vòng tròn. Quá lượt thứ 10, các ô chuyển sang đỏ và nhánh nơi máy chủ nhận dừng được đánh dấu.

Chế độ Cây liệt kê các nhận định, lỗi trước, mỗi nhận định kèm mục RFC và cách sửa, rồi mọi lượt tra cứu theo thứ tự máy chủ nhận hỏi.

Kiểm tra SPF cho github.com: 10 trên 10 lượt tra cứu DNS, một lượt rỗng, chi phí của từng include trong hạn mức tra cứuKiểm tra SPF cho github.com: 10 trên 10 lượt tra cứu DNS, một lượt rỗng, chi phí của từng include trong hạn mức tra cứuKết luậnĐiều máy chủ nhận nhận được với một máy chủ gửi mà bản ghi không liệt kê, và phần kết quyết định điều đó.Bản ghi, từng term mộtMỗi term được tô màu theo loại; một include mang dấu hiệu của chủ nó và chi phí tra cứu riêng.Các nhận địnhMột bản ghi, cú pháp hợp lệ, lượt tra cứu, lượt rỗng, phần kết, ptr, DMARC: lỗi trước, mỗi nhận định kèm cách sửa.Hạn mức tra cứuMỗi lượt tra cứu DNS là một ô, tô màu theo include đã dùng nó, so với giới hạn 10.Chi phí của từng includeMột nhánh cho mỗi include: các ô riêng của nó, những gì nó lồng vào và tổng đang chạy.Các lượt tra cứu rỗngVòng tròn cho những truy vấn trả về rỗng; lượt thứ ba kết thúc lần kiểm tra.
Kết quả kiểm tra SPF của github.com: kết luận, bản ghi tách thành từng term, các nhận định và hạn mức tra cứu với chi phí riêng của từng include. Chọn một số để xem từng phần thể hiện điều gì.

Giới hạn 10 lượt tra cứu và lỗi "too many DNS lookups" (permerror)

Máy chủ nhận đếm mọi term cần một truy vấn DNS, gồm include, a, mx, ptr, exists và redirect, qua mọi include lồng nhau, và dừng ở 10. Lượt thứ 11 cho permerror (RFC 7208 §4.6.4). ip4, ip6, all và exp không tốn gì.

Đó là permerror, không phải fail: máy chủ nhận làm gì với nó là quyết định của riêng họ, nhưng với DMARC thì permerror không bao giờ được tính là pass. Và vì lần kiểm tra dừng ở lần khớp đầu tiên, một bản ghi vượt giới hạn vẫn pass với các máy chủ gửi được liệt kê sớm và chỉ hỏng với những máy chủ gửi được liệt kê muộn.

Chi phí ẩn trong các include: include:_netblocks.mimecast.com tự nó tốn 9, Yandex 360 tốn 8, Freshdesk 7, Mailgun 5. Include của Google và Microsoft 365 mỗi cái tốn 1. Để xuống dưới 10, hãy bỏ các máy chủ gửi bạn không còn dùng và chuyển máy chủ gửi hàng loạt sang một tên miền phụ có bản ghi riêng.

Ai dùng 10 lượt tra cứuChi phí đo ngày 24 tháng 10, 2026 · một bản ghi tự dựng gồm các include thật

v=spf1 include:spf.protection.outlook.com include:_netblocks.mimecast.com include:mailgun.org include:sendgrid.net -all

cần 17 lượt tra cứu
Được liệt kê trong 10 lượt tra cứu đầu: passMicrosoft 3651Mimecast2–10
Được liệt kê sau lượt tra cứu 10: permerrorMailgun11–15Twilio SendGrid16–17

Mọi máy chủ gửi khác cũng nhận permerror, không phải fail của -all trong bản ghi: máy chủ nhận dừng trước khi tới đó.

Một include tốn bao nhiêuInclude do chính từng nhà cung cấp ghi trong tài liệu · đo ngày 24 tháng 10, 2026
  • _netblocks.mimecast.comMimecast9 lượt tra cứu
  • _spf.yandex.netYandex 3608 lượt tra cứu
  • email.freshdesk.comFreshdesk7 lượt tra cứu
  • mailgun.orgMailgun5 lượt tra cứu
  • icloud.comiCloud+5 lượt tra cứu
  • spf.titan.emailTitan Email4 lượt tra cứu
  • secureserver.netGoDaddy3 lượt tra cứu
  • _spf.google.comGoogle Workspace1 lượt tra cứu
  • spf.protection.outlook.comMicrosoft 3651 lượt tra cứu
Lượt tra cứu được đếm theo RFC 7208 §4.6.4: chính include cộng mọi thứ bên trong nó. Số liệu trực tiếp trên trang này luôn lấy từ lần đi qua bản ghi, không phải từ bảng này.

Lượt tra cứu rỗng (void lookup) là gì?

Lượt tra cứu rỗng là một truy vấn trả về không có bản ghi nào: tên không tồn tại (NXDOMAIN) hoặc tồn tại nhưng không có loại bản ghi được hỏi. Máy chủ nhận nên cho phép hai lượt; lượt thứ ba là permerror (RFC 7208 §4.6.4).

Một term trỏ tới host đã mất, a:old.example.com, tự nó không phải lỗi: nó chỉ không khớp và tính một lượt rỗng. exists:%{i}._spf.mta.salesforce.com cũng vậy với mọi máy chủ gửi mà Salesforce không liệt kê, vì thế thứ tự của các include rất quan trọng.

Lỗi máy chủ hay hết thời gian chờ không phải lượt rỗng: đó là temperror, và máy chủ nhận thường thử lại sau.

Bốn câu trả lời, ba kết quảRFC 7208 §4.6.4

Bản ghi riêng của salesforce.com với 192.0.2.1, ghi lại ngày 24 tháng 10, 2026

v=spf1 include:_spf.google.com include:_spf.salesforce.com exists:%{i}._spf.corp.salesforce.com ~all

Lượt tra cứu rỗng2 / 2lượt thứ ba: permerror
  1. exists:%{i}._spf.mta.salesforce.com192.0.2.1._spf.mta.salesforce.com → NXDOMAIN · lượt tra cứu 3 · trong _spf.salesforce.com
  2. exists:%{i}._spf.corp.salesforce.com192.0.2.1._spf.corp.salesforce.com → NXDOMAIN · lượt tra cứu 4 · trong salesforce.com

Kết quả: softfail, với cả hai lượt rỗng được phép đã dùng hết

Tên có tồn tại, bản ghi thì khônga:mail.example.com cho một tên vẫn còn nhưng không còn địa chỉ: NOERROR không có trả lời. Không khớp, một lượt rỗng, và lần kiểm tra vẫn tiếp tục.NODATArỗng
Tên không tồn tạiexists:%{i}._spf.mta.salesforce.com dựng một tên từ mỗi IP gửi; với một địa chỉ mà Salesforce không liệt kê, câu trả lời là NXDOMAIN: mỗi lần một lượt rỗng.NXDOMAINrỗng
Lượt rỗng thứ bamx:shop.example.com, một tên đã mất, sau khi đã có 2 lượt rỗng: máy chủ nhận dừng ở đây.NXDOMAINpermerror
Không có trả lời nàoSERVFAIL hoặc hết thời gian chờ với include:_spf.vendor.example: DNS bị lỗi, nên không có gì được tính là rỗng.SERVFAILtemperror, không phải lượt rỗng

Include include:spf.bmv.jp của blastmail bắt đầu bằng hai term exists như vậy: với một địa chỉ mà nó không liệt kê, riêng nó đã dùng hết cả hai lượt rỗng được phép.

Chỉ một câu trả lời rỗng mới được tính là rỗng. Một lỗi là temperror, và lần kiểm tra sẽ được thử lại sau.

Làm phẳng SPF (flattening): khi nào hữu ích, khi nào gây lỗi

Làm phẳng là thay một include bằng các địa chỉ mà nó liệt kê, để bản ghi tốn ít lượt tra cứu hơn. Cách này hiệu quả với những dải hiếm khi đổi, và phản tác dụng khi nhà cung cấp thêm một máy chủ mà bạn chưa sao chép: thư từ máy chủ đó sẽ fail SPF.

Microsoft nói không nên làm phẳng include:spf.protection.outlook.com, và include của Google lẫn Microsoft vốn đã chỉ tốn một lượt mỗi cái. Chuyển một máy chủ gửi hàng loạt sang tên miền phụ như news.example.com cho nó một bản ghi, và 10 lượt tra cứu, của riêng nó.

Một include, sau khi làm phẳngmailgun.org · ghi lại ngày 24 tháng 10, 2026

Trước

include:mailgun.org

Lượt tra cứu
5
Bản ghi đã lấy
5
Byte trong bản ghi của bạn
19
Mailgun đổi một dải
được cập nhật ngay

Sau

ip4:159.135.224.0/20 ip4:69.72.32.0/20 ip4:204.220.90.0/23 ip4:204.220.92.0/22 +18 nữa

Lượt tra cứu
0
Byte trong bản ghi của bạn
450
Số chuỗi TXT cần có
2
Mailgun đổi một dải
bản sao của bạn đã cũ

Rủi ro của bản sao cũ. Hôm nay bạn sao chép 22 dải; khi Mailgun thêm một dải, thư từ dải đó fail SPF cho tới khi có người nhận ra và cập nhật bản ghi.

  1. đã sao chép
  2. Mailgun thêm một dải
  3. thư từ dải đó fail SPF
Nên làm phẳng chỉ những dải hiếm khi đổi, như địa chỉ máy chủ của chính bạn.
Không nên làm phẳng Microsoft 365: Microsoft nói địa chỉ gửi thư của họ thay đổi thường xuyên, nên hãy giữ include.
Nên ưu tiên một tên miền phụ cho mỗi máy chủ gửi hàng loạt: mỗi cái có một bản ghi, và 10 lượt tra cứu, của riêng nó.
Làm phẳng là đánh đổi lượt tra cứu lấy công bảo trì: bản sao chỉ đúng cho tới khi nhà cung cấp đổi các dải của họ.

~all so với -all (và DMARC)

Term cuối cùng nói điều gì xảy ra với mọi máy chủ gửi không được liệt kê. -all là fail, tuyên bố mạnh nhất; ~all là softfail, "có lẽ không"; ?all là neutral, mà máy chủ nhận coi như không có SPF; +all cho mọi người pass và không bao giờ nên công bố.

Giữa ~all và -all không có đáp án sai. Google ghi nhận ~all cho Google Workspace và Microsoft ghi nhận -all cho Microsoft 365. Khi DMARC ở mức thực thi, ~all để DMARC quyết định dựa trên DKIM: một số máy chủ nhận từ chối ngay vì -all trước khi DMARC thấy chữ ký DKIM hợp lệ, nên thư được chuyển tiếp có thể bị trả lại (RFC 9989 §7.1).

Bốn phần kếtRFC 7208 §2.6 · RFC 9989 §7.1
~all
softfail“Có lẽ không được ủy quyền”: máy chủ nhận không nên từ chối chỉ vì nó.
Được ghi nhận bởiGoogle WorkspaceMailguniCloud+
-all
failTuyên bố mạnh nhất: máy chủ nhận có thể từ chối thư ngay trong SMTP.
Được ghi nhận bởiMicrosoft 365ZendeskGoDaddy
?all
neutralKhông tuyên bố gì: máy chủ nhận coi nó đúng như không có SPF.
Được ghi nhận bởiFastmailInclude của IONOS và OVHcloud cũng kết thúc bằng ?all: ở đó vô hại, vì chỉ một pass bên trong include mới khớp.
+all
pass cho mọi ngườiBất kỳ máy chủ nào trên Internet cũng pass dưới tên miền.
Không bao giờ nên công bố

-all với DMARC ở p=reject

  1. SPF ra fail
  2. bị từ chối trong SMTP
  3. DKIM không bao giờ được kiểm tra

Một số máy chủ nhận xử lý SPF trước, nên một thư được chuyển tiếp có chữ ký DKIM hợp lệ có thể bị từ chối trước khi DMARC chạy, và thiệt hại đó không bao giờ hiện trong báo cáo DMARC.

~all với DMARC ở p=reject

  1. SPF ra softfail
  2. DMARC kiểm tra DKIM
  3. DKIM căn chỉnh: pass

DMARC quyết định. Tuy nhiên, nếu không có chữ ký DKIM, Microsoft nói DMARC thực tế bị bỏ qua với các lỗi ~all, và vì lý do đó khuyên dùng -all.

Cả ~all lẫn -all đều là lựa chọn hợp lệ; ?all không nói gì, và +all cho bất kỳ ai cũng pass.

Các lỗi SPF thường gặp và cách sửa

Phần lớn bản ghi hỏng đến từ ba sơ suất: thêm bản ghi SPF thứ hai bên cạnh bản ghi đầu thay vì gộp chúng, một include cho nhà cung cấp đã không còn, và một giá trị sao chép từ tài liệu có lỗi gõ.

Tài liệu của nhà cung cấp tự in ra một số lỗi này: Mimecast viết –all với gạch ngang en, Postmark viết include: spf.mtasv.net có dấu cách, Twilio SendGrid liệt kê một mechanism aaaa không hề tồn tại. Bất kỳ lỗi cú pháp nào cũng khiến cả bản ghi thành permerror. Ngược lại, dấu chấm cuối sau tên miền là hợp lệ.

Tám bản ghi, tám kết quảVí dụ tự dựng về những lỗi có thật

Hai bản ghi SPFpermerror

v=spf1 include:_spf.google.com ~allv=spf1 include:sendgrid.net ~all

Cách sửa: gộp thành một: một v=spf1, mỗi include một lần, một phần kết.

Hơn 10 lượt tra cứupermerror

v=spf1 include:_netblocks.mimecast.com include:mailgun.org -all

14 lượt tra cứu

Cách sửa: bỏ các máy chủ gửi bạn không còn dùng, hoặc cho máy chủ gửi hàng loạt một tên miền phụ riêng.

Lượt tra cứu rỗng thứ bapermerror

v=spf1 a:old.example.com mx:gone.example.net exists:%{i}.spf.example.org -all

3 lượt rỗng

Cách sửa: xóa các term có tên đã mất, và đặt các include exists ở cuối.

Một include không có bản ghi SPF phía saupermerror

v=spf1 include:spf.retired-vendor.example -all

Cách sửa: sửa lại tên, hoặc gỡ nhà cung cấp bạn đã bỏ.

Gạch ngang en trong –allpermerror

v=spf1 include:_netblocks.mimecast.com –all

In đúng như vậy trong tài liệu của chính Mimecast

Cách sửa: dùng dấu gạch nối thường: -all.

Dấu cách sau include:permerror

v=spf1 a mx include: spf.mtasv.net ~all

In đúng như vậy trong tài liệu của chính Postmark

Cách sửa: include:spf.mtasv.net

Một mechanism aaaapermerror

v=spf1 aaaa:example.com ~all

In đúng như vậy trong tài liệu của chính Twilio SendGrid

Cách sửa: a:example.com; a đã khớp bản ghi AAAA của các máy chủ gửi dùng IPv6.

Dấu chấm cuốihợp lệ

v=spf1 include:spf.protection.outlook.com. -all

Hợp lệ: RFC 7208 §7.3 nói không nên công bố nó, nhưng máy chủ nhận phải chấp nhận.

Trang trợ giúp của Zendesk cũng nói “redirect: syntax is supported”: modifier được viết là redirect= (RFC 7208 §6.1).

Mỗi bản ghi là một ví dụ tự dựng; các lỗi là những lỗi mà máy chủ nhận gặp nhiều nhất.

Gmail, Yahoo và Microsoft yêu cầu gì

Từ tháng 2 năm 2024, Gmail và Yahoo yêu cầu mọi bên gửi phải thiết lập SPF hoặc DKIM. Bên gửi số lượng lớn cần cả hai, một bản ghi DMARC ít nhất p=none, và tên miền From: căn chỉnh với một trong hai. Outlook.com yêu cầu bên gửi số lượng lớn có cả SPF lẫn DKIM, và đã từ chối thư của những bên thiếu chúng từ ngày 5 tháng 5 năm 2025.

Ngưỡng của Gmail là hơn 5.000 thư mỗi ngày tới tài khoản cá nhân; Yahoo không công bố ngưỡng nào. Riêng SPF không bao giờ khiến thư "căn chỉnh": tên miền MAIL FROM phải là của bạn, không phải tên miền bounce của nhà cung cấp.

Quy tắc của ba nhà cung cấp hộp thưĐọc trên các trang của chính từng nhà cung cấp, 24 tháng 10, 2026
GmailYahooOutlook.com
Ngưỡng số lượng lớnGmailhơn 5.000 thư mỗi ngày tới tài khoản Gmail cá nhân, tính theo tên miền chínhYahookhông công bố: “We will not specify a volume threshold”Outlook.comhơn 5.000 thư mỗi ngày (blog của Microsoft); 5.000 thư trở lên từ một tên miền From: (bài hỗ trợ của họ)
Mọi bên gửiGmailSPF hoặc DKIM, cộng DNS xuôi và ngược, TLS và tỷ lệ spam dưới 0,3%YahooSPF hoặc DKIM, cộng DNS xuôi và ngược và tỷ lệ spam dưới 0,3%Outlook.comkhông có quy tắc cứng
Bên gửi số lượng lớnGmailSPF và DKIM, DMARC (p=none là đủ), From: căn chỉnh với SPF hoặc DKIM, hủy đăng ký một cú nhấp cho thư tiếp thịYahooSPF và DKIM, DMARC ít nhất p=none và pass, From: căn chỉnh với SPF hoặc DKIM, hủy đăng ký một cú nhấpOutlook.comSPF phải pass và DKIM phải pass, DMARC ít nhất p=none, căn chỉnh với SPF hoặc DKIM
Có hiệu lực từGmail1 tháng 2, 2024; việc từ chối thư tăng dần từ tháng 11 năm 2025Yahootháng 2 năm 2024Outlook.com5 tháng 5, 2025 (từ chối thư)
Lỗi SPF hiện ra làGmail4.7.275.7.27Yahookhông có trong tài liệu cho SPFOutlook.com550 5.7.515

Nhật Bản: thiết lập nghiêm ngặt nhất của NTT docomo, 「全て拒否する」, từ chối thư có IP gửi mà bản ghi SPF của tên miền không cho phép, và thư từ những tên miền hoàn toàn không công bố bản ghi SPF. docomo.ne.jp

Nguồnsupport.google.comsenders.yahooinc.comtechcommunity.microsoft.com

Quy tắc của từng nhà cung cấp đúng như các trang của chính họ nêu ngày 24 tháng 10, 2026.

Tra cứu SPF so với dig và nslookup

dig và nslookup cho thấy các bản ghi TXT như bộ phân giải của bạn đang có: bản ghi SPF và mọi thứ khác nằm tại tên đó. Chúng không lần theo include, không đếm lượt tra cứu hay lượt rỗng, và không cho biết một máy chủ nhận sẽ quyết định ra sao.

Một công cụ tra cứu SPF như công cụ này đi qua toàn bộ bản ghi, nên các con số khớp với những gì một máy chủ nhận tính ra. Hãy dùng dig cho một tên, và công cụ kiểm tra này để có kết luận.

Ba cách nhìn vào SPFMỗi cách cho thấy gì
Công cụ nàydig TXTnslookup -type=TXT
Hiển thị các bản ghi TXTCông cụ nàyCótách thành từng termdig TXTCónslookup -type=TXTCó
Nối các chuỗi của một bản ghi dàiCông cụ nàyCónhư máy chủ nhận làmdig TXTKhônghiện từng chuỗi riêngnslookup -type=TXTKhônghiện từng chuỗi riêng
Lần theo mọi includeCông cụ nàyCótoàn bộ câydig TXTKhôngmỗi truy vấn một tênnslookup -type=TXTKhôngmỗi truy vấn một tên
Đếm lượt tra cứu tới 10Công cụ nàyCótổng đang chạy, theo từng includedig TXTKhônglàm thủ côngnslookup -type=TXTKhônglàm thủ công
Đếm lượt tra cứu rỗngCông cụ nàyCókèm têndig TXTKhôngnslookup -type=TXTKhông
Cho biết hai bản ghi = permerrorCông cụ nàyCódig TXTKhôngin cả hainslookup -type=TXTKhôngin cả hai
Thử một IP gửiCông cụ nàyCócheck_host và term khớpdig TXTKhôngnslookup -type=TXTKhông
Hỏi bộ phân giải của riêng bạnCông cụ nàyKhôngGoogle Public DNS, từ máy chủ của chúng tôidig TXTCónslookup -type=TXTCó
Cùng một câu hỏi, ba cách hỏi: dig và nslookup cho thấy những gì bộ phân giải của bạn có, công cụ này cho thấy những gì một máy chủ nhận tính ra.

Kiểm tra SPF: câu hỏi thường gặp

Kiểm tra bản ghi SPF là gì?

Kiểm tra bản ghi SPF là đọc bản ghi SPF của một tên miền, tức bản ghi TXT bắt đầu bằng v=spf1, và đi qua nó như một máy chủ thư nhận: lần theo mọi include và redirect, mỗi lượt tra cứu DNS tính vào giới hạn 10 và mỗi câu trả lời rỗng tính vào giới hạn 2. Kết quả là điều máy chủ nhận thấy với một máy chủ gửi không được liệt kê, hoặc permerror và nguyên nhân của nó.

Làm sao kiểm tra một địa chỉ IP có được phép gửi email cho tên miền của tôi không?

Hãy chọn Thử một IP, nhập tên miền và địa chỉ của máy chủ gửi, IPv4 hoặc IPv6, và nếu muốn thì cả địa chỉ MAIL FROM và tên HELO. Công cụ chạy check_host cho địa chỉ đó và cho thấy pass, fail, softfail, neutral hoặc permerror, đúng term đã khớp, qualifier của nó và chuỗi include dẫn tới nó.

"SPF too many DNS lookups" nghĩa là gì?

Nghĩa là việc kiểm tra bản ghi cần hơn 10 lượt tra cứu DNS, giới hạn trong RFC 7208. Mỗi include, a, mx, ptr, exists và redirect tốn một lượt, kể cả những cái lồng trong include. Máy chủ nhận dừng ở lượt thứ 11 với permerror, nên các máy chủ gửi được liệt kê sau điểm đó không còn pass SPF. Hãy bỏ include không dùng, hoặc chuyển một máy chủ gửi sang tên miền phụ có bản ghi riêng.

SPF permerror là gì?

Permerror là kết quả "không thể đánh giá bản ghi này" của SPF. Nó đến từ hơn 10 lượt tra cứu DNS, hơn 2 lượt tra cứu rỗng, hai bản ghi SPF tại một tên, một include tới tên không có bản ghi SPF, hoặc lỗi cú pháp. Nó không phải fail: máy chủ nhận tự quyết định xử lý ra sao, nhưng với DMARC thì nó không bao giờ được tính là pass.

Lượt tra cứu rỗng (void lookup) trong SPF là gì?

Lượt tra cứu rỗng là một truy vấn DNS cho một term SPF mà trả về rỗng: tên không tồn tại (NXDOMAIN) hoặc không có bản ghi thuộc loại được hỏi. RFC 7208 nói máy chủ nhận nên cho phép hai lượt; lượt thứ ba là permerror. Lỗi máy chủ hay hết thời gian chờ không phải lượt rỗng mà là temperror, thường được máy chủ nhận thử lại sau.

Bản ghi SPF của tôi nên kết thúc bằng ~all hay -all?

Cả hai đều hợp lệ. -all (fail) là tuyên bố mạnh nhất và Microsoft ghi nhận nó cho Microsoft 365; ~all (softfail) là điều Google ghi nhận cho Google Workspace. Khi có ký DKIM và DMARC ở quarantine hoặc reject, ~all thường là phần kết an toàn hơn, vì một số máy chủ nhận từ chối ngay vì -all trước khi DMARC kịp chấp nhận một chữ ký DKIM hợp lệ.

Một tên miền có thể có hai bản ghi SPF không?

Không. Nếu một tên có hai bản ghi TXT bắt đầu bằng v=spf1, máy chủ nhận không chọn được một bản ghi và lần kiểm tra kết thúc bằng permerror trước mọi lượt tra cứu, với mọi máy chủ gửi (RFC 7208 §4.5). Lỗi này thường xảy ra khi bản ghi của một nhà cung cấp mới được thêm bên cạnh bản ghi cũ. Hãy gộp thành một bản ghi với một v=spf1, mỗi include một lần và một phần kết duy nhất.

Làm phẳng SPF (flattening) là gì, và tôi có nên dùng không?

Làm phẳng là thay các include bằng những dải IP mà chúng liệt kê, để bản ghi cần ít lượt tra cứu DNS hơn. Cách này hữu ích với những dải hiếm khi đổi, nhưng bản sao đã làm phẳng sẽ cũ ngay khi nhà cung cấp thêm máy chủ, và thư từ chúng khi đó fail SPF. Hãy ưu tiên bỏ include không dùng hoặc cho máy chủ gửi hàng loạt một tên miền phụ riêng; đừng bao giờ làm phẳng include của Microsoft 365.

Tên miền phụ có cần bản ghi SPF riêng không?

Có. SPF không có kế thừa: một bản ghi chỉ áp dụng cho đúng tên mà nó được công bố, nên mail.example.com hay news.example.com cần bản ghi riêng nếu xuất hiện trong MAIL FROM hoặc HELO. Điều này khác với DMARC, vốn quay về tên miền tổ chức. Một tên miền phụ không gửi thư có thể công bố v=spf1 -all.

Vì sao SPF pass ở đây nhưng lại fail ở Gmail?

Thường là vì Gmail đã kiểm tra một tên miền hay địa chỉ khác. SPF được đánh giá cho tên miền MAIL FROM (Return-Path) và IP của máy chủ đang kết nối, có thể là tên miền bounce của nhà cung cấp, không phải của bạn. Việc chuyển tiếp thư cũng làm hỏng SPF, vì IP của máy chủ chuyển tiếp không có trong bản ghi của bạn. Hãy xem header Authentication-Results của một thư thật rồi thử IP và tên miền đó tại đây.

SPF, DKIM và DMARC khác nhau thế nào?

SPF liệt kê các máy chủ được phép gửi cho một tên miền và được kiểm tra với người gửi trong phong bì. DKIM ký từng thư bằng một khóa công bố trong DNS, nên chữ ký vẫn còn khi thư được chuyển tiếp. DMARC gắn chúng với địa chỉ From: mà người đọc nhìn thấy: một thư pass DMARC khi SPF hoặc DKIM pass cho một tên miền căn chỉnh với From:, và chính sách nói phải làm gì nếu không.

Thay đổi bản ghi SPF mất bao lâu để có hiệu lực?

Lâu bằng thời gian bộ phân giải giữ bản ghi cũ: tối đa bằng TTL do tên miền đặt (300 giây với google.com và github.com, một giờ với microsoft.com khi chúng tôi kiểm tra). Máy chủ nhận hỏi bộ phân giải của họ, nên thay đổi chỉ hiện ra khi mỗi bản sao lưu đệm hết hạn. Công cụ này hiện TTL đúng như nameserver của chính tên miền đang phục vụ; hãy kiểm tra lại sau khoảng thời gian đó.

Công cụ email và DNS liên quan