Generator Rekordu SPF

Czym Jest Rekord SPF?

Rekord SPF (Sender Policy Framework, RFC 7208) to rekord TXT w Twojej domenie, który wymienia serwery uprawnione do wysyłania z niej poczty. Gdy wiadomość dociera, serwer odbiorcy pobiera rekord SPF domeny nadawcy z koperty (Return-Path, a nie widocznego adresu From) i sprawdza, czy adres IP nadawcy jest na liście.

Domena może mieć tylko jeden rekord SPF. Dwa rekordy zaczynające się od v=spf1 sprawiają, że każde sprawdzenie SPF kończy się błędem PermError, więc dodając nową usługę, edytujesz istniejący rekord zamiast dodawać kolejny. Od lutego 2024 r. Gmail i Yahoo oczekują, że każdy nadawca używa SPF lub DKIM, a nadawcy masowi SPF, DKIM i DMARC jednocześnie.

Jak Utworzyć Rekord SPF

Składnia Rekordu SPF

Rekord SPF to lista elementów odczytywanych od lewej do prawej. Pierwszy, który pasuje do adresu IP nadawcy, decyduje o wyniku.

~all czy -all: Soft Fail czy Fail?

-all informuje odbiorców, że poczta z każdego niewymienionego serwera nie przechodzi SPF (fail), a wielu z nich ją odrzuci. ~all oznacza ją jako soft fail: odbiorcy nie powinni odrzucać jej tylko z tego powodu, ale mogą traktować ją jako podejrzaną. ?all jest neutralne i nie daje żadnej ochrony.

Instrukcje Google dla Workspace używają ~all, a przykład Microsoftu dla Microsoft 365 używa -all. Oba działają. Gdy opublikujesz DMARC, to polityka DMARC (p=quarantine lub p=reject) decyduje o losie poczty, która nie przejdzie weryfikacji, dlatego wiele domen zostaje przy ~all, by nie odrzucać prawidłowej poczty przekazywanej dalej, i zostawia egzekwowanie DMARC. Jeśli domena w ogóle nie wysyła e-maili, opublikuj v=spf1 -all.

Przykłady Rekordów SPF

Skopiuj przykład najbliższy Twojej konfiguracji lub zbuduj własny rekord w generatorze powyżej. Każdy z nich to pojedynczy rekord TXT w Twojej domenie.

Limit 10 Zapytań DNS

RFC 7208 ogranicza sprawdzenie SPF do 10 zapytań DNS. Każdy include, a, mx, ptr, exists i redirect kosztuje jedno, podobnie jak każdy z nich wewnątrz dołączanych rekordów. ip4, ip6 i all są darmowe. Sprawdzenie, które wymaga 11. zapytania, kończy się błędem PermError, który dla DMARC liczy się jako niepowodzenie SPF. Odbiorcy powinni też dopuszczać nie więcej niż 2 puste zapytania (void lookups: nazwy, które nie istnieją lub nie zwracają rekordów).

Dostawcy nie kosztują tyle samo. Policzyliśmy każdy include 5 października 2026 r., łącznie z zapytaniami zagnieżdżonymi:

Jak Naprawić Rekord SPF ze Zbyt Dużą Liczbą Zapytań

• Usuń usługi, których już nie używasz. Zwykle winne są stare narzędzia do newsletterów i konta testowe.

• Zastąp `a` i `mx` przez `ip4`/`ip6`, gdy Twoje serwery mają stałe adresy.

• Przenieś pocztę masową na subdomenę, np. news.example.com, z własnym rekordem SPF i własnymi 10 zapytaniami.

• Sprawdź, czy usługa w ogóle potrzebuje include. Wielu nadawców używa własnej domeny zwrotnej (bounce), więc SPF przechodzi na ich domenie, a wyrównanie DMARC zapewnia DKIM.

• Uważaj na spłaszczanie SPF (flattening). Zastąpienie include skopiowanymi listami IP działa do czasu, aż dostawca zmieni swoje adresy IP, a wtedy poczta bez ostrzeżenia przestaje przechodzić SPF.

Typowe Błędy SPF

• Dwa rekordy SPF w tej samej domenie, np. po jednym na dostawcę. Połącz je w jeden.

• Używanie +all, które autoryzuje cały internet.

• Publikowanie rekordu pod złą nazwą. SPF jest sprawdzany dla domeny nadawcy z koperty, a subdomeny go nie dziedziczą.

• Dodawanie mechanizmów po all. Odbiorcy nigdy ich nie sprawdzają, więc ci nadawcy nie są autoryzowani.

• Pominięcie nadawcy, np. serwera WWW, który wysyła wiadomości z formularza kontaktowego.

• Używanie starego typu rekordu SPF (typ 99). RFC 7208 go wycofał: publikuj tylko TXT.

SPF, DKIM i DMARC Działają Razem

Sam SPF nie powstrzyma nikogo przed podrobieniem adresu From, który widzą Twoi odbiorcy. DKIM podpisuje każdą wiadomość, a DMARC wiąże oba mechanizmy z widoczną domeną From i mówi odbiorcom, co zrobić, gdy weryfikacja się nie powiedzie. Skonfiguruj wszystkie trzy: