Rekord SPF: czym jest, jak działa i jak go skonfigurować

Co to jest SPF?

SPF (Sender Policy Framework) to jeden z trzech podstawowych protokołów uwierzytelniania poczty elektronicznej – obok DKIM i DMARC – który zapobiega wysyłaniu wiadomości e-mail z wykorzystaniem Twojej domeny przez nieautoryzowane serwery. Rekord SPF to rekord DNS typu TXT, w którym wymienione są wszystkie adresy IP i serwery pocztowe uprawnione do wysyłania wiadomości w Twoim imieniu. Bez tego rekordu dowolny serwer w Internecie może podszywać się pod Twoją domenę, a serwery odbiorcze nie mają możliwości odróżnienia prawdziwej wiadomości od fałszywej.

O czym jest ten przewodnik

Przejdź do dowolnej sekcji lub przeczytaj całość, aby uzyskać pełny obraz sytuacji:

Jak działa SPF

Gdy serwer pocztowy odbierający otrzymuje wiadomość e-mail, wyodrębnia domenę z pola „Return-Path” (nadawca koperty), wysyła zapytanie do serwera DNS o rekord TXT zaczynający się od „v=spf1” i sprawdza, czy adres IP serwera wysyłającego znajduje się na liście autoryzowanych adresów. Jeśli tak, test SPF kończy się wynikiem pozytywnym. W przeciwnym razie wynik to „fail”, „softfail” lub „error”, a dalszy przebieg zależy od polityki DMARC.

SPF weryfikuje domenę Return-Path (techniczny adres koperty), a nie widoczny adres w polu „Od:”. Oznacza to, że sam SPF nie jest w stanie zapobiec sfałszowaniu nazwy wyświetlanej. Właśnie dlatego wprowadzono zgodność z DMARC, aby wypełnić tę lukę.

Składnia rekordów SPF: mechanizmy i kwalifikatory

Rekord SPF zaczyna się od v=spf1, zawiera listę autoryzowanych nadawców przy użyciu takich mechanizmów jak ip4:, ip6:i obejmują:, a na końcu znajduje się klauzula określająca, jak odbiorcy mają postępować w przypadku nadawców, których nie ma na liście. Oto przykład:

v=spf1 ip4:192.168.1.1 include:_spf.google.com include:sendgrid.net -all

-all i ~all oznaczają różne poziomy egzekwowania zasad w SPF. Opcja -all (hard fail) informuje serwery odbiorcze, że tylko wymienieni nadawcy są autoryzowani, a wszystkie pozostałe wiadomości powinny zostać odrzucone. Opcja ~all (soft fail) jest bardziej łagodna i oznacza wszystkich nieautoryzowanych nadawców jako podejrzanych, ale nadal je akceptuje. Użyj opcji -all dopiero po przeprowadzeniu pełnego audytu nadawców.

Każdy include:, a, mx, przekierowanie=i exists: mechanizm ten wlicza się do Limit 10 wyszukiwań DNS. Przekroczenie tej wartości powoduje wygenerowanie błędu PermError, który całkowicie uniemożliwia uwierzytelnienie. ptr: mechanizm ten jest przestarzały, należy unikać stosowania.

Jak utworzyć rekord SPF

Zacznij od sporządzenia listy wszystkich usług, które wysyłają wiadomości e-mail z Twojej domeny, na przykład:

• Twój główny serwer pocztowy
• Google Workspace lub Microsoft 365
• Narzędzia marketingowe (Mailchimp, HubSpot, Klaviyo)
• Usługi transakcyjne (SendGrid, Mailgun, Amazon SES) oraz wszelkie systemy CRM lub platformy obsługi klienta, które wysyłają wiadomości w Twoim imieniu.

Każdy dostawca publikuje include: wartość w ich dokumentacji. Utwórz jeden rekord łączący wszystkich nadawców (można mieć tylko jeden rekord SPF na domenę), opublikuj go jako rekord TXT w swoim Dostawca usług DNS, a następnie zweryfikować to za pomocą Narzędzie do sprawdzania SPF. Rozprzestrzenianie się DNS zazwyczaj trwa to kilka godzin, ale może potrwać nawet do 48 godzin.

Instrukcje konfiguracji dla poszczególnych dostawców

Jak sprawdzić i zweryfikować swój rekord SPF

Skorzystaj z narzędzia do sprawdzania SPF, aby upewnić się, że Twój rekord jest poprawny pod względem składniowym, mieści się w limicie 10 zapytań i prowadzi do właściwych adresów IP. Narzędzie SPF Lookup firmy PowerDMARC natychmiast przeprowadza wszystkie te kontrole.

Co powinno obejmować prawidłowa kontrola SPF:

• Nagranie zaczyna się od v=spf1
• Dla tej domeny istnieje tylko jeden rekord SPF
• Łączna liczba zapytań DNS wynosi 10 lub mniej
• Brak błędów składniowych ani nierozwiązywalnych include: domeny
• The all czy kwalifikator występuje i jest właściwy
• Brak przestarzałych mechanizmów (np. ptr:)

Sprawdzanie z wiersza poleceń (Linux/Mac):

dig TXT yourdomain.com +short | grep "v=spf1"

Korzystanie z funkcji sprawdzania SPF w PowerDMARC: Wpisz swoją domenę w narzędziu PowerDMARC SPF Checker, aby uzyskać natychmiastowy raport diagnostyczny zawierający liczbę sprawdzeń, podział według mechanizmów oraz ewentualne błędy.

Typowe błędy związane z SPF i sposoby ich naprawiania

Większość awarii serwera SPF wynika ze zmian w konfiguracji, a nie z samego protokołu. Oto najczęściej spotykane błędy oraz wskazówki, gdzie należy je naprawić:

SPF i DMARC: zrozumienie zgodności

SPF może przejść pomyślnie, podczas gdy DMARC nadal kończy się niepowodzeniem. Dzieje się tak, ponieważ SPF weryfikuje domenę Return-Path, ale DMARC wymaga, aby domena ta była zgodna z widocznym adresem „From:”. Gdy wysyłasz wiadomość za pośrednictwem serwisu zewnętrznego, który korzysta z własnej domeny Return-Path, SPF uwierzytelnia się względem tej domeny, a nie Twojej, w wyniku czego DMARC nie przechodzi kontroli zgodności.

Rozwiązaniem jest albo skonfigurowanie niestandardowego pola Return-Path w swojej domenie u każdego dostawcy, albo skorzystanie zamiast tego z dopasowania DKIM (podpisy DKIM zachowują ważność po przekazaniu wiadomości i nie są powiązane z adresem IP nadawcy). Tryb dopasowania należy ustawić za pomocą tagu aspf= w rekordzie DMARC: aspf=r (łagodny, dopuszczalne poddomeny) lub aspf=s (ścisły, dokładne dopasowanie).

SPF, DKIM i DMARC: jak te rozwiązania współdziałają

Te trzy protokoły wzajemnie się uzupełniają, ale nie są zamienne. SPF weryfikuje serwer wysyłający, natomiast DKIM weryfikuje integralność wiadomości za pomocą podpisu kryptograficznego. DMARC łączy oba te protokoły, egzekwuje politykę (brak / kwarantanna / odrzucenie) oraz generuje raporty zbiorcze i analityczne. Wiadomość e-mail przechodzi test DMARC, jeśli spełnia wymagania zgodności z protokołem SPF lub DKIM; należy skonfigurować oba protokoły, aby jeden mógł zrekompensować awarię drugiego (np. gdy SPF nie działa w przypadku wiadomości przekazywanych dalej, ale DKIM nadal działa).

SPF w modelu hostowanym: rozwiązanie problemu skalowalności

Każde narzędzie SaaS dodane do rekordu SPF generuje zapytania DNS. Po osiągnięciu limitu 10 zapytań cały rekord przestaje działać, a wszystkie sprawdzania SPF zwracają błąd PermError. Ręczne upraszczanie rekordu SPF (zastępowanie elementów „include” surowymi adresami IP) sprawdza się w perspektywie krótkoterminowej, ale traci aktualność, gdy dostawcy zmieniają swoje zakresy adresów IP — a robią to bez ostrzeżenia.

PowerDMARC automatyczne spłaszczanie SPF rozwiązuje ten problem poprzez dynamiczne rozpoznawanie include: przekształcanie łańcuchów w zoptymalizowane wpisy, monitorowanie zmian adresów IP dostawców oraz utrzymywanie liczby wpisów poniżej limitu wyszukiwań bez konieczności ręcznej edycji DNS. Dla organizacji korzystających z Makra SPF lub zarządzanie Współczynnik SPF dla wielu domen i subdomen, a hosting z obsługą SPF całkowicie eliminuje nakłady związane z konserwacją.

Lista kontrolna najlepszych praktyk dotyczących SPF