Defaults.Exposed › Báo cáo
Tại Sao SPF Của Tôi Bị Lỗi? Vấn Đề 10 Tra Cứu SaaS Đối Với Người Gửi UK Và EU (2026)
Đã xuất bản 2026-07-09
Số liệu tính đến 2026-06-29 · phương pháp luận v7. Dữ liệu điều tra tổng hợp trên 261 triệu tên miền đã được chấm điểm. Xem cách chúng tôi chấm điểm.
Khi SPF thất bại ở một doanh nghiệp đang sử dụng các công cụ SaaS tại UK hoặc EU, nguyên nhân có khả năng nhất là một quy tắc RFC mà bạn chưa bao giờ cần nghĩ đến: vượt quá 10 lần tra cứu DNS, SPF không trả về “fail” — nó trả về PermError, nghĩa là bản ghi được coi như không tồn tại. Ít nhất 797,263 tên miền đã vượt qua ranh giới đó. Thêm 2,119,539 tên miền khác đang ở đúng mức 9–10 lần tra cứu — chỉ cần thêm một công cụ mới là có thể rơi xuống vực thẳm tương tự.
Tại sao SPF bị hỏng khi bạn thêm một công cụ SaaS?
SPF hoạt động bằng cách liệt kê các máy chủ thư được phép gửi thay mặt cho tên miền của bạn. Các doanh nghiệp hiện đại không vận hành máy chủ thư riêng — họ sử dụng Google Workspace cho email nội bộ, Mailchimp cho các chiến dịch, HubSpot cho chuỗi bán hàng, Pipedrive cho tiếp cận CRM. Mỗi nền tảng cung cấp cho bạn một dòng include: để dán vào DNS.
Vấn đề là: mỗi include: tự nó là một lần tra cứu DNS. Và mỗi bản ghi bên trong include đó có thể kích hoạt thêm nhiều lần tra cứu theo cách đệ quy. RFC 7208 §4.6.4 đặt ra giới hạn cứng là mười lần. Vượt quá mười, máy chủ thư nhận dừng đánh giá và trả về PermError — và PermError không phải là thất bại mềm kết thúc trong thư rác. Nó có nghĩa là bản ghi SPF của bạn được coi như vắng mặt. Xác thực email thất bại ở bước SPF.
Bạn sẽ không thấy điều này trong bảng điều khiển DNS. Bộ đếm chỉ kích hoạt trong quá trình đánh giá trực tiếp. Bạn có thể có ba dòng include: trong bản ghi hiển thị và vẫn đang ở độ sâu mười hai lần tra cứu, vì bản ghi SPF của mỗi nhà cung cấp kéo vào các sub-include của chính họ.
Có bao nhiêu tên miền đã vượt quá giới hạn?
Ít nhất 797,263. Đây là con số sau khi chúng tôi đã giải quyết mọi mục tiêu SPF include: được tham chiếu từ 100 lần trở lên — 10,842 mục tiêu riêng biệt bao gồm 95.2% tổng số tham chiếu include — và định giá chuỗi đầy đủ của từng tên miền. Con số bề mặt (những gì bạn tìm thấy bằng cách chỉ đếm các dòng hiển thị trong một bản ghi) tìm thấy khoảng 7,958. Con số dựa trên chuỗi lớn hơn 100 lần, vì gần như toàn bộ thiệt hại ẩn bên trong các mục tiêu include.
Tình huống có khả năng ảnh hưởng nhất đến doanh nghiệp châu Âu:
| Tình huống | Điều gì xảy ra |
|---|---|
| Google Workspace + Mailchimp + HubSpot + một cái khác | Có khả năng đạt hoặc vượt 10 lần tra cứu |
| Hosting IONOS + bất kỳ ba công cụ SaaS nào | Rủi ro cao: mục tiêu SPF của chính IONOS thêm nhiều bước nhảy |
| Hosting OVH + hai công cụ giao dịch + CRM | Rủi ro phụ thuộc vào độ sâu SPF của OVH lúc đánh giá |
| Chỉ Microsoft 365 | Rủi ro thấp: SPF của Microsoft gọn nhẹ và được duy trì tốt |
Các nhà cung cấp hosting châu Âu và cài đặt SPF mặc định yếu
Nhà cung cấp hosting bạn bắt đầu sử dụng rất quan trọng — vì một số đặt cài đặt SPF mặc định đã tiêu thụ một vài trong số mười lần tra cứu của bạn trước khi bạn kết nối bất kỳ công cụ SaaS nào.
Trong số các nhà cung cấp hosting lớn nhất được sử dụng bởi các tên miền châu Âu trong điều tra của chúng tôi:
| Nhà cung cấp | Tên miền sử dụng | SPF nghiêm ngặt (-all) | DMARC thực thi |
|---|---|---|---|
| IONOS (EU) | 4,346,526 | 0.3% | 1.0% |
| OVH | 2,132,049 | 43.7% | 2.2% |
| Microsoft 365 | 10,205,070 | 85.0% | 21.7% |
| Google Workspace | 12,145,313 | 8.0% | 18.5% |
IONOS nổi bật: 1.0% tên miền được host bởi IONOS có DMARC thực thi, nghĩa là đại đa số hoàn toàn không có xác thực người gửi có ý nghĩa. Các tên miền OVH làm tốt hơn về cài đặt SPF nghiêm ngặt (43.7%) nhưng vẫn rơi xuống 2.2% về thực thi DMARC — SPF đơn độc, không có DMARC để gắn kết với header From:, chỉ bảo vệ phong bì, không phải những gì người nhận nhìn thấy.
Microsoft 365 là ngoại lệ tích cực: 85.0% tên miền được host bởi Microsoft sử dụng SPF nghiêm ngặt, chủ yếu vì trình hướng dẫn luồng thư của Microsoft đặt -all theo mặc định. Google Workspace đặt ~all (softfail) theo mặc định, để lại 92% tên miền của mình không có bảo vệ nghiêm ngặt.
Cách chẩn đoán lỗi SPF trong dưới 60 giây
Kiểm tra nhanh nhất là công cụ miễn phí đánh giá toàn bộ chuỗi tra cứu — không chỉ bản ghi hiển thị. Chạy nslookup -type=TXT yourdomain.com trên dòng lệnh và đếm mọi include: bạn thấy. Sau đó tra cứu từng bản ghi đó và đếm bản ghi của chúng. Nếu bạn hết ngón tay trước khi hết include, bạn đang ở vùng nguy hiểm.
Phương pháp đáng tin cậy hơn: kiểm tra tên miền của bạn tại đây — bộ quét đánh giá toàn bộ chuỗi đã giải quyết, gắn cờ PermError và cho bạn thấy cơ chế nào đang tiêu thụ ngân sách tra cứu của bạn.
Ba kết quả chẩn đoán:
- PermError — bạn đã vượt quá mười. Mọi email bạn gửi đều thất bại kiểm tra SPF tại người nhận.
- Ở mức 9–10 lần tra cứu — bạn đang ở mép vực. Tích hợp SaaS tiếp theo sẽ đẩy bạn xuống.
- Softfail (~all) thay vì hardfail (-all) — bạn dưới giới hạn nhưng bản ghi được đặt quá dễ dãi để cung cấp bảo vệ thực sự. Xem báo cáo cấu hình SPF sai để có bức tranh đầy đủ về
-allso với~all.
Cách sửa SPF khi sử dụng nhiều công cụ SaaS
Có ba phương pháp, theo thứ tự tính lâu dài:
1. Kiểm tra và cắt tỉa. Bắt đầu bằng cách liệt kê mọi include: trong bản ghi hiện tại của bạn. Xóa bất kỳ nền tảng nào bạn không còn sử dụng — các ESP cũ, công cụ CRM từ hợp đồng trước, các nền tảng bạn đã thử nghiệm nhưng đã bỏ. Điều này miễn phí và thường lấy lại được vài lần tra cứu. Mỗi include: đã xóa có thể loại bỏ 1–3 sub-tra cứu.
2. Làm phẳng bản ghi SPF của bạn. Làm phẳng SPF giải quyết tất cả các mục tiêu include: thành các dải IP cơ bản và ghi trực tiếp vào bản ghi của bạn dưới dạng cơ chế ip4: và ip6:. Cơ chế IP không kích hoạt tra cứu, vì vậy bản ghi được làm phẳng có thể liệt kê hàng chục nguồn gửi và vẫn ở mức không tra cứu. Nhược điểm: bạn cần làm phẳng lại mỗi khi nhà cung cấp cập nhật IP gửi của họ, điều này xảy ra mà không có thông báo. Hầu hết các doanh nghiệp sử dụng dịch vụ làm phẳng SPF trả phí (PowerDMARC, EasyDMARC, Dmarcian, và các dịch vụ khác cung cấp điều này) hoặc xây dựng quy trình giám sát.
3. Sử dụng macro SPF. Macro RFC 7208 cho phép bạn xây dựng các bản ghi thực hiện một lần tra cứu DNS duy nhất mỗi kiểm tra và trả lời một cách động, thay vì một chuỗi include. Macro yêu cầu hỗ trợ hosting DNS và một số nỗ lực triển khai, nhưng chúng là giải pháp sạch về mặt kiến trúc cho các tổ chức có nhiều người gửi SaaS.
Sau khi sửa SPF, kết hợp với thực thi DMARC — SPF không có DMARC chỉ xác thực người gửi phong bì, không phải địa chỉ From: header mà người nhận nhìn thấy.
Câu hỏi thường gặp
Tại sao bản ghi SPF của tôi vượt qua công cụ DNS nhưng vẫn thất bại trong header email?
Hầu hết các công cụ tra cứu DNS chỉ đếm các cơ chế hiển thị trong bản ghi của chính bạn, không phải các sub-tra cứu mà những cơ chế đó kích hoạt. Bạn có thể có hai dòng include: và vẫn vượt quá giới hạn nếu bản ghi của mỗi nhà cung cấp chứa thêm vài dòng nữa. Chỉ công cụ định giá chuỗi (hoặc máy chủ thư nhận) mới đếm toàn bộ độ sâu. Kiểm tra tên miền của bạn để xem số đếm chuỗi thực sự.
SPF thất bại có nghĩa là email của tôi sẽ vào spam không?
PermError (quá nhiều lần tra cứu) có nghĩa là bước SPF của xác thực trả về không có kết quả — thực tế là vắng mặt. DMARC đánh giá cả SPF và DKIM; nếu DKIM vượt qua, DMARC vẫn có thể vượt qua dù có PermError SPF. Nếu cả hai đều không vượt qua, DMARC thất bại, và kết quả phụ thuộc vào chính sách DMARC của bạn. Ở p=none, email vẫn được gửi nhưng thất bại được ghi lại. Ở p=quarantine hoặc p=reject, email bị lọc hoặc trả lại. Sửa SPF để bạn không chỉ dựa vào DKIM.
Một stack SaaS thông thường sử dụng bao nhiêu lần tra cứu? Bản ghi SPF p99 trong điều tra của chúng tôi đã ở mức 9 lần tra cứu — ngay tại giới hạn — trước khi thêm bất cứ điều gì. Một bản ghi Google Workspace thêm 3–4 lần tra cứu; Mailchimp thêm 1–2; HubSpot thêm 1–3 tùy thuộc vào cấu hình hiện tại của họ. Ba công cụ chính thống cộng với cài đặt mặc định của nhà cung cấp hosting thường đủ để vượt quá mười.
Làm phẳng SPF có an toàn không?
Có, miễn là bạn giữ nó cập nhật. Làm phẳng chuyển đổi chuỗi include: thành các dải IP tĩnh — nếu nhà cung cấp xoay vòng IP gửi của họ và bạn không làm phẳng lại, bạn sẽ bắt đầu từ chối thư của họ. Hầu hết các tổ chức sử dụng dịch vụ làm phẳng được quản lý để giám sát các thay đổi IP thay vì tự duy trì.
SPF của tôi đã như thế này nhiều năm — tại sao đột nhiên thất bại? Vì các nhà cung cấp của bạn đã cập nhật bản ghi SPF của họ, không phải của bạn. Mỗi khi một nền tảng SaaS thêm một dải IP gửi mới hoặc lồng thêm một include khác, chi phí chuỗi của bạn tăng lên mà không có bất kỳ thay đổi nào từ phía bạn. Giới hạn 10 lần tra cứu được đánh giá trực tiếp khi nhận tin nhắn, vì vậy một thay đổi của nhà cung cấp vào sáng thứ Ba có thể phá vỡ SPF của bạn vào chiều thứ Ba.
Sửa SPF có cải thiện khả năng gửi email không? Nó loại bỏ một nguồn thất bại xác thực, đây là điều kiện tiên quyết cho việc gửi nhất quán — đặc biệt kể từ khi Google và Yahoo hiện thực thi căn chỉnh DMARC cho người gửi số lượng lớn. SPF một mình không phải là bức tranh toàn cảnh: kết hợp với DKIM và DMARC để xác thực email đầy đủ.
Kiểm tra SPF miễn phí
Nếu bạn không chắc liệu bản ghi SPF của mình có vượt quá giới hạn tra cứu hay không — hoặc được đặt quá yếu để bảo vệ tên miền của bạn — hãy chạy kiểm tra miễn phí. Nó đánh giá toàn bộ chuỗi đã giải quyết và chỉ cho bạn thấy chính xác ngân sách đang được chi tiêu ở đâu.
Kiểm tra tên miền của bạn → · Sửa SPF → · Báo cáo SPF PermError → · Báo cáo cấu hình SPF sai → · Mô hình độ trưởng thành áp dụng SPF → · Sửa DMARC → · Chỉ dữ liệu tổng hợp. Dữ liệu được lưu trữ và xử lý trong EU.