Defaults.Exposed › Naprawy › Guides

SPF PermError: jak naprawić "Too Many DNS Lookups" bez przerywania poczty (2026)

Opublikowano 2026-07-08

Dane z 2026-06-29 · metodologia v7. Zagregowane dane ze spisu 261 milionów ocenionych domen. Zobacz jak oceniamy.

Co najmniej 797 263 domen przekracza limit 10 wyszukiwań DNS dla SPF, zgodnie ze spisem Defaults.Exposed obejmującym 261 086 232 domen — z 139 milionów wydawców SPF. Po przekroczeniu dziesięciu wyszukiwań odbiorca zatrzymuje się i zwraca PermError: Twój SPF jest nieważny, a DMARC traktuje PermError jako błąd.

Naprawa ma ścisłą kolejność i większość poradników podaje ją od tyłu. Policz rzeczywiste, rozwiązane wyszukiwania; usuń martwe i nieużywane includes — samo to naprawia większość rekordów; przenieś masowych nadawców na subdomeny z własnym budżetem SPF; spłaszczaj tylko w ostateczności i tylko z automatycznym odświeżaniem, bo statyczne spłaszczanie psuje się i po cichu niszczy dostarczalność.

Co oznacza „SPF PermError: too many DNS lookups”?

RFC 7208 §4.6.4 ogranicza każde sprawdzanie SPF do 10 wyszukiwań DNS. Po przekroczeniu dziesięciu odbiorca zatrzymuje się i zwraca PermError — cały rekord jest traktowany jako uszkodzony, nie tylko ta część, która przekracza budżet. Ten sam rozdział dodaje mniej znany drugi limit: co najwyżej 2 „puste wyszukiwania” (zapytania zwracające brak odpowiedzi lub NXDOMAIN), więc kilka martwych wpisów include: dla anulowanych usług może samo w sobie unieważnić SPF.

Konsekwencja jest gorsza niż „brak SPF”: DMARC traktuje PermError jako błąd SPF, więc domena, która niszczy własny SPF, jest nieuwierzytelniona na etapie SPF każdej oceny DMARC. Jeśli DKIM nie jest skonfigurowany lub ulega uszkodzeniu w trakcie przesyłania, poczta teraz wprost nie przechodzi DMARC.

Jedna liczba ze spisu pokazuje, jak okrutny jest ten tryb awarii: 112 215 domen publikuje ścisły rekord -all, który jest nieważny z powodu przekroczenia limitu wyszukiwań — z 54 655 923 domen, które w ogóle publikują -all. Ich właściciele wykonali najtrudniejszy krok — wybrali ścisłe zakończenie — i jeden dodatkowy include wyłączył cały rekord. Wyglądają na surowe; są zepsute. Pełny obraz danych znajdziesz w raporcie SPF PermError.

Dlaczego mój SPF przestał działać, gdy nic nie zmieniałem?

Ponieważ budżet jest w większości wydawany przez rekordy innych ludzi. Każdy include: jest oceniany rekurencyjnie, a każdy mechanizm wyszukiwania wewnątrz niego liczy się do Twojego budżetu dziesięciu. Jedna linia w Twoim panelu DNS może kosztować cztery lub pięć wyszukiwań po rozwiązaniu. Dostawca zagnieżdża jeszcze jeden include i Twój SPF umiera bez jednej zmiany w Twojej strefie.

Duże platformy nie są problemem: Google i Microsoft oba spłaszczyły własny SPF — _spf.google.com i spf.protection.outlook.com rozwijają się do zwykłych list IP kosztujących zero wewnętrznych wyszukiwań (zweryfikowane w aktywnym DNS, lipiec 2026). Rzeczywiste przekroczenia limitu pochodzą z zagnieżdżonych kilka poziomów głęboko łańcuchów includes paneli hostingowych oraz ze zwykłego nakładania SaaS — skrzynka pocztowa plus newsletter plus CRM plus helpdesk, każdy „tylko jeden include”. Nikt celowo nie dodaje jedenastego wyszukiwania; pojawia się jako suma rozsądnych decyzji. Dlatego krawędź jest tak zatłoczona: 2 119 539 domen ma dokładnie 9–10 rozwiązanych wyszukiwań — mniej więcej 1 na 66 wszystkich wydawców SPF, dziś w porządku, nieważnych w dniu, gdy ktoś wklei jeszcze jeden include. 99. percentyl rekordu SPF rozwiązuje się już do 9 wyszukiwań. Jeśli Twój stos jest mocno oparty na SaaS, przewodnik o SPF niezaliczającym dla narzędzi SaaS opisuje wersję od dostawcy do dostawcy.

Które części rekordu SPF liczą się jako wyszukiwania DNS?

Licz rozwiązaną sumę, a nie widoczne linie. Cztery includes mogą oznaczać cztery wyszukiwania lub czternaście.

Jak naprawić „too many DNS lookups” bez psowania poczty?

1. Uruchom bezpłatne skanowanie przed dotykaniem DNS. Rozwiązuje pełny łańcuch includes i pokazuje rzeczywistą liczbę wyszukiwań, abyś naprawił rzeczywisty problem — nie rekord taki, jaki widzi panel. (Jeśli mówi, że nie masz w ogóle SPF, to inny błąd — patrz „SPF record not found”.)
2. Najpierw usuń martwe i nieużywane includes. Narzędzie, które porzuciłeś w 2023 r., include starego hosta, który przeżył migrację, duplikaty, wszelkie mechanizmy ptr. Martwe includes są podwójnie toksyczne: spalają budżet wyszukiwań i są zwykłym źródłem pustych wyszukiwań. Większość przeciążonych rekordów wraca poniżej 10 tylko w tym kroku. Jeśli Twój rekord nadal zawiera mechanizmy poprzedniego dostawcy, skorzystaj z przewodnika czyszczenia po migracji.
3. Sprawdź, czy każdy pozostały include cokolwiek robi. Odbiorcy oceniają SPF względem domeny Return-Path (RFC5321.MailFrom), a nie nagłówka From — a wiele narzędzi SaaS umieszcza własną domenę bounce w Return-Path, więc ich include w Twoim rekordzie nic nie robi poza spalaniem budżetu. Zachowaj includes tylko dla usług, które używają Twojej domeny jako Return-Path; dla pozostałych włącz własny DKIM dostawcy z niestandardową domeną.
4. Przenieś masowych nadawców na subdomeny. Newslettery z news.yourdomain.com, poczta transakcyjna z mail.yourdomain.com. Każda subdomena ma własny rekord SPF z nowym budżetem 10 wyszukiwań, a problem w jednym strumieniu przestaje przenosić się na inne.
5. Dopiero wtedy rozważ spłaszczanie — i tylko automatyczne spłaszczanie. Patrz poniżej.
6. Ponów skanowanie, aby potwierdzić, że jesteś wygodnie poniżej 10 — celuj w zapas, nie w dokładnie 10, bo w przeciwnym razie ponownie dołączyłeś do 2,1 milionów domen na krawędzi. Następnie zajmij się wszystkim innym, co zaznacza skanowanie na stronie naprawy SPF.

Czy powinienem spłaszczyć rekord SPF?

Spłaszczanie zastępuje includes ich bazowymi blokami ip4:/ip6:, które kosztują zero wyszukiwań. Działa — i zrobione ręcznie, to opóźniona awaria dostarczalności.

Dostawcy regularnie rotują wysyłkowe IP i nikomu tego nie ogłaszają. Statyczna lista IP jest poprawna w dniu, kiedy ją wklejasz, i po cichu błędna po kilku miesiącach — a ponieważ awaria objawia się tym, że inni ludzie nie otrzymują Twojej poczty, dowiadujesz się o tym późno. Jeśli przycinanie i subdomeny sprowadzają Cię poniżej limitu, zatrzymaj się tam; nigdy nie kopiuj ręcznie bloków IP stron trzecich do swojego rekordu jako stałego rozwiązania.

Często zadawane pytania

Czy SPF PermError oznacza, że moja poczta przestaje być dostarczana? Nie natychmiast — i to właśnie sprawia, że jest niebezpieczny. DMARC traktuje PermError jako błąd SPF, więc dostarczalność opiera się wyłącznie na DKIM; jeśli DKIM brakuje lub ulega uszkodzeniu w trakcie przesyłania, nie przechodzisz DMARC. Z 139 milionów wydawców SPF w naszym spisie (według stanu na 2026-06-29), co najmniej 797 263 jest w tym stanie — większość bez wiedzy.

Mój rekord ma tylko cztery includes — jak może przekraczać 10 wyszukiwań? Includes są liczone rekurencyjnie: wszystko wewnątrz każdego include (i wewnątrz jego includes) jest doliczane do Twojego budżetu, więc cztery widoczne linie mogą się rozwiązać do czternastu wyszukiwań. Licz za pomocą narzędzia rozwiązującego, a nie na oko — rozwiązywanie łańcuchów to sposób, w jaki nasz raport PermError znalazł ~100× więcej zepsutych domen niż pokazują powierzchowne liczenia.

Kończę rekord z -all — czy to nie zapewnia ochrony? Tylko jeśli rekord jest oceniany. Nasz spis (według stanu na 2026-06-29) znalazł 112 215 domen, których ścisłe rekordy -all są nieważne z powodu przekroczenia limitu wyszukiwań. Ścisły kwalifikator na rekordzie z PermError niczego nie chroni.

Czy limit to 10 wyszukiwań na include czy dla całego rekordu? Dla całej oceny: RFC 7208 §4.6.4 ogranicza kompletne sprawdzanie do 10, plus co najwyżej 2 puste wyszukiwania. Każda subdomena ma własny rekord i własny budżet — dlatego krok 4 działa.

Czy wpisy ip4 i ip6 liczą się do limitu? Nie — mechanizmy IP nic nie kosztują, i właśnie dlatego spłaszczanie zmniejsza liczbę.

Wyślij właścicielowi raport

Jeśli naprawiasz to dla klienta lub pracodawcy, zakończ pracę z dowodem. Ponów bezpłatne skanowanie po zmianach i prześlij oceniony raport właścicielowi firmy: w prostym języku, z datą, PermError zniknął. To artefakt, który będzie mu potrzebny przy przedłużaniu ubezpieczenia cybernetycznego i następnym kwestionariuszu bezpieczeństwa klienta — różnica między „zmieniłem kilka rekordów DNS” a udokumentowanym porównaniem przed i po.

Sprawdź swoją domenę bezpłatnie

Zobacz swoją rzeczywistą, rozwiązaną liczbę wyszukiwań — i wszystko inne dotyczące SPF, DKIM i DMARC — prywatnie i tylko dla właściciela.

Sprawdź swoją domenę → · Napraw SPF → · SPF niezaliczający dla narzędzi SaaS → · Skonfiguruj SPF w GoDaddy → · Jak oceniamy → · Tylko dane zagregowane. Dane przechowywane i przetwarzane w UE.