Báo cáo SPF PermError: Số tên miền vượt giới hạn 10 lần tra cứu nhiều gấp 100× so với con số bề mặt cho thấy (2026)

Đã xuất bản 2026-07-03

Số liệu tính đến 2026-06-29 · phương pháp v7, cộng thêm một lượt định giá chuỗi chạy ngày 2026-07-03. Từ cuộc điều tra tổng thể gồm 261 triệu tên miền đã được chấm điểm, chúng tôi đã phân giải mọi mục tiêu include: của SPF được tham chiếu từ 100 lần trở lên — 10,842 mục tiêu bao phủ 95.2% tổng số tham chiếu include — và định giá chuỗi được giữ lại của từng tên miền dựa trên bản đồ đó. Các mục tiêu đuôi chưa phân giải được tính là không, và nội dung chuỗi phản ánh trạng thái vào ngày phân giải, nên con số tiêu đề là một xấp xỉ thận trọng, thiên về mức sàn: chúng tôi nói “ít nhất”. Chỉ ở dạng tổng hợp; không bao giờ là hồ sơ của một doanh nghiệp cá thể. Xem cách chúng tôi chấm điểm.

Có bao nhiêu tên miền vượt giới hạn 10 lần tra cứu của SPF?

Ít nhất 797,263 — bởi vì SPF có một cơ chế tự hủy được đưa vào ngay trong chuẩn, và cái cò kích hoạt lại ẩn ở nơi chủ sở hữu không thể thấy. RFC 7208 §4.6.4 giới hạn một lần kiểm tra SPF ở tối đa 10 lần tra cứu DNS; vượt quá mười, bên nhận dừng lại và trả về PermError, và một bản ghi PermError chẳng bảo vệ được gì. Nếu chỉ đếm các lần tra cứu hiện diện ngay trong bản ghi — như hầu hết công cụ vẫn làm, và như chính cuộc điều tra của chúng tôi đã làm cho tới báo cáo này — bạn tìm thấy khoảng 8.000 trường hợp vi phạm (chính xác là 7,958). Định giá các chuỗi include: mà những bản ghi đó thực sự kéo vào, và con số lên tới 797,263: lớn hơn khoảng 100 lần.

Vì sao chủ sở hữu không thể thấy nó đến?

Bởi vì ngân sách bị tiêu bởi bản ghi của người khác. include:onetool.example.com hiện ra như một dòng trong bảng DNS của bạn — nhưng bên nhận phải tải cả bản ghi đó nữa, và đếm mọi cơ chế tra cứu mà nó chứa, một cách đệ quy. Một bản ghi có ba include có thể tốn mười một lần. Không có gì trong vùng zone của chính bạn thay đổi vào cái ngày bạn vượt ngưỡng; một nhà cung cấp đã lồng thêm một include, và SPF của bạn chết mà không hề báo trước.

Tệ hơn, DMARC coi PermError là một thất bại ở nhánh SPF — nên một tên miền làm hỏng SPF theo cách này giờ đang thất bại một nửa quy trình xác thực của chính nó.

Việc định giá chuỗi phát hiện điều gì

Phát hiện	Tên miền
Vượt giới hạn 10 lần tra cứu, đã định giá chuỗi	797,263
Vượt giới hạn khi chỉ đếm các cơ chế hiện diện	7,958
Vượt giới hạn trong khi kết thúc bằng `-all` nghiêm ngặt	112,215
Đúng ngay 9–10 lần tra cứu — sát mép vực	2,119,539

Có hai câu chuyện trong bảng đó — câu chuyện thứ ba, mép vực, có riêng một mục ở dưới:

Con số bề mặt bỏ sót khoảng 99% số ca hỏng. Việc đếm cơ chế hiện diện tìm ra 7,958; định giá các chuỗi tìm ra 797,263. Gần như toàn bộ thiệt hại được thừa kế từ những gì các include kéo vào.
112,215 trong số các bản ghi bị hỏng kết thúc bằng -all. Chủ của chúng đã làm mọi thứ đúng đắn — trèo qua bức tường, chọn cái kết thúc nghiêm ngặt — và chỉ thừa một include thôi đã vô hiệu hóa tất cả. Trông có vẻ nghiêm ngặt mà lại hỏng là kiểu thất bại tàn khốc nhất trong an ninh email.

2.1 triệu tên miền chỉ cách mép vực một công cụ

Con số nên khiến những độc giả hiện đang ổn lo lắng: 2,119,539 tên miền phân giải ra đúng 9 hoặc 10 lần tra cứu — hôm nay còn dưới giới hạn, chết ngay cái ngày ai đó kết nối thêm một nền tảng nữa. Đó là khoảng 1 trên 66 tổng số nhà phát hành SPF, và nó khớp với hình dạng của phân bố: bản ghi SPF ở phân vị thứ 99 đã nằm ở 9 lần tra cứu. Đăng ký thêm một công cụ tiếp thị, dán vào cái dòng “chỉ cần thêm include này”, và một bản ghi vốn còn dưới giới hạn lúc ăn sáng đã bị vô hiệu vào giờ ăn trưa.

Lỗi tại ai? Ngày càng là tại chính cái stack

Các nhà cung cấp lớn nhất đã lặng lẽ làm phẳng SPF của họ — _spf.google.com của Google và spf.protection.outlook.com của Microsoft giờ mở rộng thành danh sách IP thuần túy tốn không lần tra cứu nội bộ nào (chúng tôi đã kiểm chứng cả hai với DNS trực tiếp trong quá trình phân tích này). Các vụ nổ bung đến từ nơi khác: các chuỗi bảng điều khiển hosting lồng sâu ba tầng, các nhà cung cấp khu vực có include tự nó đã tốn 7–10 lần tra cứu, và sự tích lũy thành thật của SaaS — hộp thư cộng bản tin cộng CRM cộng bàn hỗ trợ, mỗi thứ “chỉ một include”. Gần như không ai thêm lần tra cứu thứ mười một một cách cố ý. Nó đến như tổng của những quyết định hợp lý.

Cách kiểm tra và sửa của bạn — miễn phí

Đếm tổng số thực của bạn — công cụ kiểm tra miễn phí của chúng tôi phân giải chuỗi của bạn, hoặc dùng bất kỳ công cụ đếm tra cứu SPF nào.
Cắt tỉa phần thừa: những công cụ bạn đã ngừng dùng, các include trùng lặp, và cơ chế ptr đã lỗi thời.
Chỉ làm phẳng những gì bạn kiểm soát. Thay một include lồng sâu bằng các dải IP của nó thì hiệu quả với hạ tầng của chính bạn; IP của bên thứ ba thay đổi mà không báo trước.
Cấp cho người gửi số lượng lớn một tên miền phụ. Bản tin gửi từ news.yourdomain.com có bản ghi riêng và ngân sách 10 lần tra cứu riêng của chúng.

Các câu hỏi thường gặp

Giới hạn 10 lần tra cứu DNS của SPF là gì? RFC 7208 §4.6.4 cho phép tối đa 10 lần tra cứu DNS để đánh giá một bản ghi SPF — tính cả các lần tra cứu bên trong mỗi include: một cách đệ quy. Vượt quá sẽ trả về PermError: bản ghi bị coi là không hợp lệ và không cung cấp sự bảo vệ nào.

SPF PermError nghĩa là gì? Một lỗi đánh giá vĩnh viễn — bên nhận không thể xử lý bản ghi của bạn (quá nhiều lần tra cứu, nhiều bản ghi, hoặc cú pháp hỏng) và coi tên miền của bạn như thể không có SPF khả dụng. DMARC tính đó là một thất bại ở nhánh SPF.

Có bao nhiêu tên miền vượt giới hạn tra cứu của SPF? Ít nhất 797,263 trong số 139 triệu nhà phát hành SPF, theo lượt định giá chuỗi của chúng tôi — gấp khoảng 100× con số 7,958 hiện diện mà không cần phân giải chuỗi. Thêm 2,119,539 tên miền nữa nằm ở mức 9–10 lần tra cứu, chỉ cách giới hạn đúng một include.

PermError có làm email của tôi không được gửi đi không? Thường là không — bên nhận vẫn tiếp tục dù không có SPF, và thư của bạn dựa vào DKIM và uy tín. Cái ngừng hoạt động là sự bảo vệ: kẻ giả mạo không còn bị từ chối, và mọi lần kiểm tra DMARC đối với thư của bạn đều mất nhánh SPF. Nó vô hình cho đến khi trở nên tốn kém.

Làm sao để giảm số lần tra cứu SPF của tôi? Loại bỏ các include không dùng và ptr, làm phẳng hạ tầng của chính bạn thành ip4:/ip6:, chuyển người gửi số lượng lớn sang các tên miền phụ, và đếm lại sau mỗi công cụ mới. Hướng dẫn khắc phục sẽ dẫn bạn qua từng bước.

Tìm ra con số thực của bạn

Các cơ chế bạn có thể thấy không phải là số lần tra cứu của bạn — con số đã phân giải mới là con số mà bên nhận tính toán, và đó là một lần kiểm tra 30 giây.

Kiểm tra tên miền của bạn → · Sửa SPF → · Mô hình trưởng thành SPF → · Hai bản ghi SPF = không có bản ghi nào → · Cái bẫy ptr → · Chỉ dữ liệu tổng hợp. Dữ liệu được lưu trữ và xử lý tại EU.