Rekord SPF w systemie DNS: jak działa i jak go skonfigurować

Każda wiadomość e-mail wysyłana przez Twoją organizację wpływa na reputację Twojej domeny. Jeśli rekord SPF jest nieprawidłowo skonfigurowany lub w ogóle go brakuje, serwery odbiorcze nie mają żadnego wiarygodnego sposobu, by sprawdzić, czy wiadomość rzeczywiście pochodzi od Ciebie. Prawdziwe wiadomości trafiają do folderu ze spamem. Kampanie marketingowe kończą się niepowodzeniem. Atakujący wysyłają wiadomości, które wyglądają, jakby pochodziły z Twojej domeny.

SPF (Sender Policy Framework) to jeden z trzech podstawowych protokołów uwierzytelniania poczty elektronicznej obok DKIM i DMARC, który informuje serwery pocztowe, które adresy IP są uprawnione do wysyłania wiadomości e-mail w imieniu Twojej domeny. Jest on publikowany jako rekord DNS TXT. Na pierwszy rzut oka wygląda to na proste. W praktyce jednak właśnie od SPF zaczyna się większość problemów z uwierzytelnianiem poczty elektronicznej. 

W niniejszym przewodniku wyjaśniono, czym dokładnie jest rekord SPF, jak krok po kroku przebiega weryfikacja SPF, jak go utworzyć oraz jak naprawić najczęstsze błędy związane z SPF, w tym problem z limitem 10 wyszukiwań DNS, który w sposób niezauważalny utrudnia dostarczanie wiadomości e-mail w rozwijających się organizacjach.

Czym jest rekord SPF w systemie DNS?

Rekord DNS SPF (Sender Policy Framework) to rodzaj rekordu DNS typu TXT, który określa, które serwery pocztowe są uprawnione do wysyłania wiadomości e-mail w imieniu danej domeny. Pomaga on serwerom pocztowym odbierającym wiadomości w weryfikacji, czy przychodzące wiadomości pochodzą z legalnych źródeł, co zmniejsza ryzyko spoofingu i phishingu. Po otrzymaniu wiadomości e-mail serwer sprawdza rekord SPF domeny nadawcy, aby upewnić się, że adres IP nadawcy jest dozwolony. 

Jeśli adres IP nie znajduje się na liście, wiadomość może zostać oznaczona, odrzucona lub przeniesiona do folderu ze spamem. Prawidłowe skonfigurowanie rekordu SPF poprawia dostarczalność wiadomości e-mail i wzmacnia uwierzytelnianie domeny.

Możesz natychmiast sprawdzić rekord SPF swojej domeny za pomocą bezpłatne narzędzie do sprawdzania SPF. Zajmuje to pięć sekund i pokazuje dokładnie, co jest opublikowane w Twoim DNS.

Jak działa uwierzytelnianie SPF?

Uwierzytelnianie SPF przebiega zgodnie ze ustaloną procedurą wyszukiwania i weryfikacji w systemie DNS przy każdym odbiorze wiadomości e-mail:

• Twoja domena publikuje rekord SPF jako wpis DNS typu TXT. Rekord ten określa wszystkie autoryzowane źródła wysyłające przy użyciu mechanizmów takich jak ip4, ip6, includeoraz a, wraz z domyślną polityką (-all, ~alllub ?all).
• Kiedy wysyłana jest wiadomość e-mail, serwer wysyłający podaje adres Return-Path (adres nadawcy koperty), który wskazuje domenę odpowiedzialną za dostarczenie wiadomości.
• Serwer pocztowy odbierający wyodrębnia domenę z adresu Return-Path.
• Wysyła zapytanie DNS w celu pobrania rekordu SPF powiązanego z tą domeną.
• Adres IP serwera wysyłającego jest następnie porównywany z każdym mechanizmem zawartym w rekordzie SPF i sprawdzany po kolei, aż do znalezienia zgodności lub podjęcia decyzji dotyczącej polityki.
• SPF nakłada ograniczenie do 10 zapytań DNS podczas tej oceny, aby zapobiec nadmiernej rekurencji; przekroczenie tego limitu skutkuje błędem PermError.
• W zależności od wyniku funkcja SPF zwraca jeden z następujących wyników: Pass, Fail, SoftFail, Neutral, None, PermError lub TempError.
• Serwer odbiorczy wykorzystuje ten wynik, wraz z uwierzytelnieniem DKIM i zgodnością z polityką DMARC, do ustalenia, w jaki sposób należy potraktować wiadomość (dostarczyć, umieścić w kwarantannie lub odrzucić).

Ważna uwaga: SPF weryfikuje domenę pola Return-Path (nadawcy koperty), a nie widoczną domenę w nagłówku „From”. Jeśli domeny te się różnią, co często ma miejsce w przypadku zewnętrznych platform wysyłkowych, test SPF może zakończyć się powodzeniem, ale dostosowanie DMARC może zakończyć się niepowodzeniem, co bezpośrednio wpływa na trafianie do skrzynki odbiorczej.

Każdy kod wyniku SPF ma konkretne praktyczne znaczenie:

Raporty zbiorcze DMARC pokazują dokładnie, które wiadomości e-mail przechodzą i nie przechodzą weryfikację SPF we wszystkich źródłach wysyłania. Bez raportów DMARC niepowodzenia SPF zachodzą w ukryciu i nigdy się o nich nie dowiesz, dopóki ktoś nie zgłosi skargi.

Wyjaśnienie składni i formatu rekordów SPF

Zrozumienie składni SPF wymaga najpierw zapoznania się z pełnym wpisem i poznania sposobu oceny poszczególnych jego części. Oto typowy przykład:

v=spf1 include:_spf.google.com include:spf.protection.outlook.com ip4:203.0.113.0/24 -all (gdzie /24 oznacza zakres 256 adresów IP przy użyciu notacji CIDR (Classless Inter-Domain Routing))

Ten pojedynczy wiersz informuje serwery odbierające, które źródła mają prawo wysyłać wiadomości e-mail w imieniu Twojej domeny oraz jak postąpić, jeśli nadawca nie znajduje się na liście.

Tag wersji SPF (v=spf1)

Każdy rekord SPF musi zaczynać się od v=spf1. Oznacza to, że rekord TXT jest polityką SPF. Nie ma innych poprawnych wersji. Jeśli ten tag nie występuje lub jest nieprawidłowy, rekord jest całkowicie ignorowany.

Mechanizmy SPF (autoryzowani nadawcy) 

Mechanizmy określają, kto może wysyłać wiadomości e-mail. Są one sprawdzane od lewej do prawej, a wynik zależy od pierwszego dopasowania.

Wśród obejmują: mechanizm jest najczęściej stosowany i powoduje najwięcej problemów. Każdy include: wywołuje rekurencyjne wyszukiwanie DNS. Jeśli rekord SPF w Google zawiera trzy inne domeny, wszystkie one wliczają się do limitu 10 wyszukiwań.

Częsty powód nieporozumień: mechanizm mechanizm w SPF odwołuje się do rekordu DNS typu A danej domeny. Nie tworzy on oddzielnego „rekordu A dla SPF”. Po dodaniu a do swojego rekordu SPF, autoryzujesz wszystkie adresy IP, do których rozdziela się rekord A Twojej domeny.

Modyfikatory (redirect=)

Modyfikatory regulują sposób działania algorytmu SPF, a nie służą do definiowania nadawców.

• redirect=
  Przenosi całą ocenę SPF do innej domeny. W przeciwieństwie do include:, które dodaje kolejną politykę do Twojego rekordu, redirect= całkowicie zastępuje całkowicie zmianę Twojej oceny.
  Używaj tego tylko wtedy, gdy jedna domena powinna w pełni odziedziczyć konfigurację SPF innej domeny.

Limit wyszukiwania DNS (ograniczenie krytyczne)

SPF zezwala na maksymalnie 10 zapytań DNS na jedną ocenę. Mechanizmy takie jak obejmują:, a, mx, istnieje:, oraz redirect= wszystkie wliczają się do tego limitu.

W przypadku przekroczenia limitu funkcja SPF zwraca błąd PermError, a uwierzytelnianie kończy się niepowodzeniem, nawet jeśli nadawca jest autoryzowany. Dlatego duże, złożone rekordy często wymagają optymalizacji (np. poprzez ograniczenie liczby nieużywanych elementów include lub spłaszczenie struktury).

Kwalifikatory SPF (mechanizm „all”)

Warunek w mechanizm mechanizm na końcu rekordu SPF określa politykę SPF – co dzieje się z wiadomościami e-mail pochodzącymi z serwerów, które nie zostały wyraźnie wymienione:

SPF działa jako zestaw reguł logicznych. Serwer odbierający odczytuje rekord od lewej do prawej, sprawdza każdy mechanizm i zatrzymuje się przy pierwszym dopasowaniu. Jeśli nie zostanie znalezione żadne dopasowanie, stosowana jest reguła .

Prawidłowo skonstruowany rekord SPF wygląda następująco:

• Pełna lista (obejmująca wszystkich wiarygodnych nadawców)
• Wydajne (w ramach ograniczeń wyszukiwania)
• Ścisłe (z użyciem -all po walidacji)

Zapewnia to prawidłowe uwierzytelnianie i zapobiega nieuprawnionemu wykorzystaniu Twojej domeny do wysyłania wiadomości e-mail.

Jak utworzyć i opublikować rekord SPF

Skonfigurowanie rekordu SPF wymaga zidentyfikowania wszystkich autoryzowanych źródeł wysyłania, jednoznacznego zdefiniowania ich w systemie DNS oraz sprawdzenia, czy konfiguracja działa zgodnie z oczekiwaniami. Wykonaj kolejno wszystkie 5 poniższych kroków.

Krok 1: Zidentyfikuj wszystkie źródła wysyłek

Wymień wszystkie usługi, które wysyłają wiadomości e-mail w imieniu Twojej domeny. Zazwyczaj obejmuje to głównego dostawcę poczty elektronicznej (np. Google Workspace lub Microsoft 365), platformy marketingowe (takie jak Mailchimp lub HubSpot), systemy zarządzania relacjami z klientami (CRM) (np. Salesforce), narzędzia do obsługi klienta (np. Zendesk) oraz usługi poczty transakcyjnej (np. SendGrid, Amazon SES). Każda z tych usług wysyła wiadomości z innej infrastruktury, więc wszystkie muszą być wyraźnie autoryzowane. Większość dostawców publikuje w swojej dokumentacji wartość SPF include, która informuje serwery odbiorcze, aby ufały ich adresom IP nadawców.

Krok 2: Utwórz rekord SPF

Rekord SPF to jednowierszowy wpis typu TXT, który zaczyna się od v=spf1. Następnie definiuje się autoryzowanych nadawców za pomocą następujących mechanizmów:

• obejmują: w przypadku usług stron trzecich (np. include:_spf.google.com)
• ip4: lub ip6: dla konkretnych adresów IP lub zakresów adresów, które kontrolujesz
  Mechanizmy są oceniane od lewej do prawej. Na końcu definiujesz regułę:
• ~all (miękki błąd) oznacza nieautoryzowanych nadawców jako podejrzanych
• -all (błąd krytyczny) wyraźnie je odrzuca

Przykład:

v=spf1 include:_spf.google.com include:servers.mcsv.net ip4:198.51.100.0/24 ~all

Ten wpis określa serwerom odbierającym, które źródła są dozwolone i jak należy traktować pozostałe.

Krok 3: Opublikuj wpis w systemie DNS

Zaloguj się do swojego dostawcy usług DNS (np. Cloudflare, Route 53 lub GoDaddy). Utwórz nowy rekord TXT dla swojej domeny głównej:

• Host/Nazwa: @ (lub pozostaw puste, w zależności od dostawcy)
• Wartość: pełny wpis SPF
  Po zapisaniu rekord staje się publicznie dostępny za pośrednictwem DNS. Propagacja zmian może zająć trochę czasu.

Krok 4: Sprawdź poprawność wpisu

Po opublikowaniu sprawdź, czy:

• Rekord SPF ma poprawny format (nie zawiera błędów składniowych)
• Wszystkie elementy działają poprawnie
• Łączna liczba zapytań DNS nie przekracza limitu 10 (w przypadku przekroczenia limitu SPF zwraca błąd PermError)

Walidacja gwarantuje, że serwery odbiorcze będą w stanie bezbłędnie przetworzyć Twój rekord.

Krok 5: Sprawdzaj wyniki SPF

Konfiguracja SPF nie jest jednorazowa. W miarę dodawania lub usuwania źródeł wysyłania należy aktualizować rekord SPF. Aby monitorować działanie:

• Włącz DMARC , aby otrzymywać zbiorcze raporty przedstawiające wskaźniki pozytywnych i negatywnych wyników SPF
• Sprawdź, które źródła przechodzą uwierzytelnianie, a które nie
• Usuń nieużywane usługi i popraw nieprawidłowe lub nieautoryzowane adresy nadawców

Ważne: Dopuszczalny jest tylko jeden rekord SPF na domenę. Jeśli istnieje wiele rekordów TXT zaczynających się od v=spf1 , ocena SPF kończy się całkowitym niepowodzeniem i generuje błąd PermError. Zawsze należy łączyć wszystkie źródła wysyłające w jeden, kompletny rekord.

Limit wyszukiwania DNS o współczynniku SPF 10 (i dlaczego powoduje to problemy z pocztą elektroniczną)

Sprawdzanie SPF nie ma nieograniczonych możliwości. Zgodnie z RFC 7208 serwer odbierający może wykonać maksymalnie 10 zapytań DNS podczas przetwarzania rekordu SPF. Jeśli limit ten zostanie przekroczony, SPF zwraca błąd PermError (błąd trwały), a weryfikacja kończy się całkowitą porażką.

Nie jest to częściowa awaria. Błąd PermError oznacza, że nie można w ogóle przeprowadzić weryfikacji SPF. W rezultacie każda wiadomość e-mail wysłana z Twojej domeny nie przechodzi uwierzytelnienia SPF, niezależnie od tego, czy nadawca jest autentyczny.

Co wlicza się do limitu 10 wyszukiwań?

Następujące mechanizmy powodują wyszukiwanie adresów DNS:

• obejmują: (najczęstsze i mające największy wpływ)
• a
• mx
• ptr (przestarzałe, ale nadal się liczy, jeśli jest używane)
• istnieje:
• przekierowanie=

Mechanizmy „ip4:” i „ip6:” nie są uwzględniane w limicie wyszukiwań, ponieważ odwołują się bezpośrednio do adresów IP i nie wymagają rozpoznawania DNS

Dlaczego łatwo jest przekroczyć ten limit

Główny problem wynika z zagnieżdżonych (rekurencyjnych) wyszukiwań.

Dodając instrukcję `include:`, nie tylko dodajesz jedno odwołanie, ale także przejmujesz całą zawartość rekordu SPF tego dostawcy.

Na przykład:

• Dodajesz Google → Lista SPF firmy Google może obejmować wiele innych domen
• Dodajesz pakiet Microsoft 365 → dodaje kilka dodatkowych wpisów
• Uwzględniasz narzędzia marketingowe i transakcyjne → każde z nich dodaje swój własny łańcuch

Liczba tych operacji szybko się kumuluje. Nawet jeśli lista wydaje się krótka, rzeczywista liczba operacji wyszukiwania może przekroczyć 10 podczas przetwarzania.

Ograniczenie dotyczące 2 „nieprawidłowych wyszukiwań” (często pomijane)

SPF nakłada również ograniczenie do 2 nieudanych prób wyszukiwania.

Wyszukiwanie bez wyników ma miejsce, gdy zapytanie DNS nie zwraca żadnego wyniku (błąd „Non-Existent Domain” (NXDOMAIN) lub pusta odpowiedź).

Najczęstsze przyczyny:

• Nieprawidłowe lub nieaktualne dane obejmują: domeny
• Błędy w mechanizmach SPF
• Odwołania do domen, które już nie istnieją

Jeśli wystąpią więcej niż dwa nieudane wyszukiwania, SPF ponownie zwraca błąd PermError.

A PermError nie oznacza „niepowodzenia dla niektórych nadawców”. Oznacza to:

• Współczynnik SPF został uznany za nieprawidłowy
• Serwery odbierające nie mogą uznać Twojej polityki SPF za wiarygodną
• SPF w praktyce nie zapewnia żadnej ochrony ani uwierzytelniania

Ponieważ SPF jest jednym z sygnałów wykorzystywanych przez DMARC, może to również prowadzić do:

• Błędy DMARC (jeśli DKIM nie jest zgodny)
• Wzrost liczby spamowych ogłoszeń
• Odrzucenie wiadomości przez bardziej rygorystycznych odbiorców

Wraz z rozwojem infrastruktury poczty elektronicznej rekord SPF w naturalny sposób staje się coraz bardziej złożony. Bez aktywnego zarządzania:

• Liczba wyszukiwań rośnie w tle
• Niewykorzystane usługi pozostają w rejestrze
• Błędy kumulują się z biegiem czasu

SPF ma tę wadę. Działa niezawodnie tylko wtedy, gdy dane są przechowywane w określonych granicach, są dokładne i stale aktualizowane.

Jak szybko osiągniesz limit (prawdziwy przykład)

Oto jak wygląda typowy zestaw rozwiązań SaaS dla średnich przedsiębiorstw pod kątem wyszukiwań DNS:

Nie dodałeś jeszcze nawet Zendesk, SendGrid, swojego systemu obsługi klienta ani dostawcy usług płacowych. Jeśli Twoja organizacja korzysta z Google Workspace oraz czterech lub pięciu narzędzi SaaS do wysyłania wiadomości e-mail, prawdopodobnie osiągnąłeś już limit lub go przekroczyłeś.

Jak rozwiązać problemy związane z limitem wyszukiwania SPF

Jeśli Twój rekord SPF przekracza limit 10 wyszukiwań DNS, musisz zmniejszyć jego złożoność bez zakłócania działania legalnych nadawców. Oto trzy praktyczne sposoby, uporządkowane według stopnia skuteczności:

Usuń zbędne mechanizmy

Zacznij od dokładnego sprawdzenia swojego rekordu SPF.

• Wymień wszystkie w tym: i mechanizm obecnie wymieniony
• Sprawdź, czy każda z usług nadal aktywnie wysyła wiadomości e-mail z Twojej domeny
• Usuń wszystko, czego już nie używasz

Typowe problemy:

• Stare narzędzia marketingowe, które pozostały w archiwum
• Duplikaty wpisów w różnych subdomenach
• Usługi testowe lub tymczasowe nigdy nie zostały usunięte

Każdy niewykorzystany plik: które natychmiast usuniesz, zwolni jedno lub więcej wyszukiwań DNS. Jest to najprostszy i najmniej ryzykowny sposób na powrót poniżej limitu.

Zastąp dołącz: na ip4:/ip6: tam, gdzie to możliwe

Jeśli nadawca korzysta ze stałego, niewielkiego zestawu adresów IP, można zastąpić jego dołącz: na bezpośrednie wpisy adresów IP.

• Przykład: zamień include:vendor.com na ip4:x.x.x.x
• Spowoduje to całkowite wyłączenie sprawdzania DNS dla tego nadawcy

Kiedy to działa dobrze:

• Infrastruktura wewnętrzna
• Adresy IP z dedykowanego zakresu od dostawcy
• Dostawcy posiadający jasno udokumentowane, stałe zakresy adresów IP

Kwestie, które należy wziąć pod uwagę:

• Przejmujesz odpowiedzialność za konserwację
• Jeśli dostawca zaktualizuje lub zmieni adresy IP, Twój rekord SPF stanie się nieaktualny
• Może to powodować niewidoczne błędy SPF, dopóki nie zostaną usunięte

Należy stosować tę opcję wyłącznie w sytuacjach, gdy można przewidzieć stabilność adresu IP.

Zastosowanie makra spłaszczające SPF lub makra SPF

Kiedy korzystasz z wielu usług innych firm, samo ręczne porządkowanie danych zazwyczaj nie wystarcza. Potrzebujesz sposobu na ograniczenie liczby wyszukiwań bez utraty zakresu danych.

SPF Spłaszczenie

• Rozwiązuje wszystkie w tym: mechanizmy na odpowiadające im adresy IP
• Zastępuje je płaską listą zawierającą ip4: / ip6: wpisów
• Eliminuje większość operacji wyszukiwania DNS

Ograniczenie:

• Spłaszczone rekordy są statyczne
• Jeśli dostawca (np. Google lub Microsoft) zaktualizuje swoje adresy IP, z których wysyła wiadomości, Twój wpis nie zostanie zaktualizowany automatycznie
• Powoduje to powstanie luki, w wyniku której prawidłowe wiadomości e-mail mogą nie przejść weryfikacji SPF bez żadnego ostrzeżenia

Makra SPF (wersja dynamiczna)

• Zachowaj dynamiczny charakter oceny SPF przy jednoczesnej kontroli głębokości wyszukiwania
• Ograniczanie zależności od długich łańcuchów plików do włączenia
• Rozwiązanie lepiej sprawdzające się w środowiskach, w których infrastruktura nadawców ulega częstym zmianom

Nie was, ile wpisów wykorzystuje Twój rekord SPF? Sprawdź liczbę wpisów za pomocą naszego bezpłatnego narzędzia do sprawdzania rekordów SPF

Dla organizacji, które muszą zmieścić się w limicie 10 zapytań bez konieczności ręcznego zarządzania DNS, rozwiązanie PowerDMARC PowerSPF oferuje zarówno tradycyjne spłaszczanie , jak i nowoczesne makra SPF, co pozwala wybrać technikę najlepiej pasującą do danego środowiska. Rekord aktualizuje się automatycznie, gdy zewnętrzni dostawcy zmieniają swoje autoryzowane zakresy adresów IP.

Dlaczego sam filtr SPF to za mało

Protokół SPF stanowi podstawową metodę uwierzytelniania, jednak nie został zaprojektowany z myślą o zapewnieniu pełnej ochrony przed współczesnymi metodami spoofingu i nadużyciami. Ma trzy zasadnicze ograniczenia, które sprawiają, że sam w sobie jest niewystarczający.

Ograniczenie 1: SPF sprawdza nadawcę koperty, a nie nagłówek „From”

SPF weryfikuje pole Return-Path (nadawcę koperty), czyli domenę używaną podczas przesyłania wiadomości e-mail. Użytkownicy widzą jednak nagłówek „Od”, który może się różnić.

Powoduje to powstanie luki, którą mogą wykorzystać osoby atakujące:

• Atakujący wysyła wiadomość e-mail ze swojej własnej domeny (która przechodzi test SPF)
• Ustawili oni widoczny adres nadawcy tak, aby wyświetlał się jako adres z Twojej domeny lub zaufanej osoby
• Test SPF zakończył się powodzeniem, ponieważ domena nadawcy jest prawidłowa
• Odbiorca nadal widzi sfałszowaną tożsamość

SPF nie posiada wbudowanej funkcji pozwalającej sprawdzić, czy domena nadawcy zgadza się z widocznym nadawcą. DMARC rozwiązuje ten problem poprzez egzekwowanie zgodności między SPF (lub DKIM) a domeną w nagłówku „From”.

Ograniczenie 2: Usługa SPF przestaje działać w przypadku przekazywania wiadomości e-mail

System SPF opiera się na adresie IP serwera wysyłającego. Gdy wiadomość e-mail jest przekazywana dalej:

• Serwer przekaźnikowy staje się nowym źródłem wysyłania
• Jego adres IP jest porównywany z rekordem SPF oryginalnej domeny. Ponieważ serwer przekierowujący nie figuruje na liście autoryzowanych nadawców, weryfikacja SPF kończy się niepowodzeniem.
• Ponieważ nie ma go na liście, SPF nie działa

Dzieje się tak nawet wtedy, gdy wiadomość e-mail jest całkowicie wiarygodna. Nie jest to błąd konfiguracji, lecz ograniczenie wynikające z zasad działania protokołu SPF.

Skutki:

• Legalne wiadomości e-mail przekazane dalej często nie przechodzą testu SPF
• Systemy odbiorcze muszą opierać się na innych sygnałach (takich jak DKIM) w celu weryfikacji wiadomości

Ograniczenie 3: System SPF sam w sobie nie posiada mechanizmu raportowania

SPF nie oferuje żadnych wbudowanych funkcji raportowania.

Bez dodatkowej warstwy:

• Nie wiesz, które źródła przechodzą test SPF, a które nie
• Nie można wykrywać nieautoryzowanych nadawców korzystających z Twojej domeny
• Nie masz wglądu w problemy związane z uwierzytelnianiem, które wpływają na dostarczalność

DMARC oferuje funkcję raportowania, dzięki czemu otrzymujesz zbiorcze dane dotyczące wyników SPF i DKIM dla wszystkich odbiorców.

Współczesna infrastruktura poczty elektronicznej, obejmująca przekazywanie wiadomości, listy mailingowe, nadawców zewnętrznych oraz zaawansowane metody fałszowania adresów, przerosła możliwości samego protokołu SPF. DKIM dodaje podpis kryptograficzny, który pozostaje nienaruszony podczas przekazywania wiadomości, rozwiązując tym samym największą słabość SPF. DMARC to warstwa polityki, która łączy SPF i DKIM z nagłówkiem „From”.

Aby zapoznać się z pełnym porównaniem działania tych protokołów, zapoznaj się z naszym przewodnikiem na temat SPF vs DKIM vs DMARC.

Typowe błędy w rekordach SPF (i jak je naprawić)

Większość awarii systemu SPF wynika z kilku powtarzających się problemów. Głównym powodem jest zazwyczaj brak konserwacji i weryfikacji. Oto jak je zidentyfikować i naprawić, stosując konkretne działania.

Błąd 1: Wiele rekordów SPF w tej samej domenie.

SPF wymaga jednej, wiążącej polityki. Jeśli wiele rekordów TXT zaczyna się od v=spf1, serwery odbierające nie są w stanie określić, który z nich należy ocenić. Skutkiem tego jest błąd PermError, co oznacza, że SPF całkowicie zawodzi w przypadku każdej wiadomości.

Dlaczego tak się dzieje:

• Różne zespoły dodają wpisy samodzielnie (marketing, IT, narzędzia wsparcia)
• Nowi dostawcy przekazują instrukcje typu „dodaj ten wpis” bez sprawdzania dotychczasowej konfiguracji

Jak to naprawić:

• Sprawdź wszystkie rekordy TXT dla swojej domeny
• Zidentyfikuj wszystkie wpisy związane z SPF
• Połącz wszystkie mechanizmy w jeden kompletny zapis

Na co warto zwrócić uwagę:

• Fragmenty dokumentacji pozostałe po migracjach
• Poddomeny używane nieprawidłowo zamiast domeny głównej 

Błąd 2: Przekroczenie limitu 10 wyszukiwań DNS

Gdy liczba sprawdzeń DNS w ramach weryfikacji SPF przekroczy 10, proces zostaje natychmiast przerwany i zwracany jest błąd PermError. Powoduje to unieważnienie certyfikatu SPF dla wszystkich nadawców, nawet tych legalnych.

Dlaczego tak się dzieje:

• Nadmierne stosowanie obejmuje: dla wielu narzędzi SaaS
• Wbudowane pliki z dostawców (ty je dołączasz, a one z kolei dołączają inne)
• Brak wglądu w łączną liczbę wyszukiwań

Jak to naprawić:

• Należy przeanalizować każdy mechanizm i jego wpływ na wyszukiwanie
• Najpierw usuń nieużywane lub zbędne pliki dołączane
• Zastanów się, czy każde narzędzie naprawdę musi wysyłać wiadomości z Twojej domeny

Na co warto zwrócić uwagę:

• „Ukryte” odwołania w plikach dołączanych innych producentów
• Stopniowe rozbudowywanie w miarę upływu czasu wraz z dodawaniem nowych narzędzi

Błąd 3: Używanie +all (przekaż wszystko)

To wyraźnie nakazuje serwerom odbierającym, by ufały każdemu nadawcy, co w praktyce uniemożliwia wykorzystanie SPF jako środka zabezpieczającego.

Dlaczego tak się dzieje:

• Błędna interpretacja składni SPF
• Tymczasowe konfiguracje testowe nigdy nie zostały przywrócone

Jak to naprawić:

• Zastąp przez ~wszystkie podczas sprawdzania poprawności konfiguracji
• Przejdź do -wszystkich po potwierdzeniu wszystkich legalnych nadawców

Na co warto zwrócić uwagę:

• Stare zapisy skopiowane z niewiarygodnych źródeł
• Domeny, które wydają się „uwierzytelnione”, ale nie są w rzeczywistości chronione

Błąd 4: Używanie przestarzałego ptr .

Mechanizmy takie jak ptr powodują powolne i zawodne wyszukiwanie i mogą być ignorowane przez nowoczesne odbiorniki, co prowadzi do niespójnych wyników SPF.

Dlaczego tak się dzieje:

• Konfiguracje historyczne przenoszone z biegiem czasu
• Nieaktualna dokumentacja lub szablony

Jak to naprawić:

• Należy usunąć przestarzałe mechanizmy, takie jak ptr
• Zastąpić wyraźnym : lub ip4: / ip6: wpisy

Na co warto zwrócić uwagę:

• Nadmiernie skomplikowane zapisy, które mają uwzględniać skrajne przypadki
• Mechanizmy, które zwiększają złożoność bez wyraźnych korzyści

Błąd 5: Brak wiarygodnych źródeł wysyłki

Wiadomości e-mail wysłane z legalnych platform nie przechodzą testu SPF, co może skutkować:

• Wiadomości trafiające do folderu ze spamem
• Opóźnienia w dostawie lub odmowa przyjęcia przesyłki
• Błędy DMARC w przypadku braku odpowiedniego rozwiązania awaryjnego

Dlaczego tak się dzieje:

• Dodano nowe narzędzia bez aktualizacji pliku SPF
• Brak koordynacji między zespołami zarządzającymi systemami poczty elektronicznej

Jak to naprawić:

• Prowadź scentralizowaną listę wszystkich zatwierdzonych źródeł wysyłania
• Włączanie elementów SPF należy uwzględnić w procesie wdrażania — a nie dopiero po pojawieniu się problemów
• Należy regularnie sprawdzać, czy uwzględniono wszystkich aktywnych nadawców

Na co warto zwrócić uwagę:

• Systemy transakcyjne (rozliczeniowe, powiadomienia) są często pomijane
• Narzędzia regionalne lub przeznaczone dla konkretnych zespołów, wysyłane niezależnie

Błąd 6: Rekord SPF zawierający więcej niż 255 znaków w jednym ciągu DNS

Rekordy SPF, które przekraczają limity DNS lub mają nieprawidłowy format, mogą zostać skrócone lub błędnie zinterpretowane, co może prowadzić do niewidocznych awarii.

Dlaczego tak się dzieje:

• Zbyt wiele instrukcji INCLUDE i mechanizmów w jednym rekordzie
• Dostawcy usług DNS różnie traktują długie wartości rekordów TXT

Jak to naprawić:

• Staraj się, aby zapis był jak najkrótszy
• W razie potrzeby można użyć wielu ciągów znaków w cudzysłowie w jednym rekordzie TXT
• Po zapisaniu sprawdź ponownie opublikowany wpis (a nie tylko wprowadzone dane)

Na co warto zwrócić uwagę:

• Zapisy, które w panelu DNS wyglądają na poprawne, ale nie są poprawnie rozpoznawane
• Problemy z formatowaniem powstałe podczas ręcznej edycji

Przeprowadź bezpłatną kontrolę stanu SPF, aby sprawdzić, czy w Twoim rekordzie występują któreś z tych błędów

Najlepsze praktyki dotyczące SPF na rok 2026

Prawidłowy rekord SPF to nie tylko kwestia składni. Chodzi o przestrzeganie zasad, które pozostają aktualne wraz z rozwojem infrastruktury pocztowej. Te sprawdzone praktyki pomogą zapewnić, że konfiguracja SPF będzie niezawodna, wydajna i zgodna z aktualnymi wymaganiami stawianymi nadawcom.

1. Należy utrzymywać tylko jeden rekord SPF na domenę

SPF dopuszcza tylko jeden rekord TXT zaczynający się od v=spf1. Wiele rekordów powoduje błąd PermError, całkowicie uniemożliwiając uwierzytelnienie. Zawsze scalaj nowe wpisy z istniejącym rekordem.

2. Należy uwzględnić wszystkie legalne źródła wysyłki

Twój rekord SPF musi uwzględniać wszystkie systemy, które wysyłają wiadomości e-mail w Twoim imieniu. Pominięcie jakiegokolwiek nadawcy powoduje błędy SPF, co ma bezpośredni wpływ na dostarczalność wiadomości oraz zgodność z protokołem DMARC.

3. Nie przekraczaj limitu 10 zapytań DNS

Każdy zawiera:, a, mx, istnieje:, oraz redirect= liczy się do limitu. Przekroczenie 10 powoduje błąd PermError, unieważniający SPF dla wszystkich wiadomości e-mail. Regularnie sprawdzaj i optymalizuj swój rekord.

4. Usuń nieużywane lub nieaktualne pliki dołączane

Stare narzędzia, środowiska testowe i wycofane usługi często pozostają w rekordach SPF długo po tym, jak przestają wysyłać dane. Powoduje to niepotrzebne komplikacje i zużywa limit zapytań.

5. Wybierz ip4: oraz ip6: w przypadku infrastruktury kontrolowanej

Jeśli zarządzasz dedykowanymi adresami IP lub stabilnymi zakresami adresów wysyłkowych, korzystaj z mechanizmów bezpośredniego wysyłania z IP zamiast include:. Zmniejsza to liczbę wyszukiwań DNS i poprawia wydajność.

6. Unikaj używania +wszystkich w żadnym wypadku

W +all kwalifikator pozwala dowolnemu serwerowi wysyłać wiadomości w imieniu Twojej domeny, co w praktyce wyłącza SPF jako mechanizm zabezpieczający. Nie należy go nigdy używać w środowisku produkcyjnym.

7. Użyj ~wszystkich podczas konfiguracji, a następnie przejdź do -all

Zacznij od ~all (softfail) podczas sprawdzania poprawności konfiguracji. Gdy wszyscy legalni nadawcy zostaną potwierdzeni i dostosowani do DMARC, przełącz na -all (hardfail), aby zapewnić ścisłe egzekwowanie zasad.

8. Należy unikać przestarzałych lub ryzykownych mechanizmów, takich jak ptr

Wskaźnik mechanizm jest przestarzały i zawodny. Powoduje niepotrzebne wyszukiwania DNS i może być ignorowany przez nowoczesne odbiorniki. Zamiast tego należy stosować mechanizmy jawne.

9. Monitoruj skuteczność SPF za pomocą raportów DMARC

Sam w sobie SPF nie zapewnia wglądu w dane. Włącz raportowanie DMARC, aby śledzić, które źródła przechodzą lub nie przechodzą weryfikację SPF u wszystkich odbiorców, oraz wykrywać nieautoryzowaną aktywność.

10. Traktuj system SPF jako system wymagający stałego nadzoru

Konfiguracja SPF nie jest działaniem jednorazowym. Każde nowe narzędzie, platforma lub dostawca wysyłający wiadomości e-mail musi zostać uwzględniony w rekordzie SPF. Należy go regularnie sprawdzać i aktualizować, aby zapobiec niewidocznym awariom.

Jak działa SPF w połączeniu z DKIM i DMARC

Protokół SPF, DKIM i DMARC zostały zaprojektowane tak, by działały jako spójny system. Każdy z nich rozwiązuje inny aspekt problemu zaufania do wiadomości e-mail, w tym kwestię autentyczności nadawcy, integralności wiadomości oraz zgodności tożsamości, a jedynie razem zapewniają niezawodną ochronę i egzekwowanie zasad.

Po otrzymaniu wiadomości e-mail uwierzytelnianie odbywa się w kilku etapach:

• SPF sprawdza, czy adres IP serwera wysyłającego jest autoryzowany dla domeny podanej w polu Return-Path (nadawca koperty)
• DKIM weryfikuje podpis kryptograficzny dołączony do wiadomości, potwierdzając, że nie została ona zmieniona oraz że domena podpisująca jest prawidłowa
• DMARC analizuje wyniki sprawdzania SPF i DKIM oraz weryfikuje, czy któryś z nich jest zgodny z widocznym adresem nadawcy

Protokół SPF i DKIM generują surowe wyniki uwierzytelniania, ale to DMARC określa, czy wyniki te mają znaczenie w kontekście tego, co faktycznie widzi odbiorca.

Potrzebujesz zarówno SPF, jak i DKIM, ponieważ każda z tych metod rekompensuje słabe strony drugiej. SPF przestaje działać w przypadku przekazywania wiadomości, podczas gdy DKIM zachowuje swoją skuteczność. Niektórzy pośrednicy mogą usunąć podpis DKIM, natomiast SPF nie zależy od treści wiadomości. Razem zapewniają one nadmiarowość.

DMARC wprowadza warstwę zasad: co powinni zrobić odbiorcy, gdy zarówno SPF, jak i DKIM nie spełniają wymogów zgodności? Dostępne są trzy opcje: brak (tylko monitorowanie), kwarantanna (przesłanie do spamu) oraz odrzucenie (całkowite zablokowanie). DMARC zapewnia również raportowanie – bez niego nigdy nie wiadomo, kiedy uwierzytelnianie się nie powiodło.

Wniosek

Profil SPF stanowi podstawę uwierzytelniania wiadomości e-mail, ale jego skuteczność zależy od poprawności konfiguracji, a przydatność – od systemu DMARC, do którego jest on podłączony. Nieprawidłowo skonfigurowany rekord SPF zakłóca dostarczanie wiadomości e-mail, naraża domenę na ataki typu spoofing oraz powoduje, że organizacja nie spełnia aktualnych wymogów dotyczących nadawców.

Następny krok jest taki sam, niezależnie od tego, czy konfigurujesz SPF po raz pierwszy, czy też próbujesz naprawić uszkodzony wpis: sprawdź aktualną konfigurację.

Sprawdź konfigurację uwierzytelniania poczty e-mail swojej domeny za pomocą naszego bezpłatnego narzędzia Domain Analyzer . W ciągu kilku sekund ocenia on SPF, DKIM, DMARC i inne. Potrzebujesz ciągłego monitorowania, automatycznego zarządzania SPF i raportowania DMARC? 

Rozpocznij 15-dniowy bezpłatny okres próbny

Najczęściej zadawane pytania

Czy domena może mieć więcej niż jeden rekord SPF?

Nie. Standard RFC 7208 wymaga dokładnie jednego rekordu SPF na domenę. Jeśli istnieją dwa rekordy TXT zaczynające się od v=spf1 , oba zwracają PermError, a weryfikacja SPF kończy się całkowitą porażką. Połącz wszystkie autoryzowane źródła w jeden rekord.

Co to znaczy, jeśli moja domena generuje zbyt wiele zapytań DNS?

Twój rekord SPF przekracza limit 10 wyszukiwań DNS określony w RFC 7208. Powoduje to błąd SPF PermError, który uniemożliwia uwierzytelnianie SPF dla wszystkich wiadomości e-mail – nie tylko dla tych, które spowodowały przekroczenie limitu. Ogranicz liczbę wpisów „includes” i zastąp je ip4:/ip6:lub użyj spłaszczania SPF lub makr, aby pozostać poniżej limitu.

Jaka jest różnica między opcją SPF softfail (~all) a hardfail (-all)?

Błąd niekrytyczny (~all) nakazuje odbiorcom zaakceptować wiadomość e-mail, ale oznaczyć ją jako podejrzaną. Hardfail (-all) nakazuje odbiorcom odrzucić wiadomość e-mail bez wahania. Używaj softfail podczas wstępnej konfiguracji i testowania; przełącz na hardfail, gdy wszyscy legalni nadawcy zostaną potwierdzeni, a DMARC będzie już wdrożony.

Czy protokół SPF zapobiega fałszowaniu adresów e-mail?

Nie samo w sobie. SPF sprawdza nadawcę koperty (Return-Path), a nie nagłówek „From”, który widzą odbiorcy. Atakujący może przejść weryfikację SPF, podszywając się pod widoczny adres „From”. Aby zapobiec fałszowaniu nazwy wyświetlanej, potrzebny jest protokół DMARC, który sprawdza zgodność wyników SPF/DKIM z nagłówkiem „From”.

Co się dzieje, gdy system SPF zawiedzie?

Zależy to od kwalifikatora SPF oraz od tego, czy skonfigurowano DMARC. W przypadku -all i polityką odrzucania DMARC wiadomość e-mail zostanie zablokowana. Przy ustawieniu ~all i braku DMARC wiadomość e-mail może nadal zostać dostarczona, ale zostanie oznaczona jako podejrzana. Bez SPF odbiorcy nie mają sygnału SPF do oceny.

Jak sprawdzić swój rekord SPF?

Skorzystaj z bezpłatnego narzędzia do sprawdzania rekordów SPF. Wprowadź swoją domenę, a narzędzie pobierze Twój rekord SPF z DNS, sprawdzi poprawność składni, policzy liczba zapytań DNS i zaznaczy wszelkie błędy – w tym naruszenia PermError i void lookup.

Czy potrzebuję SPF, skoro mam już DKIM i DMARC?

Tak. DMARC wymaga, aby co najmniej jeden z mechanizmów – SPF lub DKIM – przeszedł test i zapewnił zgodność. Chociaż sam DKIM może spełnić wymagania DMARC, posiadanie zarówno SPF, jak i DKIM zapewnia nadmiarowość. Jeśli jeden z nich zawiedzie (na przykład SPF przestaje działać podczas przekazywania wiadomości), drugi nadal może zapewnić zgodność z DMARC.

Co to jest wyrównanie SPF?

Zgodność SPF oznacza, że domena w polu Return-Path (nadawca koperty) jest zgodna z domeną w nagłówku From. DMARC sprawdza tę zgodność. Bez niej test SPF może zakończyć się powodzeniem, ale test DMARC nadal zakończy się niepowodzeniem – tak właśnie dzieje się w przypadku wielu zewnętrznych nadawców, chyba że są oni skonfigurowani tak, by używać Twojej domeny w polu Return-Path.

Jak często należy aktualizować rekord SPF?

Sprawdzaj swój rekord SPF za każdym razem, gdy dodajesz lub usuwasz usługę wysyłkową, a także przeprowadzaj audyt co najmniej raz na kwartał. Rekordy SPF tracą ważność w miarę jak dostawcy zmieniają zakresy adresów IP oraz w miarę ewolucji infrastruktury wysyłkowej Twojej organizacji. Rekord SPF, który był ważny sześć miesięcy temu, może być dziś nieprawidłowy lub niekompletny.

Czym jest spłaszczanie SPF?

Wyrównanie SPF rozwiązuje wszystkie obejmuje: mechanizmów na surowe adresy IP, zmniejszając liczbę wyszukiwań DNS. Dzięki temu pozostajesz poniżej limitu 10 wyszukiwań, ale tworzysz statyczny rekord, który musi być aktualizowany za każdym razem, gdy dostawca zmienia swoje adresy IP. Nowoczesne alternatywy, takie jak makra SPF, utrzymują rekord w stanie dynamicznym, pozostając jednocześnie poniżej limitu.

• O
• Latest Posts

Ahona Rudra

Ekspert ds. bezpieczeństwa domen i poczty e-mail w PowerDMARC

Ahona jest Marketing Managerem w PowerDMARC, z ponad 5-letnim doświadczeniem w pisaniu na tematy związane z cyberbezpieczeństwem, specjalizującym się w bezpieczeństwie domen i poczty elektronicznej. Ahona posiada dyplom ukończenia studiów podyplomowych w zakresie dziennikarstwa i komunikacji, umacniając swoją karierę w sektorze bezpieczeństwa od 2019 roku.

Latest posts by Ahona Rudra (zobacz wszystkie)

• Zasady ochrony przed phishingiem w usłudze Office 365: jak je skonfigurować - 3 czerwca 2026 r.
• Bezpieczeństwo agentów AI: zagrożenia, najlepsze praktyki i uwierzytelnianie wiadomości e-mail – 2 czerwca 2026 r.
• PowerDMARC jest teraz zintegrowany z HaloPSA – 1 czerwca 2026 r.