Defaults.Exposed › Naprawy › Guides

"SPF Record Not Found" — masz rekord, a mimo to błąd? 5 prawdziwych przyczyn (2026)

Opublikowano 2026-07-08

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

Jeśli narzędzie do sprawdzania mówi „SPF record not found”, a masz pewność, że opublikowałeś rekord, to zazwyczaj jest on niewidoczny, a nie brakujący: 1 013 416 domen — mniej więcej jedna na 138 spośród tych, które próbują używać SPF — publikuje dwa lub więcej rekordów SPF, co jest PermError (RFC 7208 §3.2), który wiele narzędzi raportuje jako nie znaleziono, zgodnie ze spisem Defaults.Exposed obejmującym 261 milionów domen.

Istnieje pięć prawdziwych przyczyn, które można naprawić podczas jednej sesji: zły host, zduplikowany rekord, nieprawidłowy typ DNS lub zniekształcone cudzysłowy, niespójne serwery nazw albo kolizja długości/CNAME. Poniżej znajdziesz 60-sekundowy test dla każdej przyczyny — w kolejności, w jakiej należy je sprawdzać — oraz kroki naprawcze.

Czy masz pewność, że rekord naprawdę istnieje?

Zacznij od tej mało pochlebnej możliwości, bo jest zdecydowanie najczęstsza: z 261 086 232 domen ocenionych w spisie Defaults.Exposed 121 145 609 — 46,4% — nie ma w ogóle rekordu SPF. Wiele przypadków „ale przecież to ustawiłem” okazuje się być rekordem dodanym do strefy testowej lub do starego dostawcy DNS, który nie jest już autorytatywny. Sprawdź u dostawcy DNS, na który rzeczywiście wskazują Twoje serwery nazw (często nie jest to Twój rejestrator domen), czy istnieje rekord TXT zaczynający się od v=spf1. Jeśli naprawdę go nie ma, pomijaj krok detektywistyczny i przejdź bezpośrednio do naprawy rekordu SPF.

Jak prawidłowo sprawdzić rekord SPF?

Narzędzia webowe odpytują DNS przez własny resolver z pamięcią podręczną. Żeby zobaczyć prawdę, zapytaj bezpośrednio autorytatywny serwer nazw Twojej domeny:

# znajdź autorytatywne serwery nazw
dig NS yourdomain.com +short

# zapytaj jeden z nich bezpośrednio o rekordy TXT
dig TXT yourdomain.com @ns1.yourdnshost.com +short

W systemie Windows: nslookup -type=TXT yourdomain.com ns1.yourdnshost.com.

Dwie zasady interpretacji. Po pierwsze, policz linie zaczynające się od v=spf1 — liczba liczy się tak samo jak treść. Po drugie, upewnij się, że zapytałeś o właściwą nazwę: odbiorcy sprawdzają SPF względem domeny w Return-Path (RFC5321.MailFrom, tzw. „envelope from”) — nie adresu From widocznego dla odbiorców. Jeśli Twoje narzędzie do newsletterów odbija pocztę przez bounce.yourdomain.com, idealny rekord przy wierzchołku domeny nie jest tym, czego szukają odbiorcy.

Jakie są pięć prawdziwych przyczyn?

Dane z 2026-06-29.

1. Czy rekord jest w złym hoście?

Klasyczny przypadek: SPF dodany do mail.yourdomain.com, gdy poczta twierdzi, że pochodzi z yourdomain.com, lub odwrotnie. SPF nie jest dziedziczony w dół — rekord przy wierzchołku domeny nic nie mówi o subdomenach i odwrotnie. Publikuj dokładnie w miejscu odpowiadającym Return-Path. Dostawca wysyłający z własnej subdomeny bounce musi mieć rekord na tej subdomenie — zazwyczaj CNAME lub TXT dostarczony przez dostawcę (w przewodniku konfiguracji SPF dla GoDaddy pokazano, gdzie te pola się znajdują).

2. Czy masz dwa rekordy SPF?

To główna przyczyna — i najbardziej mylący komunikat błędu w uwierzytelnianiu poczty. RFC 7208 §3.2 jest jednoznaczny: domena musi mieć dokładnie jeden rekord SPF. Dwa lub więcej to PermError — odbiorcy traktują Twój SPF jako nieważny. Niektóre narzędzia raportują ten stan precyzyjnie (“multiple records found”); inne raportują efekt: brak ważnego rekordu SPF. Widzisz rekord w swoim panelu i dochodzisz do wniosku, że narzędzie jest zepsute. Nie jest — masz o jeden rekord za dużo.

Spis wykrył 1 013 416 domen z dwoma lub więcej rekordami SPF — mniej więcej jeden na 138 spośród domen próbujących używać SPF — każda z nich ma skutecznie wyłączony SPF. Zwykle dzieje się tak podczas zmiany dostawcy: kreator nowego dostawcy dodaje nowy rekord zamiast edytować stary. Naprawą jest scalenie, nigdy drugi rekord: połącz wszystko w jedną linię v=spf1 … ~all i usuń resztę. Nasz raport dwa rekordy SPF to żaden rekord wyjaśnia, jak milion domen tu doszło; jeśli problem pojawił się po migracji, sprawdź SPF przestało działać po zmianie dostawcy. Podczas scalania nie łącz ślepo wszystkich include: — każdy kosztuje jedno wyszukiwanie DNS wliczane do twardego limitu 10 dla SPF, zamieniając „nie znaleziono” na PermError: zbyt wiele wyszukiwań DNS.

3. Czy opublikowałeś zły typ rekordu — lub UI go zniekształcił?

Wczesny SPF miał własny typ rekordu DNS (typ 99, dosłownie nazwany „SPF”). Został on wycofany: RFC 7208 wymaga TXT, a odbiorcy nie odpytują typu 99. Niektóre panele DNS nadal oferują „SPF” w liście rozwijalnej typów rekordów; jeśli go wybierzesz, Twój rekord jest prawdziwy, poprawnie sformułowany i niewidoczny. Sprawdź kolumnę typu i ponownie opublikuj jako TXT.

Subtelny wariant to cudzysłowy. Wklejenie wartości opatrzonej cudzysłowami do pola, które samo dodaje cudzysłowy, powoduje ""v=spf1 …"" — co już nie zaczyna się od v=spf1, więc dla weryfikatora nie istnieje. Wynik dig pokazuje prawdę; panel DNS często to kosmetycznie ukrywa.

4. Czy to naprawdę „ciągle się propaguje”?

„Daj mu 24–48 godzin na propagację” to najczęściej nadużywana rada w dziedzinie DNS. Propagacja to tylko wygasanie pamięci podręcznych: gdy minie TTL rekordu (zazwyczaj 1 godzina, rzadko ponad 24), każdy resolver widzi nową odpowiedź. Nadal nie znaleziono po 24 godzinach? Propagacja nie jest przyczyną.

Dwa prawdziwe winowajce: ujemne buforowanie — resolver, który szukał Cię przed dodaniem rekordu, buforuje odpowiedź „brak takiego rekordu” do wygaśnięcia ujemnego TTL — oraz niespójne serwery nazw po migracji, gdzie domena nadal wyświetla serwery nazw starego dostawcy obok nowych, a połowa świata odczytuje strefę, której już nie edytujesz. Zapytaj każdy wymieniony serwer nazw bezpośrednio; jeśli odpowiedzi się różnią, znalazłeś problem. Napraw delegację NS u rejestratora, tak żeby tylko faktycznie edytowany dostawca był autorytatywny.

5. Czy rekord jest za długi albo blokowany przez CNAME?

Jeden ciąg w rekordzie TXT może mieć maksymalnie 255 znaków. Dłuższe rekordy SPF są dozwolone, ale muszą być podzielone na wiele cytowanych ciągów w obrębie jednego rekordu — a interfejsy dostawców DNS regularnie to psują, obcinając wartość lub łamiąc ją w połowie mechanizmu, przez co przestaje być parsowalna. Jeśli Twój rekord jest długi, sprawdź wynik dig pod kątem wartości urwanej w połowie.

Oddzielnie, DNS zabrania rekordu TXT pod nazwą, która ma już CNAME. Jeśli mail.yourdomain.com jest CNAME do Twojego dostawcy, nie możesz tam też umieścić SPF — niektóre panele to akceptują, a następnie serwują tylko CNAME. Umieść rekord tam, gdzie wskazuje CNAME (jeśli kontrolujesz ten cel), albo przebuduj strukturę tak, żeby nazwa wysyłkowa nie miała CNAME. Dostawcy z czytelną obsługą TXT ułatwiają jedno i drugie — zobacz przewodnik konfiguracji SPF dla Cloudflare.

Jak to naprawić krok po kroku?

1. Uruchom bezpłatne skanowanie na defaults.exposed — odczyta Twoje aktywne DNS i wskaże, w którym z pięciu stanów się znajdujesz, zanim cokolwiek zmienisz.
2. Potwierdź, które serwery nazw są autorytatywne (dig NS) i czy wszystkie się zgadzają.
3. Odpytaj TXT na autorytatywnym serwerze nazw dla dokładnej domeny Return-Path.
4. Policz linie v=spf1: zero → opublikuj jeden; dwa lub więcej → scal do jednego.
5. Sprawdź, czy typ to TXT, wartość zaczyna się dokładnie od v=spf1 i czy nie pojawiły się zbędne cudzysłowy ani obcięcie.
6. Poczekaj jeden TTL, a następnie ponów skanowanie, aby potwierdzić poprawne rozwiązywanie wszędzie.

Często zadawane pytania

Dlaczego narzędzie mówi „not found”, skoro widzę rekord w panelu DNS? Zazwyczaj przyczyna 2 lub 4: drugi rekord v=spf1 sprawia, że oba są nieważne — PermError, który niektóre narzędzia raportują jako nie znaleziono, i w którym jest 1 013 416 domen według stanu na 2026-06-29 — albo Twój panel nie jest tym DNS, który jest faktycznie autorytatywny.

Jak długo zanim narzędzia zobaczą moją poprawkę? Jeden TTL — zazwyczaj godzina, maksymalnie 24. Po tym czasie „propagacja” nie jest wyjaśnieniem; ponownie sprawdź pięć przyczyn, zaczynając od spójności serwerów nazw.

Czy powinienem używać typu rekordu „SPF”, który oferuje mój panel DNS? Nie. Typ 99 jest wycofany; RFC 7208 wymaga wyłącznie TXT. Rekord typu 99 jest niewidoczny dla nowoczesnych odbiorców.

Rekord jest już znaleziony — dlaczego poczta nadal nie przechodzi SPF? Ponieważ SPF jest sprawdzany względem domeny Return-Path, a nie nagłówka From, i rekord musi faktycznie wymieniać serwery, które wysyłają dla Ciebie. Znaleziony to krok pierwszy; przewodnik naprawy rekordu SPF wyjaśnia, jak przejść weryfikację.

Czy brak rekordu SPF jest naprawdę tak powszechny? Tak — 121 145 609 domen, 46,4% z 261 086 232 ocenionych w spisie Defaults.Exposed (według stanu na 2026-06-29), nie publikuje w ogóle SPF. Brak rekordu to domyślny stan internetu.

Wyślij właścicielowi raport

Gdy rekord rozwiązuje się poprawnie, ponów skanowanie i prześlij oceniony raport właścicielowi firmy lub klientowi, do którego należy ta domena. Pokazuje on — w prostym języku — co było zepsute, co naprawiłeś i gdzie domena się teraz znajduje — dokładnie takie dowody, jakich będą wymagać przy przedłużaniu ubezpieczenia cybernetycznego i kwestionariuszach bezpieczeństwa dostawców. Raport to pokwitowanie wykonanej pracy.

Sprawdź swój rekord SPF bezpłatnie

Sprawdź, w którym z pięciu stanów „nie znaleziono” jest Twoja domena — prywatnie i tylko dla właściciela.

Sprawdź swoją domenę → · Napraw SPF → · SPF przestało działać po zmianie dostawcy → · Jak oceniamy → · Tylko dane zagregowane. Dane przechowywane i przetwarzane w UE.