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.

Parsowanie rekordu SPF
Sprawdzanie mechanizmów (include, ip4, a, mx)
Liczba zapytań DNS (limit 10)

Jak korzystać

  1. Wpisz nazwę domeny aby przeanalizować rekord SPF
  2. Narzędzie wyodrębni rekord SPF z DNS i przeanalizuje wszystkie mechanizmy
  3. Przejrzyj listę autoryzowanych serwerów i liczbę zapytań DNS

FAQ

SPF (Sender Policy Framework) to rekord DNS wskazujący, które serwery mogą wysyłać pocztę w imieniu Twojej domeny. Pomaga chronić domenę przed fałszowaniem nadawcy i spamem.

Standard SPF dopuszcza nie więcej niż 10 zapytań DNS przy weryfikacji rekordu. Przekroczenie limitu może spowodować odrzucenie wiadomości przez odbiorców.

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:

PolitykaOcenaWynik dla nieuprawnionego serwera
-all100fail — odbiorca może odrzucić wiadomość
~all80softfail — przyjąć, ale oznaczyć jako podejrzaną
?all50neutral — domena niczego nie deklaruje
+all20pass 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; ptr jest odradzany przez RFC 7208.
  • redirect=domena — modyfikator przekazujący całą politykę innej domenie; działa tylko bez all.

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.

  1. Usuń include usług, z których już nie korzystasz.
  2. Usuń a i mx, jeśli serwer WWW i serwery poczty przychodzącej nie wysyłają maili w imieniu domeny.
  3. Własne serwery wpisuj przez ip4/ip6.
  4. 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=spf bez jedynki, adres IPv6 w ip4.
  • 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ługaMechanizm
Google Workspaceinclude:_spf.google.com
Microsoft 365include:spf.protection.outlook.com
SendGridinclude:sendgrid.net
Mailguninclude:mailgun.org
Amazon SESinclude: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.

  1. Znajdź istniejący rekord TXT z v=spf1 dla domeny głównej (nazwa @ lub puste pole) i edytuj go zamiast dodawać drugi.
  2. Typ: TXT, nazwa: @ (dla subdomeny tylko jej część, np. newsletter), wartość: cały rekord, TTL: 3600.
  3. Cudzysłowy panel zwykle dodaje sam — nie wstawiaj ich podwójnie.
  4. 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.

Kaskadowa promocja witryny linkami Bonus 30 $Linki zwrotne 5→50→5000 w ponad 100 serwisach. Start od 30 $, bonus 30 $ dla nowych.