Narzędzie do sprawdzania i generowania rekordu SPF

Jak sprawdzić rekord SPF

1. Wpisz nazwę domeny w polu powyżej. Pełny adres e-mail również zadziała – narzędzie automatycznie wyodrębni samą domenę.
2. Kliknij Sprawdź rekord SPF. Narzędzie odpytuje publiczne serwery DNS w taki sam sposób, w jaki robi to serwer pocztowy odbiorcy.
3. Najpierw sprawdź podsumowanie. Informuje ono, czy rekord jest prawidłowy, zawiera ostrzeżenia czy jest uszkodzony.
4. Następnie zapoznaj się z listą wykrytych problemów. Każdy punkt precyzyjnie wyjaśnia, co należy zmienić.
5. Poniżej znajdziesz objaśnienie każdego elementu rekordu wraz z liczbą zużywanych zapytań DNS. Rozwiń include, aby zobaczyć, co autoryzuje dana usługa.

Link w pasku adresu zapisuje parametry tego testu, więc możesz łatwo przesłać go współpracownikowi lub administratorowi hostingu. Pamiętaj o ograniczeniu: serwer odbiorcy weryfikuje SPF na podstawie adresu IP serwera faktycznie przesyłającego wiadomość. To narzędzie analizuje samą konfigurację rekordu w DNS. Nie jest w stanie przetworzyć dynamicznych makr SPF zależnych od IP nadawcy.

Czym jest rekord SPF?

Rekord SPF to rekord TXT w strefie DNS domeny, który określa listę serwerów uprawnionych do wysyłania poczty w jej imieniu. Skrót SPF oznacza Sender Policy Framework, a jego zasady definiuje standard RFC 7208. Domena korzystająca z Google Workspace zazwyczaj posiada rekord w takiej postaci:

v=spf1 include:_spf.google.com ~all

v=spf1 identyfikuje początek rekordu SPF. include:_spf.google.com autoryzuje wszystkie serwery pocztowe z oficjalnej listy Google. ~all instruuje serwery odbiorcze, aby traktowały pocztę z wszelkich innych serwerów jako podejrzaną.

Gdy wiadomość trafia do odbiorcy, serwer pobiera domenę z technicznego adresu zwrotnego (Return-Path lub koperta). Następnie sprawdza rekord SPF tej domeny i weryfikuje, czy IP nadawcy znajduje się na liście. SPF nie sprawdza widocznego adresu nadawcy (From). Z tego względu SPF działa w ścisłym połączeniu z DKIM i DMARC. Aby poznać zasady ich współpracy, przeczytaj SPF, DKIM i DMARC w przystępnym przewodniku.

Od lutego 2024 r. Gmail wymaga SPF lub DKIM od każdego nadawcy, a obu zabezpieczeń od nadawców masowych. Yahoo stosuje identyczne wymogi.

Co oznacza każdy element rekordu SPF

Rekord SPF to ciąg mechanizmów i modyfikatorów oddzielonych spacjami. Serwery odbiorcze czytają go od lewej do prawej i zatrzymują się na pierwszej regule pasującej do serwera wysyłającego.

Każdy mechanizm może zaczynać się od kwalifikatora określającego wynik testu w przypadku dopasowania. + oznacza Pass (zaliczone) i jest domyślny. - oznacza Fail (odrzucenie), ~ to Softfail (łagodne odrzucenie), a ? oznacza Neutral. Dlatego rekordy kończą się regułą -all, ~all lub ?all.

Wielkość liter nie ma znaczenia: Include: działa tak samo jak include:. Standard RFC 7208 zaleca kończenie każdego rekordu regułą all lub modyfikatorem redirect. Bez tego nieujęte serwery otrzymują wynik neutralny.

Rygorystyczny limit 10 zapytań DNS

Każdy mechanizm include, a, mx, ptr, exists oraz redirect zmusza serwer odbiorczy do wykonania zapytania DNS. Standard RFC 7208 dopuszcza maksymalnie 10 zapytań DNS podczas jednej weryfikacji. Zapytania wewnątrz zagnieżdżonych rekordów include również się wliczają, więc pojedynczy include może kosztować kilka zapytań. Mechanizmy ip4, ip6 oraz all nie generują zapytań. Gdy rekord wymaga więcej niż 10 zapytań, serwer odbiorcy przerywa sprawdzanie błędem Permerror i test SPF kończy się porażką.

Przekroczenie tego limitu jest bardzo łatwe. Zmierzyliśmy w publicznym DNS koszt popularnych usług: Google Workspace zużywa 1 zapytanie, Microsoft 365 zużywa 1 zapytanie, Salesforce 2, Mailgun 5, a Freshdesk 7. Firma na Google Workspace, która doda Mailguna i Freshdeska, potrzebuje już 13 zapytań. Badanie z 2024 r. nad rekordami SPF w domenach .com, .net, .org i .se wykazało, że 6,5% z nich przekraczało limit 10 zapytań, a rekordy zaledwie dwóch dostawców hostingu odpowiadały za 83,7% tych przypadków.

Koszty te ulegają również zmianom. Include Google zużywał 4 zapytania aż do grudnia 2025 r., kiedy to Google uprościło swoje zagnieżdżone include do płaskiej listy. Wiele poradników i generatorów wciąż podaje starą wartość 4. Nasze narzędzie sprawdza bieżącą liczbę zapytań w czasie rzeczywistym.

Przekroczenie limitu nie zawsze powoduje natychmiastowe odrzucenie każdego maila. Jak wyjaśnia Microsoft, serwery sprawdzają mechanizmy od lewej do prawej i zatrzymują się na pierwszym dopasowaniu. Wiadomość z usługi umieszczonej na początku rekordu może przejść pomyślnie, podczas gdy usługa z końca rekordu zawiedzie. Powoduje to pozorne wrażenie losowości błędów dostarczalności.

Obowiązuje również drugi limit: zapytania puste (void lookups), np. include wskazujący na domenę, która już nie istnieje. Standard RFC 7208 nakazuje przerwanie weryfikacji po napotkaniu 2 takich zapytań.

Jak utrzymać się poniżej limitu 10 zapytań DNS

1. Usuń reguły include dla usług i narzędzi marketingowych, z których już nie korzystasz.
2. Usuń wpisy include, których dostawcy już nie wymagają. Mailchimp, Postmark, Brevo i Klaviyo nie potrzebują include w domenie głównej. SendGrid i Amazon SES realizują wysyłkę z dedykowanych subdomen. Zobacz zestawienie poniżej.
3. Wpisuj własne serwery pocztowe za pomocą mechanizmów ip4 i ip6 zamiast a lub mx. RFC 7208 zaleca tę kolejność, a adresy IP nie zużywają zapytań DNS.
4. Wysyłaj mailingi i powiadomienia z dedykowanej subdomeny, np. newsletter.twojadomena.pl. Każda subdomena ma własny rekord SPF i własną pulę 10 zapytań.

Niektóre serwisy oferują tzw. SPF flattening, czyli zastąpienie include bezpośrednimi adresami IP. Oszczędza to zapytania, lecz dostawcy regularnie modyfikują swoje zakresy IP. Statyczny rekord szybko staje się nieaktualny. Microsoft odradza spłaszczanie dla usług o dynamicznych adresach i zaleca regularny audyt co najmniej raz na kwartał.

Wpisy include dla Google Workspace, Microsoft 365 i innych usług

Poniżej zebrano oficjalne wartości include z dokumentacji popularnych dostawców wraz z liczbą zapytań DNS zmierzoną w publicznym DNS 12 października 2026 r. Zawsze weryfikuj dokumentację własnego konta pod kątem specyfikacji regionalnych.

HubSpot przydziela każdemu kontu unikalny include kończący się na hubspotemail.net. Należy go skopiować z ustawień e-mail w HubSpot. Zużywa 1 zapytanie.

Usługi, które zwykle nie wymagają wpisu SPF include

Weryfikacja SPF odbywa się na adresie Return-Path, a nie na widocznym adresie From. Większość nowoczesnych platform mailingowych stosuje własną domenę zwrotną lub dedykowaną subdomenę CNAME. Dodawanie ich include do domeny głównej niepotrzebnie marnuje zapytania DNS.

• Mailchimp. Mailchimp konfiguruje autoryzację za pomocą rekordów CNAME dla DKIM.
• Postmark. Postmark realizuje wysyłkę z własnej domeny Return-Path.
• Brevo. Brevo nie wymaga rekordu SPF na domenie głównej (chyba że posiadasz dedykowany adres IP).
• Klaviyo. Klaviyo nie wymaga dodawania include SPF na domenie głównej.
• SendGrid. SendGrid konfiguruje SPF na dedykowanej subdomenie podczas uwierzytelniania.
• Amazon SES. SES wymaga SPF jedynie w przypadku niestandardowej subdomeny MAIL FROM.

Nasz weryfikator oznacza zbędne wpisy include, gdy wykryje je w Twoim rekordzie.

Jak utworzyć rekord SPF

Przejdź do zakładki Generator powyżej. Zaznacz usługi wysyłające pocztę w Twoim imieniu, a narzędzie przygotuje poprawny rekord i na bieżąco zliczy zapytania DNS. Jeśli Twoja domena posiada już rekord, załaduj go najpierw, aby go uzupełnić zamiast nadpisywać. Oto zalecane kroki:

1. Sporządź listę wszystkich systemów wysyłających pocztę z Twojej domeny: poczta firmowa, newslettery, CRM, helpdesk, fakturowanie i formularze kontaktowe. Raporty DMARC pomagają namierzyć pominięte źródła.
2. Znajdź oficjalny include każdego dostawcy lub zaznacz go w naszym narzędziu. Dla serwerów własnych przygotuj ich adresy IP.
3. Wybierz zakończenie: ~all lub -all. W kolejnej sekcji wyjaśniamy konsekwencje obu wariantów.
4. Opublikuj regułę jako pojedynczy rekord TXT w domenie głównej (często oznaczanej jako @ w panelu DNS). Jeśli istnieje już rekord zaczynający się od v=spf1, zmodyfikuj go zamiast dodawać kolejny.
5. Odczekaj kilka minut na propagację DNS i sprawdź domenę ponownie za pomocą tego weryfikatora SPF.

Każda subdomena wysyłająca pocztę musi posiadać własny rekord SPF, ponieważ nie dziedziczy konfiguracji z domeny głównej. Domena lub subdomena, która nigdy nie wysyła maili, powinna zostać zabezpieczona rekordem: v=spf1 -all. Standard RFC 7208 uznaje to za kluczową dobrą praktykę chroniącą przed podszywaniem się. Brytyjskie NCSC rekomenduje dodanie do nieaktywnych domen również polityki DMARC p=reject oraz pustego rekordu MX (Null MX).

Rekord o długości przekraczającej 255 znaków musi zostać podzielony na kilka ciągów w cudzysłowach wewnątrz tego samego rekordu TXT. Serwery odbiorcze łączą te ciągi bez dodawania spacji, dlatego spacje rozdzielające muszą znajdować się wewnątrz ciągów. Sprawdź wytyczne swojego panelu DNS dotyczące długich wpisów.

~all czy -all: które zakończenie wybrać

Najwięksi dostawcy poczty prezentują odmienne rekomendacje:

• Google zaleca stosowanie ~all (Softfail).
• M3AAWG, międzynarodowa organizacja zrzeszająca operatorów poczty, rekomenduje ~all, aby serwery nie odrzucały wiadomości przed weryfikacją DMARC.
• Microsoft rekomenduje -all (Fail), pod warunkiem pełnego wdrożenia DKIM i DMARC.

Ryzyko związane z -all polega na tym, że część serwerów odbiorczych odrzuca wiadomość już na etapie wstępnej sesji SMTP, zanim sprawdzi zasady DMARC. Standard RFC 9989 (DMARC 2026) zauważa, że odrzucone w ten sposób wiadomości nie trafiają do raportów DMARC, co uniemożliwia diagnozę problemów z legalną pocztą.

W praktyce ~all jest bezpieczniejszym wyborem dla domen aktywnych, zwłaszcza w trakcie mapowania wszystkich źródeł wysyłki. Przy aktywnej polityce DMARC na poziomie quarantine lub reject to DMARC decyduje o losie wiadomości. Regułę -all rezerwuj dla domen obronnych, które nie wysyłają żadnych wiadomości. Nigdy nie używaj +all (dopuszcza cały internet) i unikaj ?all (brak ochrony).

Co oznaczają wyniki testu rekordu SPF

Serwery odbiorcze stosują znormalizowane statusy wyników weryfikacji SPF w nagłówkach Authentication-Results oraz w raportach DMARC :

Typowe błędy w rekordach SPF i sposoby naprawy

Analiza 12 milionów popularnych domen z 2023 r. wykazała obecność SPF w 56,5% z nich, a 2,9% rekordów zawierało krytyczne błędy. Najczęstszą usterką było odwoływanie się do domeny bez rekordu SPF, a zaraz za nią uplasowało się przekroczenie limitu zapytań DNS.

Dwa rekordy SPF w tej samej domenie

Problem pojawia się zwykle podczas wdrażania nowej usługi, gdy instrukcja nakazuje „dodać rekord TXT” i tworzony jest kolejny wpis zamiast edycji starego. Dwa rekordy SPF skutkują natychmiastowym Permerror. Połącz wszystkie mechanizmy w jeden wpis TXT rozpoczynający się od v=spf1 i kończący się pojedynczym all.

Wpis include wskazujący na nieistniejącą regułę

Jeśli include wskazuje na domenę bez poprawnego SPF, cała weryfikacja kończy się błędem Permerror. Przyczyną bywają literówki lub wycofane usługi dostawców. Usuń lub zaktualizuj niepoprawny include.

+all, ?all lub brak zakończenia all

+all autoryzuje wszystkie komputery w sieci i usuwa jakąkolwiek ochronę. ?all lub brak reguły zamykającej daje bezużyteczny status neutralny. Zawsze kończ rekord regułą ~all lub -all.

Obecność mechanizmu ptr

RFC 7208 stanowczo odradza mechanizm ptr. Jest powolny, zużywa cenne zapytanie DNS i często zawodzi przy problemach z DNS. Zastąp go bezpośrednimi wpisami ip4 oraz ip6.

Błędy składniowe i literówki

Spacja po dwukropku, niekompletny adres IPv4 czy nieznane słowo wywołują natychmiastowy Permerror. Bardziej podstępny błąd to include=example.com ze znakiem równości: serwery ignorują go jako nieznany modyfikator, przez co usługa nigdy nie zostaje autoryzowana. Nasz weryfikator natychmiast wychwytuje takie usterki.

Trzy częste mity na temat rekordu SPF

• „Rekord SPF nie może zawierać wielkich liter.” RFC 7208 precyzuje, że mechanizmy i nazwy są całkowicie niewrażliwe na wielkość liter.
• „Rekord SPF może mieć maksymalnie 255 znaków.” Limit 255 znaków dotyczy pojedynczego ciągu w rekordzie DNS TXT. Dłuższy rekord dzieli się na wiele ciągów, które serwer odbiorcy automatycznie łączy.
• „Można zdefiniować maksymalnie 10 mechanizmów include.” Limit dotyczy łącznej liczby zapytań DNS generowanych rekurencyjnie przez całe drzewo SPF, a nie liczby użytych słów include.

SPF jako element kompleksowej ochrony poczty

Pozytywny wynik SPF ma swoje ograniczenia. W badaniu z 2023 r. aż 34,7% domen autoryzowało pośrednio ponad 100 000 adresów IP. Ponadto SPF niemal zawsze zawodzi przy automatycznym przekazywaniu wiadomości, ponieważ serwer pośredniczący nie widnieje w rekordzie nadawcy.

Problem ten rozwiązuje DKIM za pomocą podpisu kryptograficznego wiadomości, który pozostaje nienaruszony przy przekazywaniu. Z kolei DMARC sprawdza zgodność domeny widocznej w nagłówku From z domeną uwierzytelnioną przez SPF lub DKIM i instruuje odbiorców, jak traktować podejrzaną pocztę. Skonfiguruj pozostałe filary za pomocą naszego generatora DKIM oraz generatora DMARC. Użyj narzędzia MX lookup, aby sprawdzić konfigurację serwerów odbiorczych.

Uwierzytelnianie nie zapobiega jednak wysyłce na nieistniejące skrzynki pocztowe, co generuje twarde odbicia i niszczy reputację nadawcy. Weryfikuj pojedyncze adresy za pomocą testera e-mail lub sprawdzaj całe bazy przez masowy weryfikator adresów e-mail. Zwięzłe podsumowanie dla zespołu znajdziesz w haśle rekord SPF w słowniku pojęć.