Defaults.Exposed › Cách khắc phục › Guides
SPF PermError: Cách Sửa "Quá Nhiều Tra Cứu DNS" Không Làm Hỏng Email (2026)
Đã xuất bản 2026-07-08
Số liệu tính đến 2026-06-29 · phương pháp luận v7. Dữ liệu tổng hợp từ 261 triệu tên miền được chấm điểm. Xem cách chúng tôi chấm điểm.
Ít nhất 797,263 tên miền vượt quá giới hạn 10 tra cứu DNS của SPF, theo dữ liệu khảo sát 261,086,232 tên miền của Defaults.Exposed — trong số 139 triệu nhà xuất bản SPF. Vượt quá mười tra cứu, máy chủ nhận dừng lại và trả về PermError: SPF của bạn vô hiệu, và DMARC tính PermError là lỗi.
Cách sửa có thứ tự nghiêm ngặt, và hầu hết hướng dẫn làm ngược lại. Đếm số tra cứu thực tế đã phân giải; xóa các includes chết và không dùng — điều đó một mình sửa hầu hết các bản ghi; chuyển người gửi khối lượng lớn sang tên miền con với ngân sách SPF riêng; chỉ phẳng hóa như biện pháp cuối cùng, và chỉ với tự động tái phẳng hóa, vì phẳng hóa tĩnh sẽ mục nát và lặng lẽ phá vỡ việc gửi thư.
”SPF PermError: quá nhiều tra cứu DNS” có nghĩa là gì?
RFC 7208 §4.6.4 giới hạn mỗi kiểm tra SPF ở 10 tra cứu DNS. Vượt qua mười, máy chủ nhận dừng lại và trả về PermError — toàn bộ bản ghi được coi là hỏng, không chỉ phần vượt ngân sách. Cùng phần đó thêm một giới hạn thứ hai ít được biết đến: tối đa 2 “tra cứu void” (truy vấn không trả về kết quả hoặc NXDOMAIN), vì vậy một vài mục include: chết cho các dịch vụ đã hủy có thể tự mình vô hiệu SPF của bạn.
Hậu quả tệ hơn “không có SPF”: DMARC coi PermError là lỗi SPF, vì vậy một tên miền phá vỡ SPF của chính mình là không được xác thực trên chân SPF của mọi đánh giá DMARC. Nếu DKIM không được cài đặt hoặc bị hỏng trong quá trình truyền, thư đó giờ đây hoàn toàn thất bại DMARC.
Một con số khảo sát cho thấy kiểu lỗi này tàn nhẫn như thế nào: 112,215 tên miền xuất bản bản ghi -all strict mà vô hiệu vì tràn tra cứu — trong số 54,655,923 tên miền xuất bản -all. Chủ sở hữu của họ đã làm phần khó — chọn kết thúc strict — và một include thừa đã tắt toàn bộ bản ghi. Họ trông có vẻ strict; họ đang bị hỏng. Để xem bức tranh dữ liệu đầy đủ, xem báo cáo SPF PermError.
Tại sao SPF của tôi hỏng khi tôi không thay đổi gì?
Vì ngân sách chủ yếu được tiêu bởi bản ghi của người khác. Mỗi include: được đánh giá đệ quy, và mỗi cơ chế tra cứu bên trong nó đều tính vào mười của bạn. Một dòng trong bảng điều khiển DNS của bạn có thể tốn bốn hoặc năm tra cứu sau khi phân giải. Một nhà cung cấp lồng thêm một include, và SPF của bạn chết mà không có một thay đổi nào trong vùng của bạn.
Các nền tảng lớn không phải vấn đề: Google và Microsoft đã phẳng hóa SPF của riêng họ — _spf.google.com và spf.protection.outlook.com mở rộng thành danh sách IP thuần tốn không có tra cứu nội bộ (đã xác minh với DNS thực tế, tháng 7/2026). Các sự cố thực tế đến từ chuỗi include trong bảng điều khiển hosting lồng nhau nhiều lớp, và từ việc xếp chồng SaaS trung thực — hộp thư cộng newsletter cộng CRM cộng helpdesk, mỗi cái “chỉ một include”. Không ai cố ý thêm tra cứu thứ mười một; nó đến như tổng của các quyết định hợp lý. Đó là lý do tại sao bờ vực này quá đông: 2,119,539 tên miền nằm ở đúng 9–10 tra cứu đã phân giải — khoảng 1 trong 66 trong tất cả nhà xuất bản SPF, ổn hôm nay, vô hiệu ngày ai đó dán thêm một include. Bản ghi SPF ở phân vị thứ 99 đã phân giải thành 9 tra cứu. Nếu hệ thống của bạn nặng về SaaS, hướng dẫn SPF lỗi cho công cụ SaaS bao gồm phiên bản theo từng nhà cung cấp.
Phần nào của bản ghi SPF tính là tra cứu DNS?
| Cơ chế | Chi phí tra cứu | Ghi chú |
|---|---|---|
include: | 1 + mọi thứ bên trong nó, đệ quy | nơi hầu hết các vụ nổ đến từ |
a | 1 mỗi cái | kể cả a trần cho tên miền của chính bạn |
mx | 1 mỗi cái (cộng tra cứu A của máy chủ MX) | thường bị quên |
ptr | 1 — và đã lỗi thời từ 2014 | xóa bất kể |
exists: | 1 mỗi cái | hiếm |
redirect= | 1 + nội dung bản ghi đích | tính như include |
ip4: / ip6: | 0 | đây là lý do phẳng hóa hoạt động |
-all / ~all / ?all | 0 | qualifier miễn phí |
Đếm tổng đã phân giải, không phải số dòng hiển thị. Bốn includes có thể là bốn tra cứu hoặc mười bốn.
Cách sửa “quá nhiều tra cứu DNS” không làm hỏng email?
- Chạy quét miễn phí trước khi chạm vào DNS. Nó phân giải toàn bộ chuỗi include và hiển thị số tra cứu thực tế, để bạn sửa đúng vấn đề — không phải bản ghi như nó xuất hiện trong bảng điều khiển. (Nếu nó nói bạn không có SPF, đó là lỗi khác — xem “không tìm thấy bản ghi SPF”.)
- Xóa các includes chết và không dùng trước. Công cụ bạn đã bỏ năm 2023, include của máy chủ cũ còn sót lại sau di chuyển, bản sao, cơ chế
ptr. Các includes chết có hại kép: chúng đốt ngân sách tra cứu và thường là nguồn của các tra cứu void. Hầu hết các bản ghi vượt ngân sách trở lại dưới 10 chỉ ở bước này. Nếu bản ghi của bạn vẫn mang cơ chế của nhà cung cấp trước, hãy theo dõi hướng dẫn dọn dẹp sau di chuyển. - Kiểm tra mỗi include còn lại có hoạt động gì không. Máy chủ nhận đánh giá SPF theo tên miền Return-Path (RFC5321.MailFrom), không phải header From — và nhiều công cụ SaaS đặt tên miền bounce của riêng họ trên Return-Path, nên include của họ trong bản ghi của bạn không làm gì ngoài tiêu ngân sách. Chỉ giữ includes cho các dịch vụ dùng tên miền của bạn làm Return-Path; với phần còn lại, bật DKIM tên miền tùy chỉnh của nhà cung cấp.
- Chuyển người gửi khối lượng lớn sang tên miền con. Newsletter từ
news.yourdomain.com, thư giao dịch từmail.yourdomain.com. Mỗi tên miền con có bản ghi SPF riêng với ngân sách 10 tra cứu mới, và vấn đề trong một luồng không còn ảnh hưởng đến các luồng khác. - Chỉ sau đó mới xem xét phẳng hóa — và chỉ phẳng hóa tự động. Xem bên dưới.
- Quét lại để xác nhận bạn thoải mái dưới 10 — hướng đến khoảng dự phòng, không phải đúng 10, nếu không bạn vừa quay lại nhóm 2.1 triệu tên miền trên bờ vực. Sau đó xử lý mọi thứ khác mà quét gắn cờ trên trang sửa SPF.
Có nên phẳng hóa bản ghi SPF không?
Phẳng hóa thay thế các includes bằng các khối ip4:/ip6: cơ bản, không tốn tra cứu. Nó hoạt động — và làm tay, nó là sự cố gửi thư có độ trễ.
| Phương pháp | Số tra cứu | Theo thời gian |
|---|---|---|
| Cắt tỉa + tên miền con (bước 2–4) | Thường trở lại dưới 10 | Ổn định; nhà cung cấp quản lý IP của riêng họ |
| Phẳng hóa tự động (dịch vụ hoặc công việc lập lịch tự động phân giải lại và tái xuất bản) | Gần 0 | Theo dõi thay đổi IP của nhà cung cấp; an toàn |
| Phẳng hóa thủ công một lần | Gần 0 — hôm nay | Mục nát trong im lặng: nhà cung cấp luân chuyển IP, thư hợp lệ bắt đầu lỗi SPF mà không có lỗi nào về phía bạn |
Nhà cung cấp luân chuyển IP gửi thường xuyên và không thông báo cho ai. Danh sách IP tĩnh đúng ngày bạn dán vào và lặng lẽ sai trong vài tháng — và vì lỗi hiển thị là người khác không nhận được thư của bạn, bạn phát hiện muộn. Nếu cắt tỉa và tên miền con đưa bạn xuống dưới giới hạn, dừng ở đó; không bao giờ sao chép thủ công khối IP của bên thứ ba vào bản ghi của bạn như một cách sửa vĩnh viễn.
Câu hỏi thường gặp
SPF PermError có nghĩa là email của tôi ngừng được gửi không? Không ngay lập tức — đó là điều làm nó nguy hiểm. DMARC tính PermError là lỗi SPF, vì vậy việc gửi thư hoàn toàn phụ thuộc vào DKIM; nếu DKIM bị thiếu hoặc hỏng trong quá trình truyền, bạn đang thất bại DMARC. Trong số 139 triệu nhà xuất bản SPF trong khảo sát (tính đến 2026-06-29), ít nhất 797,263 đang ở trạng thái này — hầu hết mà không biết.
Bản ghi của tôi chỉ có bốn includes — làm sao có thể vượt 10 tra cứu? Includes được tính đệ quy: mọi thứ bên trong mỗi include (và bên trong các includes của nó) đều tính vào ngân sách của bạn, vì vậy bốn dòng hiển thị có thể phân giải thành mười bốn tra cứu. Đếm bằng công cụ phân giải, không phải bằng mắt — phân giải các chuỗi là cách báo cáo PermError của chúng tôi tìm thấy ~100× nhiều tên miền hỏng hơn so với đếm bề mặt cho thấy.
Tôi kết thúc bản ghi bằng -all — chắc chắn tôi được bảo vệ chứ?
Chỉ khi bản ghi được đánh giá. Khảo sát của chúng tôi (tính đến 2026-06-29) tìm thấy 112,215 tên miền có bản ghi -all strict bị vô hiệu do tràn tra cứu. Qualifier strict trên bản ghi PermError không bảo vệ gì.
Giới hạn là 10 tra cứu mỗi include hay cho toàn bộ bản ghi? Toàn bộ đánh giá: RFC 7208 §4.6.4 giới hạn kiểm tra hoàn chỉnh ở 10, cộng tối đa 2 tra cứu void. Mỗi tên miền con có bản ghi và ngân sách riêng — đó là lý do bước 4 hoạt động.
Các mục ip4 và ip6 có tính vào giới hạn không? Không — các cơ chế IP không tốn gì, đó chính xác là lý do phẳng hóa giảm số lượng.
Gửi báo cáo cho chủ sở hữu
Nếu bạn đang sửa điều này cho khách hàng hoặc nhà tuyển dụng, hãy hoàn thành công việc với bằng chứng. Chạy lại quét miễn phí sau các thay đổi của bạn và chuyển tiếp báo cáo được chấm điểm cho chủ doanh nghiệp: ngôn ngữ đơn giản, có ngày tháng, PermError đã biến mất. Đó là tài liệu họ cần cho đợt tái tục bảo hiểm mạng và bảng câu hỏi bảo mật khách hàng tiếp theo — sự khác biệt giữa “tôi đã thay đổi một số bản ghi DNS” và tài liệu trước-và-sau.
Kiểm tra tên miền miễn phí
Xem số tra cứu đã phân giải thực tế — và mọi thứ về SPF, DKIM và DMARC — một cách riêng tư và chỉ chủ sở hữu mới thấy.
Kiểm tra tên miền → · Sửa SPF → · SPF lỗi cho công cụ SaaS → · Cài đặt SPF trên GoDaddy → · Cách chúng tôi chấm điểm → · Chỉ dữ liệu tổng hợp. Dữ liệu được lưu trữ và xử lý tại EU.