Co to jest SPF i jak działa?

SPF (Sender Policy Framework) to rekord DNS, w którym domena wymienia serwery uprawnione do wysyłania poczty w jej imieniu. Gdy przychodzi wiadomość, serwer odbiorcy pobiera tę listę i sprawdza, czy jest na niej serwer, który się z nim połączył. Aktualną specyfikacją jest RFC 7208 z 2014 roku.

SPF to jeden z trzech mechanizmów — obok DKIM i DMARC — dzięki którym dostawcy skrzynek odróżniają prawdziwą pocztę od sfałszowanej. Od 2024 roku Gmail i Yahoo wymagają go od każdego, kto wysyła pocztę masowo, a od maja 2025 roku to samo robi Microsoft w Outlook.com.

Co właściwie sprawdza SPF

Każda wiadomość e-mail ma dwa adresy nadawcy:

• nadawcę z koperty (envelope sender) — adres podawany w poleceniu SMTP MAIL FROM, a później zapisywany w nagłówku Return-Path. Na niego trafiają odbicia;
• nagłówek From, czyli adres, który ludzie widzą w programie pocztowym.

SPF sprawdza wyłącznie domenę nadawcy z koperty (i opcjonalnie nazwę, którą serwer przedstawił w HELO). O adresie From nie mówi nic. Jeśli Twoja usługa newsletterowa wysyła z adresem koperty w rodzaju bounce-123@mailer.example-esp.net, SPF jest oceniany dla mailer.example-esp.net, a nie dla Twojej domeny.

Dlatego sam SPF nie powstrzyma nikogo przed wpisaniem Twojego adresu w nagłówek From. Powiązanie obu adresów to zadanie DMARC, który wymaga, by domena sprawdzona przez SPF była zgodna (aligned) z domeną z From.

Jak wygląda rekord SPF

Rekord SPF to rekord TXT opublikowany bezpośrednio na domenie:

example.com.  3600  IN  TXT  "v=spf1 ip4:203.0.113.10 include:_spf.google.com -all"

Czytany od lewej do prawej oznacza:

1. v=spf1 — to rekord SPF (wersja 1, jedyna istniejąca).
2. ip4:203.0.113.10 — serwer o tym adresie IPv4 może wysyłać pocztę.
3. include:_spf.google.com — może też każdy serwer autoryzowany w rekordzie SPF Google (tak konfiguruje się Google Workspace).
4. -all — żaden inny serwer nie jest autoryzowany.

Elementy między v=spf1 a końcem rekordu to mechanizmy. Każdy z nich może być poprzedzony kwalifikatorem, który określa wynik, gdy mechanizm pasuje:

Kwalifikator	Wynik, gdy mechanizm pasuje	Znaczenie
+ (domyślny)	pass	autoryzowany
-	fail	nieautoryzowany
~	softfail	prawdopodobnie nieautoryzowany
?	neutral	brak deklaracji

Mechanizmy, które spotkasz w praktyce:

Mechanizm	Pasuje, gdy adres IP nadawcy…	Zapytanie DNS?
ip4:192.0.2.0/24, ip6:2001:db8::/32	należy do podanego zakresu	nie
a, a:host.example.com	jest adresem (A/AAAA) domeny lub hosta	tak
mx	jest adresem jednego z serwerów poczty domeny	tak
include:other.example	przechodzi weryfikację SPF domeny other.example	tak
exists:…	(zaawansowany, używany z makrami)	tak
ptr	ma odwrotny DNS w obrębie domeny — nie używaj	tak
all	pasuje zawsze; umieszczany na końcu	nie

Jest też modyfikator redirect=, który przekazuje całą ocenę rekordowi innej domeny, jeśli nic wcześniej nie pasowało. Przydaje się, gdy wiele domen korzysta z jednej wspólnej polityki.

Jak serwer odbiorcy ocenia SPF

Serwer odbiorcy wykonuje procedurę check_host() (RFC 7208, sekcja 4):

1. Pobiera rekordy TXT domeny nadawcy z koperty i zostawia tylko te, które zaczynają się dokładnie od v=spf1.
2. Jeśli nie ma żadnego, wynik to none. Jeśli jest więcej niż jeden — permerror.
3. Ocenia mechanizmy od lewej do prawej. O wyniku decyduje pierwszy pasujący.
4. Jeśli nic nie pasuje, a rekord zawiera redirect=, ocena przechodzi do rekordu wskazanej domeny. W przeciwnym razie wynik to neutral.

Problemy z DNS po drodze dają wynik temperror, a błędy składni i przekroczone limity — permerror. O tym, co zrobić z danym wynikiem, decyduje odbiorca; wielu traktuje permerror tak samo jak fail.

Limit 10 zapytań DNS

Aby chronić DNS przed rekordami, które wymykają się spod kontroli, RFC 7208 (sekcja 4.6.4) ogranicza liczbę mechanizmów i modyfikatorów wymagających zapytań DNS — include, a, mx, ptr, exists i redirect — do 10 na jedną ocenę, wliczając wszystko w zagnieżdżonych include. Po przekroczeniu limitu wynik to permerror.

To najczęstszy powód, dla którego działający rekord SPF nagle przestaje działać. Weźmy przykład:

v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:servers.mcsv.net include:sendgrid.net a mx -all

Sześć elementów na najwyższym poziomie wygląda niewinnie, ale rekord każdego dostawcy może zawierać kolejne include, a dostawcy zmieniają swoje rekordy bez uprzedzenia. Łączną liczbę zobaczysz dopiero wtedy, gdy prześledzisz każde include — i właśnie to robi narzędzie Sprawdzanie SPF.

Drugi limit dotyczy pustych zapytań (void lookups), czyli zapytań DNS, które nic nie zwracają (nazwa nie istnieje albo nie ma rekordów). Więcej niż dwa takie zapytania również powinny skończyć się wynikiem permerror. Zwykle biorą się ze starego include albo a: wskazującego host, którego już nie ma.

Jak zmieścić się w limicie:

• usuń include usług, z których już nie korzystasz;
• zastąp a i mx zakresami ip4/ip6 Twoich serwerów;
• nigdy nie używaj ptr;
• przenieś wysyłkę masową albo wysyłkę przez zewnętrzne usługi na subdomenę (np. news.example.com) z własnym rekordem SPF.

Typowe błędy

Dwa rekordy SPF. Klasyczny błąd to dodanie drugiego rekordu v=spf1 przy wdrażaniu nowej usługi pocztowej. Przy dwóch rekordach każda wiadomość kończy się wynikiem permerror. Połącz je w jeden:

; źle: dwa rekordy
example.com.  TXT  "v=spf1 include:_spf.google.com ~all"
example.com.  TXT  "v=spf1 include:sendgrid.net ~all"

; dobrze: jeden rekord
example.com.  TXT  "v=spf1 include:_spf.google.com include:sendgrid.net ~all"

+all albo brak all. +all autoryzuje każdy serwer w internecie. Rekord bez all kończy się domyślnym wynikiem neutral, który nie mówi odbiorcom nic o nieautoryzowanych nadawcach.

Pominięty nadawca. Faktury z systemu księgowego, powiadomienia ze sklepu internetowego, CRM — każdy system, który wysyła pocztę z Twoją domeną w adresie koperty, musi być ujęty w rekordzie, inaczej jego poczta nie przejdzie SPF.

Założenie, że subdomeny dziedziczą SPF. Nie dziedziczą. SPF jest sprawdzany dla dokładnie tej domeny, która występuje w adresie nadawcy z koperty. Jeśli wysyłasz jako noreply@shop.example.com, domena shop.example.com potrzebuje własnego rekordu.

Źle podzielone ciągi znaków. Pojedynczy ciąg w rekordzie TXT może mieć najwyżej 255 znaków, dlatego długie rekordy dzieli się na kilka ciągów, które przy odczycie są łączone bez dodawania spacji (RFC 7208, sekcja 3.3). Podział dokładnie między dwoma mechanizmami skleja je w jeden nieprawidłowy element, chyba że pierwszy ciąg kończy się spacją.

Typograficzne cudzysłowy. Rekordy kopiowane z dokumentów często zawierają „drukarskie” cudzysłowy albo twarde spacje, przez które stają się nieprawidłowe.

SPF dla domen, które nie wysyłają poczty

Domeny zaparkowane i domeny używane wyłącznie do strony internetowej to łatwy cel dla podszywających się, bo nikt ich nie pilnuje. Opublikuj dla nich rekord, który nie autoryzuje nikogo:

parked.example.  TXT  "v=spf1 -all"

Połącz go z rekordem null MX i rekordem DMARC z p=reject, aby odbiorcy odrzucali każdą wiadomość, która podaje się za pochodzącą z tej domeny.

SPF a DMARC

Dla DMARC wynik SPF liczy się tylko wtedy, gdy domena nadawcy z koperty jest zgodna z domeną z From: identyczna w trybie ścisłym (strict) albo należąca do tej samej domeny organizacyjnej w domyślnym trybie swobodnym (relaxed). Jeśli usługa pocztowa wysyła z własną domeną dla odbić, SPF przechodzi dla jej domeny, a DMARC nic z tego nie ma. Większość usług pozwala ustawić własną domenę return-path (często jako CNAME, np. bounce.example.com), co rozwiązuje problem. Drugim sposobem na przejście DMARC jest podpisywanie DKIM Twoją własną domeną — zobacz SPF, DKIM i DMARC: czym się różnią i co robią.

Jak sprawdzić Twój rekord

1. Sprawdź swoją domenę narzędziem Sprawdzanie SPF. Zweryfikuje składnię, prześledzi każde include i pokaże łączną liczbę zapytań DNS.
2. Wyślij wiadomość na zewnętrzną skrzynkę, otwórz jej oryginał i poszukaj spf=pass w nagłówku Authentication-Results — albo wklej nagłówki do analizatora nagłówków e-mail.
3. Po każdej zmianie pamiętaj, że resolwery mogą przechowywać stary rekord, dopóki nie wygaśnie jego TTL.