Defaults.Exposed › Raporty

Dlaczego mój SPF nie działa? Problem 10 zapytań DNS w środowiskach SaaS dla nadawców z UK i UE (2026)

Opublikowano 2026-07-09

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

Gdy SPF przestaje działać w firmie korzystającej z narzędzi SaaS w UK lub UE, najbardziej prawdopodobną przyczyną jest jedna reguła RFC, o której nigdy nie musiałeś myśleć: po przekroczeniu 10 zapytań DNS SPF nie zwraca „fail” — zwraca PermError, co oznacza, że rekord jest traktowany tak, jakby nie istniał. Co najmniej 797 263 domen już przekroczyło tę granicę. Kolejne 2 119 539 znajduje się dokładnie na poziomie 9–10 zapytań — jedno nowe narzędzie dzieli je od tej samej przepaści.

Dlaczego SPF przestaje działać po dodaniu narzędzia SaaS?

SPF działa przez wylistowanie serwerów pocztowych upoważnionych do wysyłania wiadomości w imieniu Twojej domeny. Nowoczesne firmy nie prowadzą własnych serwerów pocztowych — używają Google Workspace do wewnętrznej poczty, Mailchimp do kampanii, HubSpot do sekwencji sprzedażowych, Pipedrive do działań CRM. Każda platforma podaje Ci linię include: do wklejenia do DNS.

Problem: każde include: to samo w sobie jedno zapytanie DNS. A każdy rekord wewnątrz tego include może rekurencyjnie wyzwalać kolejne zapytania. RFC 7208 §4.6.4 ustala twardy limit dziesięciu. Po jego przekroczeniu odbierający serwer pocztowy przestaje oceniać i zwraca PermError — a PermError to nie jest łagodny błąd, który trafia do spamu. Oznacza, że Twój rekord SPF jest traktowany jako nieobecny. Uwierzytelnianie poczty e-mail nie przechodzi etapu SPF.

Nie zobaczysz tego w swoim panelu DNS. Licznik uruchamia się tylko podczas oceny na żywo. Możesz mieć trzy linie include: w widocznym rekordzie i nadal sięgać dwanaście zapytań w głąb, ponieważ rekord SPF każdego dostawcy sam ściąga własne pod-include.

Ile domen już przekroczyło limit?

Co najmniej 797 263. To liczba po rozwiązaniu każdego celu SPF include:, który jest odwoływany 100 lub więcej razy — 10 842 odrębnych celów pokrywających 95,2% wszystkich odwołań do include — i wycenieniu pełnego łańcucha każdej domeny. Liczba powierzchniowa (znaleziona przez zliczenie tylko widocznych linii w rekordzie) wynosi około 7958. Liczba wyceniona łańcuchowo jest 100 razy większa, ponieważ prawie wszystkie szkody są niewidoczne wewnątrz celów include.

Sytuacja, która najczęściej dotyka europejskie firmy:

Europejscy dostawcy hostingu i słabe domyślne ustawienia SPF

Dostawca hostingu, od którego zacząłeś, ma znaczenie — ponieważ niektórzy ustawiają domyślne ustawienia SPF, które już zużywają kilka z Twoich dziesięciu zapytań, zanim podłączysz jakiekolwiek narzędzie SaaS.

Wśród największych dostawców hostingu używanych przez europejskie domeny w naszym spisie:

IONOS wyróżnia się: 1,0% domen hostowanych przez IONOS ma wymuszający DMARC, co oznacza, że zdecydowana większość nie ma żadnego sensownego uwierzytelniania nadawcy. Domeny OVH radzą sobie lepiej w kwestii ścisłego SPF (43,7%), ale i tak spadają do 2,2% jeśli chodzi o wymuszanie DMARC — sam SPF bez DMARC powiązanego z nagłówkiem From: chroni tylko kopertę, nie to, co widzi odbiorca.

Microsoft 365 jest pozytywnym wyjątkiem: 85,0% domen hostowanych przez Microsoft używa ścisłego SPF, głównie dlatego, że kreator przepływu poczty Microsoftu domyślnie ustawia -all. Google Workspace domyślnie ustawia ~all (softfail), pozostawiając 92% swoich domen bez ścisłej ochrony.

Jak zdiagnozować błąd SPF w mniej niż 60 sekund

Najszybsza weryfikacja to bezpłatne narzędzie oceniające pełny łańcuch zapytań — nie tylko widoczny rekord. Uruchom nslookup -type=TXT twojadomema.com w wierszu poleceń i policz każde include:, które widzisz. Następnie sprawdź każdy z tych rekordów i policz ich include. Jeśli skończą Ci się palce zanim skończą się include, jesteś w strefie zagrożenia.

Bardziej niezawodne podejście: sprawdź swoją domenę tutaj — skaner ocenia pełny rozwiązany łańcuch, oznacza PermError i pokazuje, które mechanizmy zużywają Twój budżet zapytań.

Trzy wyniki diagnostyczne:

• PermError — już przekroczyłeś dziesięć. Każda wysłana wiadomość e-mail nie przechodzi kontroli SPF u odbiorcy.
• Na poziomie 9–10 zapytań — jesteś na krawędzi. Następna integracja SaaS przesunie Cię za linię.
• Softfail (~all) zamiast hardfail (-all) — jesteś poniżej limitu, ale rekord jest ustawiony zbyt permisywnie, aby zapewniać prawdziwą ochronę. Zobacz raport o błędnej konfiguracji SPF po pełny obraz różnicy między -all a ~all.

Jak naprawić SPF, gdy używasz wielu narzędzi SaaS

Istnieją trzy podejścia, w kolejności trwałości:

1. Audyt i oczyszczenie. Zacznij od wylistowania każdego include: w bieżącym rekordzie. Usuń wszystkie platformy, których już nie używasz — stare ESP, narzędzia CRM z poprzednich umów, platformy, które testowałeś, ale porzuciłeś. Jest to bezpłatne i często odzyskuje kilka zapytań. Każde usunięte include: może wyeliminować 1–3 pod-zapytania.

2. Spłaszczenie rekordu SPF. Spłaszczanie SPF rozwiązuje wszystkie cele include: do ich bazowych zakresów IP i zapisuje je bezpośrednio w rekordzie jako mechanizmy ip4: i ip6:. Mechanizmy IP nie wyzwalają zapytań, więc spłaszczony rekord może wylistować dziesiątki źródeł wysyłania i nadal utrzymywać zero zapytań. Wadą jest konieczność ponownego spłaszczania za każdym razem, gdy dostawca aktualizuje swoje adresy IP do wysyłania, co dzieje się bez powiadomienia. Większość firm korzysta z płatnej usługi spłaszczania SPF (PowerDMARC, EasyDMARC, Dmarcian i inne oferują to) lub buduje przepływ pracy monitorowania.

3. Użycie makr SPF. Makra RFC 7208 pozwalają budować rekordy, które wykonują jedno zapytanie DNS na weryfikację i odpowiadają dynamicznie, zamiast łańcucha include. Makra wymagają obsługi hostingu DNS i pewnego nakładu wdrożeniowego, ale są architektonicznie czystym rozwiązaniem dla organizacji z wieloma nadawcami SaaS.

Po naprawieniu SPF, powiąż je z wymuszaniem DMARC — SPF bez DMARC uwierzytelnia tylko nadawcę koperty, nie adres From: w nagłówku, który widzą odbiorcy.

Często zadawane pytania

Dlaczego mój rekord SPF przechodzi weryfikację w narzędziu DNS, ale nadal nie działa w nagłówkach e-maili? Większość narzędzi do wyszukiwania DNS liczy tylko mechanizmy widoczne w Twoim własnym rekordzie, a nie pod-zapytania, które te mechanizmy wyzwalają. Możesz mieć dwie linie include: i nadal być powyżej limitu, jeśli rekord każdego dostawcy zawiera kolejne kilka. Tylko narzędzie wyceniające łańcuch (lub odbierający serwer pocztowy) liczy pełną głębokość. Sprawdź swoją domenę aby zobaczyć rzeczywistą liczbę w łańcuchu.

Czy niepowodzenie SPF oznacza, że moje e-maile trafiają do spamu? PermError (zbyt wiele zapytań) oznacza, że etap SPF uwierzytelniania zwraca wynik nierozstrzygający — faktycznie nieobecny. DMARC ocenia zarówno SPF jak i DKIM; jeśli DKIM przejdzie, DMARC może mimo to przejść pomimo PermError SPF. Jeśli żadne z nich nie przejdzie, DMARC nie powiedzie się, a wynik zależy od Twojej polityki DMARC. Przy p=none e-mail nadal jest dostarczany, ale błąd jest rejestrowany. Przy p=quarantine lub p=reject e-mail jest filtrowany lub odrzucany. Napraw SPF, aby nie polegać wyłącznie na DKIM.

Ile zapytań zużywa typowy stos SaaS? Rekord SPF p99 w naszym spisie już wynosi 9 zapytań — dokładnie na granicy — zanim cokolwiek zostanie dodane. Rekord Google Workspace dodaje 3–4 zapytania; Mailchimp dodaje 1–2; HubSpot dodaje 1–3 w zależności od jego bieżącej konfiguracji. Trzy główne narzędzia plus domyślne ustawienie dostawcy hostingu często wystarczają, aby przekroczyć dziesięć.

Czy spłaszczanie SPF jest bezpieczne? Tak, pod warunkiem że jest aktualne. Spłaszczanie konwertuje łańcuchy include: na statyczne zakresy IP — jeśli dostawca zmienia swoje adresy IP do wysyłania, a Ty nie wykonujesz ponownego spłaszczania, zaczniesz odrzucać jego pocztę. Większość organizacji korzysta z zarządzanej usługi spłaszczania, która monitoruje zmiany IP, zamiast utrzymywać to ręcznie.

Mój SPF jest taki od lat — dlaczego nagle przestaje działać? Ponieważ Twoi dostawcy zaktualizowali swoje rekordy SPF, nie Twój. Za każdym razem gdy platforma SaaS dodaje nowy zakres IP do wysyłania lub zagnieżdża kolejne include, koszt łańcucha rośnie bez żadnych zmian z Twojej strony. Limit 10 zapytań jest oceniany na żywo przy odbiorze wiadomości, więc zmiana u dostawcy we wtorek rano może zepsuć Twój SPF we wtorek po południu.

Czy naprawienie SPF poprawia dostarczalność e-maili? Usuwa źródło błędu uwierzytelniania, co jest warunkiem wstępnym dla spójnego dostarczania — zwłaszcza że Google i Yahoo teraz wymuszają zgodność DMARC dla nadawców masowych. Sam SPF nie jest całym obrazem: połącz go z DKIM i DMARC dla pełnego uwierzytelniania poczty e-mail.

Sprawdź swój SPF bezpłatnie

Jeśli nie jesteś pewien, czy Twój rekord SPF przekracza limit zapytań — lub jest ustawiony zbyt słabo, aby chronić Twoją domenę — wykonaj bezpłatną weryfikację. Ocenia ona pełny rozwiązany łańcuch i pokazuje dokładnie, gdzie budżet jest zużywany.

Sprawdź swoją domenę → · Napraw SPF → · Raport SPF PermError → · Raport o błędnej konfiguracji SPF → · Model dojrzałości adopcji SPF → · Napraw DMARC → · Wyłącznie dane zagregowane. Dane przechowywane i przetwarzane w UE.