SPF record: pełny przewodnik składni include/all/redirect

Jeśli Twoje e-maile lądują w spamie albo serwery odbiorców je odrzucają, pierwszym podejrzanym jest brak lub błędna konfiguracja rekordu SPF. Ten przewodnik przeprowadzi Cię przez całą składnię — od zera do gotowego wpisu DNS — z wyjaśnieniem mechanizmów include, all i redirect, tabelą kwalifikatorów oraz listą najczęstszych pułapek.

Czym jest rekord SPF i dlaczego ma znaczenie?

SPF (Sender Policy Framework) to rekord DNS typu TXT, który informuje serwery odbiorców, które adresy IP lub hosty są uprawnione do wysyłania e-maili w imieniu Twojej domeny. Standard opisuje RFC 7208. Jeśli wiadomość przychodzi z IP spoza listy, serwer odbiorcy może ją odrzucić, oznaczyć jako spam lub przepuścić — zależnie od polityki.

Brak rekordu SPF to jeden z głównych powodów, dla których nowe domeny lub nowe serwery SMTP trafiają na listy blokujące. Poprawna konfiguracja to też warunek wstępny skutecznego działania DMARC — bez SPF (lub DKIM) DMARC nie ma podstawy do weryfikacji.

Anatomia rekordu SPF — podstawowa składnia

Rekord SPF zawsze zaczyna się od wersji protokołu i jest publikowany jako rekord TXT w DNS domeny. Przykład minimalny:

v=spf1 ip4:203.0.113.10 -all

Każdy rekord SPF składa się z trzech warstw: wersji (v=spf1), mechanizmów (co jest autoryzowane) oraz kwalifikatora przy mechanizmie all (co zrobić z resztą). Poniżej tabela wszystkich dostępnych kwalifikatorów:

Dostępne mechanizmy

• ip4: — pojedynczy adres IPv4 lub zakres CIDR, np. ip4:203.0.113.0/24
• ip6: — adres IPv6 lub zakres, np. ip6:2001:db8::/32
• a — rekord A/AAAA domeny (lub podanej nazwy hosta)
• mx — serwery MX domeny
• include: — dołącza politykę innej domeny (omówione szczegółowo poniżej)
• redirect= — zastępuje całą politykę polityką innej domeny
• exists: — zaawansowany mechanizm warunkowy (rzadko używany)
• all — pasuje do wszystkiego; zawsze na końcu rekordu

Mechanizm spf include — jak i kiedy go używać

Mechanizm include: to najczęściej stosowane rozszerzenie rekordu SPF. Pozwala dołączyć politykę SPF innej domeny — np. dostawcy usług e-mail — do własnego rekordu. Gdy serwer weryfikujący napotka include:przykład.com, pobiera rekord SPF domeny przykład.com i sprawdza, czy IP nadawcy mieści się w tamtej polityce.

Przykład praktyczny

Firma wysyła e-maile przez własny serwer SMTP oraz przez zewnętrzny system mailingowy. Rekord SPF wygląda wtedy tak:

v=spf1 ip4:198.51.100.5 include:mailing.example.com -all

Serwer odbiorcy sprawdza najpierw IP 198.51.100.5, a jeśli nie pasuje — pobiera rekord SPF domeny mailing.example.com i sprawdza tam. Jeśli żaden mechanizm nie pasuje, stosuje kwalifikator -all.

Limit 10 zapytań DNS — kluczowe ograniczenie

RFC 7208 (sekcja 4.6.4) narzuca twardy limit: maksymalnie 10 zapytań DNS (lookup) podczas weryfikacji jednego rekordu SPF. Każde include:, a, mx i redirect= kosztuje co najmniej jedno zapytanie. Przekroczenie limitu skutkuje wynikiem PermError — co serwery odbiorców często traktują jak Fail.

• Sprawdź aktualną liczbę lookupów narzędziem takim jak MXToolbox SPF Checker.
• Unikaj zagnieżdżania include: w include: — każde zagnieżdżenie to dodatkowe zapytania.
• Adresy IP wpisuj bezpośrednio (ip4:/ip6:) zamiast przez a lub mx, gdy to możliwe.
• Jeśli przekraczasz limit, rozważ spłaszczenie rekordu (SPF flattening) — zastąpienie include: konkretnymi zakresami IP.

Mechanizm spf all — twarda i miękka polityka

Mechanizm all zawsze stoi na końcu rekordu i określa, co zrobić z wiadomościami, których IP nie pasuje do żadnego wcześniejszego mechanizmu. To de facto domyślna odpowiedź Twojej polityki SPF.

-all vs ~all — kiedy co stosować?

-all (Hard Fail) oznacza: „każde IP spoza listy jest nieautoryzowane — odrzuć wiadomość". To rekomendowana polityka dla domen, które mają stabilną, dobrze udokumentowaną listę serwerów wysyłających. Wdrożenie DMARC z p=reject wymaga właśnie -all lub ~all po stronie SPF.

~all (Soft Fail) mówi: „IP spoza listy jest podejrzane, ale przepuść z flagą". Stosuj go podczas migracji serwera pocztowego, dodawania nowego dostawcy mailingowego lub gdy nie masz pewności, że zebrałeś wszystkie IP wysyłające. Po ustabilizowaniu konfiguracji przejdź na -all.

Uwaga: Samo ustawienie ~all nie chroni Twojej domeny przed spoofingiem. Dopiero -all w połączeniu z DMARC (p=quarantine lub p=reject) daje realną ochronę.

Mechanizm spf redirect — kiedy zastępuje cały rekord

Modyfikator redirect= różni się fundamentalnie od include:. Zamiast dołączać politykę innej domeny jako jeden z elementów, zastępuje całą politykę SPF bieżącej domeny polityką domeny docelowej. Jeśli w rekordzie pojawi się redirect=, mechanizm all z bieżącego rekordu jest ignorowany.

Przykład użycia redirect

v=spf1 redirect=spf.maindomain.example.com

Typowy scenariusz: firma zarządza wieloma domenami (np. sklep.pl, blog.sklep.pl, en.sklep.pl) i chce utrzymywać jedną centralną politykę SPF. Zamiast aktualizować rekord w każdej domenie osobno, wszystkie przekierowują do jednego rekordu wzorcowego.

Ograniczenia redirect

• redirect= i all w tym samym rekordzie — redirect= jest ignorowany, gdy pojawi się jakikolwiek mechanizm all. Nie mieszaj obu.
• Modyfikator redirect= kosztuje jedno zapytanie DNS — wlicza się do limitu 10.
• Domena docelowa musi mieć własny, poprawny rekord SPF — inaczej wynik to PermError.

Kompletne przykłady rekordów SPF dla typowych scenariuszy

Scenariusz 1: Własny serwer SMTP + jeden dostawca mailingowy

v=spf1 ip4:203.0.113.42 include:send.newsletter.example -all

Jeden adres IP własnego serwera, jeden include: dla zewnętrznego systemu mailingowego, twarda polityka na końcu. Łącznie 2 zapytania DNS — daleko od limitu.

Scenariusz 2: Firma z wieloma dostawcami

v=spf1 ip4:203.0.113.0/24 ip6:2001:db8::/48 include:_spf.google.com include:spf.protection.outlook.com include:send.crm.example ~all

Zakres IPv4 i IPv6, trzy include: dla Google Workspace, Microsoft 365 i systemu CRM. Soft Fail na czas weryfikacji, czy wszystkie IP są objęte — docelowo zmienić na -all.

Scenariusz 3: Wiele subdomen z centralną polityką

Domena główna firma.pl:

v=spf1 ip4:203.0.113.42 ip4:198.51.100.10 -all

Subdomeny noreply.firma.pl, info.firma.pl:

v=spf1 redirect=firma.pl

Najczęstsze błędy konfiguracji SPF

• Dwa rekordy SPF dla jednej domeny — RFC 7208 (sekcja 3.2) zabrania publikowania więcej niż jednego rekordu TXT SPF. Serwery weryfikujące zwracają wtedy PermError. Jeśli masz dwa rekordy, scal je w jeden.
• Przekroczenie limitu 10 lookupów — jak opisano wyżej, skutkuje PermError i de facto brakiem uwierzytelnienia.
• Brak rekordu SPF dla subdomen wysyłających — każda subdomena, z której wychodzą e-maile, potrzebuje własnego rekordu SPF (lub redirect=).
• Używanie ptr: — mechanizm ptr jest przestarzały (RFC 7208 odradza jego użycie) i generuje dodatkowe zapytania DNS.
• Zostawienie ?all lub brak all — brak kwalifikatora na końcu to zaproszenie dla spoofingu. Zawsze kończ rekord -all lub ~all.
• Nieaktualne zakresy IP po migracji serwera — po każdej zmianie serwera SMTP lub dostawcy mailingowego zaktualizuj rekord SPF. Weryfikuj co kilka miesięcy.

Jak weryfikować rekord SPF po wdrożeniu?

Po opublikowaniu rekordu w DNS (propagacja trwa zazwyczaj od kilku minut do 48 godzin) zweryfikuj konfigurację na kilka sposobów:

1. Zapytanie DNS ręcznie: dig TXT twojadomena.pl +short — sprawdź, czy zwracany jest dokładnie jeden rekord SPF.
2. Narzędzia online: MXToolbox SPF Checker, dmarcian SPF Surveyor, easydmarc.com — pokazują liczbę lookupów, błędy składni i wynik weryfikacji dla konkretnego IP.
3. Nagłówki wiadomości: wyślij testową wiadomość na konto Gmail lub Outlook i sprawdź nagłówek Authentication-Results — powinien zawierać spf=pass.
4. Raporty DMARC: jeśli masz wdrożony DMARC z rua=, raporty agregowane pokażą, które IP wysyłają w Twoim imieniu i czy przechodzą SPF.

Jeśli korzystasz z platformy takiej jak MailerPRO do wysyłki przez własne skrzynki SMTP, upewnij się, że adres IP Twojego serwera SMTP jest uwzględniony w rekordzie SPF domeny nadawcy — bez tego nawet najlepiej skonfigurowana kampania może trafić do folderu spam.

SPF a DKIM i DMARC — trójca uwierzytelniania

SPF weryfikuje serwer wysyłający (adres IP), ale nie chroni nagłówka From: widocznego dla odbiorcy. DKIM podpisuje treść wiadomości kluczem kryptograficznym. DMARC łączy oba mechanizmy i definiuje politykę dla wiadomości, które nie przejdą weryfikacji. Dopiero wszystkie trzy razem tworzą kompletną ochronę przed spoofingiem i phishingiem.

Wdrożenie samego SPF to dobry start, ale nie koniec drogi. Jeśli zależy Ci na dostarczalności i reputacji domeny, kolejnym krokiem powinno być dodanie rekordu DKIM oraz polityki DMARC — nawet na poziomie p=none do monitorowania.

Podsumowanie: poprawny rekord SPF to v=spf1, lista autoryzowanych mechanizmów (ip4/ip6/include/a/mx), opcjonalnie redirect= zamiast całej polityki, i zawsze kończący -all lub ~all. Pilnuj limitu 10 lookupów, publikuj dokładnie jeden rekord TXT na domenę i weryfikuj konfigurację po każdej zmianie infrastruktury pocztowej. To kilka minut pracy, które decydują o tym, czy Twoje wiadomości docierają do skrzynki odbiorczej.