Sprawdzanie SPF
Analiza rekordu SPF domeny: mechanizmy, dołączenia, polityka.
Sprawdzanie rekordu SPF
Sprawdź rekord SPF (Sender Policy Framework) domeny. Prawidłowy SPF zapobiega podszywaniu się pod adresy e-mail z Twojej domeny.
Jak korzystać
- Wpisz nazwę domeny aby przeanalizować rekord SPF
- Narzędzie wyodrębni rekord SPF z DNS i przeanalizuje wszystkie mechanizmy
- Przejrzyj listę autoryzowanych serwerów i liczbę zapytań DNS
FAQ
Sprawdzenie rekordu SPF: jak czytać wynik
Narzędzie pobiera rekordy TXT domeny, wybiera ten, który zaczyna się od v=spf1, i rozkłada go na mechanizmy. W raporcie widać ocenę od 0 do 100, treść rekordu, liczbę mechanizmów, liczbę zapytań DNS i końcową politykę. O ocenie decyduje przede wszystkim kwalifikator przy all:
| Polityka | Ocena | Wynik dla nieuprawnionego serwera |
|---|---|---|
-all | 100 | fail — odbiorca może odrzucić wiadomość |
~all | 80 | softfail — przyjąć, ale oznaczyć jako podejrzaną |
?all | 50 | neutral — domena niczego nie deklaruje |
+all | 20 | pass dla każdego serwera — brak ochrony |
Gdy mechanizmów wymagających zapytania DNS jest więcej niż dziesięć, ocena spada o kolejne 30 punktów. Licznik obejmuje mechanizmy samego rekordu: każdy include to jedno zapytanie, ale dołączony rekord może mieć własne include, które też zużywają limit. Łańcuch rozwiniesz ręcznie:
dig +short TXT example.pl dig +short TXT _spf.google.com
Zajrzyj też do surowej treści rekordu. Jeśli brakuje w nim all, według specyfikacji serwery spoza listy dostają wynik neutral, jak przy ?all. Samo all bez znaku oznacza +all.
Składnia SPF w pigułce
Mechanizmy są sprawdzane od lewej do prawej, wygrywa pierwsze dopasowanie. Przed mechanizmem może stać kwalifikator: + (pass, domyślnie), - (fail), ~ (softfail), ? (neutral).
ip4,ip6— konkretny adres lub podsieć; nie zużywają limitu zapytań.a— adresy z rekordów A/AAAA domeny;mx— adresy serwerów pocztowych z MX.include:domena— dołącza politykę innej domeny; tak autoryzuje się Google, Microsoft czy usługę mailingową.exists,ptr— rzadkie;ptrjest odradzany przez RFC 7208.redirect=domena— modyfikator przekazujący całą politykę innej domenie; działa tylko bezall.
Limit 10 zapytań DNS
RFC 7208 pozwala na maksymalnie dziesięć zapytań DNS podczas weryfikacji SPF. Liczą się include, a, mx, ptr, exists i redirect, także zagnieżdżone. Po przekroczeniu limitu odbiorca zwraca permerror i SPF nie przechodzi dla żadnej wiadomości z domeny, choć w panelu DNS rekord wygląda poprawnie. Limit zwykle wyczerpuje się stopniowo: poczta firmowa, CRM, system newsletterów, helpdesk.
- Usuń include usług, z których już nie korzystasz.
- Usuń
aimx, jeśli serwer WWW i serwery poczty przychodzącej nie wysyłają maili w imieniu domeny. - Własne serwery wpisuj przez
ip4/ip6. - Mailing przenieś na subdomenę (np.
newsletter.example.pl) z osobnym rekordem i osobnym limitem.
Najczęstsze błędy w rekordzie SPF
- Dwa rekordy v=spf1. Dozwolony jest jeden; dwa dają permerror. Trzeba połączyć mechanizmy w jeden rekord. Raport pokazuje pierwszy znaleziony rekord, więc ich liczbę sprawdź poleceniem
dig TXT example.pl. +all— każdy może wysyłać pocztę jako Ty.- Literówki: spacja po dwukropku (
include: _spf.google.com),v=spfbez jedynki, adres IPv6 wip4. - Subdomeny nie dziedziczą SPF. Subdomena, z której nie wychodzi poczta, powinna mieć
v=spf1 -all. - Rekord typu SPF (99) jest przestarzały — publikuj wyłącznie TXT.
Przykładowe rekordy SPF
| Usługa | Mechanizm |
|---|---|
| Google Workspace | include:_spf.google.com |
| Microsoft 365 | include:spf.protection.outlook.com |
| SendGrid | include:sendgrid.net |
| Mailgun | include:mailgun.org |
| Amazon SES | include:amazonses.com |
Domena na Google Workspace, która wysyła powiadomienia przez SendGrid i ze sklepu na własnym VPS:
v=spf1 ip4:203.0.113.10 include:_spf.google.com include:sendgrid.net ~all
Domena bez poczty (np. strona wizytówka na osobnej domenie):
v=spf1 -all
Część usług mailingowych sprawdza SPF nie na domenie głównej, lecz na subdomenie zwrotnej (Return-Path), którą kierujesz do nich rekordem CNAME. Zawsze trzymaj się instrukcji dostawcy.
Gdzie dodać rekord SPF
Rekord SPF zmieniasz tam, gdzie jest strefa DNS domeny — u rejestratora (np. w panelu OVH, home.pl, nazwa.pl), u hostingodawcy albo w Cloudflare. Liczy się to, czyje serwery NS są ustawione dla domeny, a nie gdzie ją kupiono.
- Znajdź istniejący rekord TXT z
v=spf1dla domeny głównej (nazwa@lub puste pole) i edytuj go zamiast dodawać drugi. - Typ: TXT, nazwa:
@(dla subdomeny tylko jej część, np.newsletter), wartość: cały rekord, TTL: 3600. - Cudzysłowy panel zwykle dodaje sam — nie wstawiaj ich podwójnie.
- Rekord dłuższy niż 255 znaków musi być podzielony na kilka ciągów w jednym rekordzie TXT; większość paneli robi to automatycznie.
Jak sprawdzić SPF w nagłówkach wiadomości
Zapytanie DNS pokazuje, co jest opublikowane, a nagłówki — jak odbiorca ocenił konkretną wiadomość. W Gmailu otwórz maila i wybierz „Pokaż oryginał”: przy SPF zobaczysz PASS, SOFTFAIL, FAIL, NEUTRAL lub PERMERROR wraz z adresem IP nadawcy. W surowych nagłówkach szukaj linii Authentication-Results:
Authentication-Results: mx.google.com;
spf=fail (google.com: domain of [email protected] does not
designate 198.51.100.25 as permitted sender) [email protected]
Widać tu, którą domenę sprawdzano (smtp.mailfrom) i który serwer nie jest wpisany. Dodaj go przez ip4 albo przez include usługi, do której należy. permerror to prawie zawsze dwa rekordy lub przekroczony limit zapytań, a temperror — chwilowy problem z serwerami DNS domeny.
~all czy -all
-all jest surowsze, ale niektóre serwery odrzucają wiadomość po nieudanym SPF jeszcze przed sprawdzeniem DKIM, a przekazywane dalej maile (w których SPF z natury się psuje) giną. Dlatego przy skonfigurowanym DMARC często zostawia się ~all i pozwala DMARC podjąć decyzję na podstawie SPF i DKIM razem.
SPF przechodzi, a poczta i tak trafia do spamu
SPF potwierdza tylko, że serwer ma prawo wysyłać pocztę w imieniu domeny — reputacji nie buduje. Jeśli w nagłówkach jest spf=pass, a wiadomości lądują w spamie, sprawdź kolejne elementy:
- czy adres IP nadawcy ma rekord PTR zgodny z DNS w przód — pokaże to odwrotny DNS;
- czy IP nie trafił na listy DNSBL — sprawdzenie IP na czarnych listach;
- czy DKIM przechodzi i czy domena podpisu zgadza się z domeną w polu From;
- czy ktoś nie wysyła spamu z przejętej skrzynki lub zainfekowanej strony.
Nowa domena lub nowy adres IP buduje reputację stopniowo; nagła wysyłka do tysięcy odbiorców sama w sobie jest sygnałem dla filtrów antyspamowych.
SPF, DKIM i DMARC
SPF weryfikuje adres koperty (Return-Path), a nie pole „Od”, które widzi odbiorca. DKIM podpisuje wiadomość kluczem domeny, a DMARC wymaga, by SPF lub DKIM przeszły dla domeny zgodnej z polem From, i mówi odbiorcy, co zrobić z resztą. Od 2024 roku Gmail i Yahoo wymagają wszystkich trzech od nadawców masowych. Po sprawdzeniu SPF zweryfikuj klucz DKIM, rekord DMARC i rekordy MX, a pozostałe wpisy strefy podejrzysz w DNS lookup. Po zmianie rekordu odczekaj czas TTL i powtórz test.