Kluczowe wnioski
- Rekord SPF informuje serwery pocztowe odbierające wiadomości, które adresy IP są uprawnione do wysyłania wiadomości e-mail w imieniu Twojej domeny.
- Adres IP należy dodać, korzystając z mechanizmu „ip4:” lub „ip6:” w istniejącym rekordzie SPF typu TXT; w żadnym wypadku nie należy tworzyć drugiego rekordu SPF. W danej domenie może istnieć tylko jeden taki rekord.
- W przypadku usług zewnętrznych (Google Workspace, Microsoft 365, Mailchimp, SendGrid itp.) należy stosować mechanizm „include:” zamiast podawać bezpośrednie adresy IP. Rozwiązanie to nie wymaga dodatkowej konserwacji.
- Twój rekord SPF nie może przekraczać 10 operacji wyszukiwania DNS. Liczy się każda operacja typu „include:”, „a”, „mx” oraz mechanizm przekierowania. Nie liczą się natomiast operacje typu „ip4”, „ip6” oraz wszystkie inne mechanizmy.
- Po wprowadzeniu zmian zawsze sprawdź poprawność rekordu SPF. Nawet jeden błąd składniowy może w sposób niezauważalny zakłócić dostarczanie wiadomości e-mail dla całej domeny.
- Google, Yahoo i Microsoft wymagają obecnie od nadawców masowych wiadomości zgodności z protokołem DMARC. Jeśli korzystasz wyłącznie z SPF, nie spełniasz w pełni wymogów obowiązujących od 2026 roku.
Aby dodać adres IP do rekordu SPF, należy edytować istniejący rekord TXT SPF swojej domeny w systemie DNS i wstawić mechanizm „ip4:” (lub „ip6:”) przed mechanizmem „all”. Na przykład:
v=spf1 ip4:192.0.2.1 include:_spf.google.com -all
Ważne: NIE TWÓRZ drugiego rekordu SPF. Musisz edytować istniejący rekord i przed dodaniem surowego adresu IP sprawdzić, czy Twoja usługa wysyłkowa udostępnia zamiast tego wartość include:, co zazwyczaj jest lepszym wyborem w dłuższej perspektywie.
W tym przewodniku opisano krok po kroku cały proces, w tym wyszukiwanie aktualnego wpisu, wybór między opcjami „ip4” a „include”, edycję ustawień DNS u popularnych dostawców, sprawdzanie poprawności wyników oraz unikanie błędów, które co roku w sposób niezauważalny uniemożliwiają działanie poczty elektronicznej dla tysięcy domen.
Czym jest rekord SPF i dlaczego ma on znaczenie w 2026 roku?
SPF (Sender Policy Framework) to rekord DNS typu TXT, który zawiera listę adresów IP i usług uprawnionych do wysyłania wiadomości e-mail z Twojej domeny. Jeśli adres IP serwera nie znajduje się na tej liście, serwery pocztowe odbierające wiadomość mogą ją odrzucić lub oznaczyć jako podejrzaną.
Firma Google zaczęła egzekwować wymogów dotyczących uwierzytelniania nadawców masowych w lutym 2024 r., wymagając stosowania protokołów SPF lub DKIM oraz DMARC od wszystkich, którzy wysyłają ponad 5 000 wiadomości dziennie.
Od listopada 2025 r. wiadomości e-mail niezgodne z wymogami będą spotykały się z trwałym odrzuceniem – nie będzie to tymczasowe odłożenie, lecz twardy bounce. Firma Yahoo wprowadziła identyczne wymagania w tym samym terminie. Microsoft dołączył do nich w maju 2025 r., odrzucając nieautoryzowane wiadomości masowe z błędem 550.
Bez prawidłowego rekordu SPF Twoja domena jest narażona na ataki typu spoofing, a nawet Twoje prawidłowe wiadomości e-mail mogą zostać odrzucone przez serwisy Gmail, Yahoo i Outlook. Jeśli rekord SPF jest nieprawidłowy, Twoje wiadomości e-mail po prostu przestaną docierać do adresatów bez żadnych ostrzeżeń. Nie dotrą one do odbiorców bez żadnego powiadomienia, a dowiesz się o tym dopiero wtedy, gdy klient lub współpracownik poinformuje Cię, że nie otrzymał Twojej wiadomości.
Wyjaśnienie składni rekordów SPF (z przykładami)
Zanim dodasz cokolwiek do swojego rekordu, musisz zrozumieć, do czego służy każda z jego części. Oto budowa typowego rekordu SPF:
v=spf1 ip4:192.0.2.1 ip4:203.0.113.0/24 include:_spf.google.com -all
| Komponent | Co robi |
|---|---|
| v=spf1 | Tag wersji. Wymagany. Musi znajdować się na pierwszym miejscu. |
| ip4:192.0.2.1 | Uprawnia do korzystania z jednego adresu IPv4. Nie wymaga wyszukiwania w systemie DNS. |
| ip4:203.0.113.0/24 | Zezwala na użycie zakresu CIDR (256 adresów IP). Nie wymaga wyszukiwania w DNS. |
| ip6:2001:db8::1 | Przydziela adres IPv6. Nie wymaga wyszukiwania w systemie DNS. |
| obejmują:_spf.google.com | Przekierowuje do rekordu SPF innej domeny. Wymaga co najmniej jednego zapytania DNS. |
| a | Autoryzuje adresy IP z rekordu A domeny. Wykorzystuje 1 operację wyszukiwania. |
| mx | Autoryzuje adresy IP z serwerów MX domeny. Wykorzystuje 1 operację wyszukiwania. |
| -all | Hardfail. Odrzuć wszystko, czego nie ma na powyższej liście. |
| ~wszystkie | Błąd miękki. Oznacz wiadomość, ale nie odrzucaj nieautoryzowanej wiadomości e-mail. |
Oto trzy przykłady z życia wzięte, obejmujące różne poziomy złożoności:
Prosta konfiguracja (jeden serwer pocztowy):
v=spf1 ip4:198.51.100.25 -all
Typowa firma z sektora MŚP (Microsoft 365 + jedno narzędzie marketingowe):
v=spf1 include:spf.protection.outlook.com include:servers.mcsv.net -all
Złożone przedsiębiorstwo (wiele usług):
v=spf1 ip4:203.0.113.0/24 include:_spf.google.com include:spf.protection.outlook.com include:sendgrid.net include:spf.brevo.com -all
| Ważna zasada: Domena może mieć tylko JEDEN rekord SPF. Jeśli już go masz, MUSISZ go edytować. Nie dodawaj drugiego rekordu TXT zaczynającego się od v=spf1. Dwa rekordy SPF w tej samej domenie spowodują błąd PermError i uniemożliwią WSZELKIE uwierzytelnianie poczty elektronicznej. |
Chcesz stworzyć rekord od podstaw?
Użyj bezpłatnego generatora rekordów SPF firmy PowerDmarc , aby błyskawicznie utworzyć poprawny składniowo rekord.
Jak dodać adres IP do rekordu SPF (krok po kroku)
Dodanie adresu IP do rekordu SPF to jeden z najprostszych sposobów na uwierzytelnienie źródła wysyłki. Jest to zazwyczaj wymagane w przypadku korzystania z serwera dedykowanego, systemu poczty transakcyjnej lub dowolnej infrastruktury, nad którą sprawujesz kontrolę.
Chociaż sama zmiana jest prosta, dokładność ma znaczenie, ponieważ błędne wpisy lub problemy z formatowaniem mogą wpłynąć na proces uwierzytelniania i dostarczalność wiadomości. Poniższe kroki przedstawiają proces prawidłowego dodania adresu IP do rekordu SPF bez zakłócania dotychczasowej konfiguracji.
Krok 1: Znajdź swój aktualny rekord SPF
Wiele domen posiada już rekord SPF z poprzedniej konfiguracji. Jeśli utworzysz nowy bez sprawdzenia, powstają dwa rekordy, co powoduje awarię systemu.
Możesz sprawdzić swoje aktualne dane na dwa sposoby.
Skorzystaj z bezpłatnego narzędzia do sprawdzania SPF firmy PowerDMARC , aby uzyskać natychmiastowy wynik wizualny, lub uruchom zapytanie z wiersza poleceń:
nslookup -type=TXT twojadomena.com
dig TXT twojadomena.com

Zobacz, jak błyskawicznie sprawdzić swój rekord SPF i wykryć problemy konfiguracyjne, które mogą wpływać na dostarczalność wiadomości e-mail
Poszukaj rekordu TXT, który zaczyna się od v=spf1. Jeśli taki znajdziesz, to jest to Twój rekord SPF i będziesz go edytować w kroku 3. Jeśli widzisz dwa rekordy, które zaczynają się od v=spf1, to już masz problem – połącz je w jeden, zanim zrobisz cokolwiek innego.
Krok 2: Znajdź adres IP lub wpisz: wartość, którą chcesz dodać
Możliwe są dwa scenariusze, a właściwy wybór zależy od tego, na co udzielasz upoważnienia:
Scenariusz A: Dodajesz konkretny adres IP. Ma to zastosowanie, gdy prowadzisz własny serwer pocztowy na statycznym adresie IP lub dysponujesz dedykowanym adresem IP do wysyłania, nad którym sprawujesz kontrolę. Potrzebujesz dokładnego adresu IPv4 lub IPv6 serwera.
Scenariusz B: Autoryzujesz usługę zewnętrzną. Dotyczy to usług takich jak Mailchimp, SendGrid, HubSpot, Google Workspace lub Microsoft 365. W tym przypadku musisz podać wartość include: z dokumentacji tej usługi, a nie jej adresy IP.
Zanim dodasz surowy adres IP, zapoznaj się z poniższym rozdziałem poświęconym porównaniu opcji „ip4” i „include”. W przypadku większości usług zewnętrznych opcja „include:” stanowi lepszy wybór w perspektywie długoterminowej.
Krok 3: Edytuj rekord SPF w systemie DNS
Zaloguj się do panelu swojego dostawcy usług DNS (rejestratora domeny lub dostawcy usług hostingowych), znajdź rekordy TXT dla swojej domeny i edytuj istniejący rekord SPF. Dodaj nowy mechanizm „ip4:” lub „include:” PRZED mechanizmem „all”.
Oto jak to zrobić w przypadku najpopularniejszych dostawców:
- Cloudflare: Przejdź do sekcji DNS → Rekordy. Znajdź istniejący rekord TXT dla swojej domeny (@ lub root), który zaczyna się od v=spf1. Kliknij Edytuj. Dodaj nowy mechanizm przed tagiem all. Kliknij Zapisz.
- GoDaddy: Przejdź do sekcji Moje produkty → DNS → Rekordy DNS. Znajdź rekord TXT zawierający v=spf1. Kliknij Edytuj. Zmodyfikuj pole Wartość, dodając nowy mechanizm przed słowem all. Zapisz.
- Namecheap: Przejdź do Lista domen → Zarządzaj → Zaawansowane DNS. W sekcji Rekordy TXT znajdź wpis SPF. Edytuj go, aby dodać nowy mechanizm. Zapisz.
- AWS Route 53: Otwórz Hosted Zones → wybierz swoją domenę → znajdź rekord TXT z wartością v=spf1. Kliknij Edytuj. Zaktualizuj wartość (zachowaj cudzysłowy). Zapisz.
- cPanel: Przejdź do sekcji Dostarczalność wiadomości e-mail → kliknij Zarządzaj obok swojej domeny → przewiń do sekcji Sugerowany rekord SPF → kliknij Dostosuj. Dodaj nowy adres IP w sekcji Adres IP. Kliknij Zainstaluj.
| Wskazówka: Zmniejsz wartość TTL do 300 sekund (5 minut) PRZED wprowadzeniem zmian w rekordach SPF. Przyspiesza to propagację DNS i pozwala szybciej naprawić błędy. Poczekaj, aż wygaśnie stary TTL, a następnie wprowadź zmianę. Po potwierdzeniu, że rekord działa, zresetuj TTL do normalnej wartości. |
Krok 4: Sprawdź poprawność zaktualizowanego rekordu SPF
Wystarczy jedna źle umieszczona spacja, brakujący dwukropek lub zduplikowany wpis, by w sposób niezauważalny zakłócić działanie poczty elektronicznej w całej domenie. Sprawdzanie poprawności zajmuje 30 sekund i pozwala uniknąć wielogodzinnego rozwiązywania problemów.
Po każdej zmianie SPF przejrzyj poniższą listę kontrolną:
- Sprawdź swoją domenę za pomocą narzędzia do sprawdzania rekordów SPF i upewnij się, że rekord jest odczytywany bez błędów.
- Upewnij się, że widzisz tylko JEDEN rekord SPF (a nie dwa rekordy TXT zaczynające się od v=spf1).
- Sprawdź łączną liczbę wyszukiwań DNS. Musi wynosić 10 lub mniej.
- Sprawdź, czy cały mechanizm znajduje się na samym końcu taśmy.
- Wyślij wiadomość testową na konto Gmail lub Yahoo, otwórz ją, sprawdź oryginalne nagłówki i poszukaj wpisu „spf=pass”.
Aby przeprowadzić kompleksowy audyt bezpieczeństwa wykraczający poza protokół SPF, sprawdź swoją domenę za pomocą narzędzia do analizy domen PowerDMARC. Narzędzie to sprawdza protokoły SPF, DKIM, DMARC, MTA-STS i BIMI w jednym przebiegu.
Krok 5: Monitorowanie wyników uwierzytelniania SPF w czasie
Pierwszym krokiem jest dodanie adresu IP. Drugim krokiem jest sprawdzenie, czy rzeczywiście działa, oraz wykrycie ewentualnych późniejszych awarii.
Zestawione raporty DMARC stanowią główny sposób na uzyskanie bieżącego wglądu w wskaźniki pozytywnych i negatywnych wyników weryfikacji SPF dla poszczególnych nadawców. Bez monitorowania działasz na ślepo. Wielu administratorów odkrywa uszkodzony rekord SPF dopiero wtedy, gdy klienci zaczynają oznaczać prawidłowe wiadomości e-mail jako spam lub gdy narzędzie do fakturowania przez tygodnie wysyła wiadomości z nieautoryzowanego adresu IP, a nikt tego nie zauważa.
| Chcesz mieć stały wgląd we wszystkie adresy IP wysyłające wiadomości e-mail z Twojej domeny?
Panel raportowania DMARC w PowerDMARC pokazuje wskaźniki pozytywnych i negatywnych wyników SPF dla poszczególnych źródeł we wszystkich Twoich domenach w postaci przejrzystych wykresów, a nie surowego kodu XML. Rozpocznij bezpłatny 15-dniowy okres próbny → powerdmarc.com/free-dmarc-trial/ |
ip4 a include: czego lepiej używać? (Przewodnik po wyborze)
Kiedy stosować IPv4 (adresy IP w postaci surowej):
- Prowadzisz własny serwer pocztowy pod statycznym adresem IP, nad którym masz kontrolę.
- Posiadasz dedykowany adres IP do wysyłania wiadomości od dostawcy usług e-mailowych (nie jest to adres współdzielony).
- Zezwalasz na lokalny serwer przekaźnikowy SMTP o stałym adresie.
Zasada: używaj ip4: tylko wtedy, gdy TY kontrolujesz adres IP i nie ulegnie on zmianie.
Kiedy stosować include: (delegowany SPF):
- Wyrażasz zgodę na korzystanie z dowolnej usługi SaaS oferowanej przez podmioty zewnętrzne, takiej jak Google Workspace, Microsoft 365, Mailchimp, SendGrid, HubSpot, Salesforce, Zendesk lub dowolnego narzędzia do obsługi poczty elektronicznej w chmurze.
- Usługa korzysta z adresów IP współdzielonych lub zmiennych.
- Usługa publikuje własny rekord SPF, który sama aktualizuje.
Dlaczego warto to uwzględnić: w przypadku usług zewnętrznych prawie zawsze jest to lepsze rozwiązanie:
Usługi w chmurze regularnie zmieniają adresy IP. Jeśli na stałe zaprogramujesz ich aktualne adresy IP z przedrostkiem „ip4:”, Twój rekord SPF stanie się nieaktualny w momencie migracji infrastruktury, a wysyłanie wiadomości e-mail przestanie działać bez żadnego ostrzeżenia.
Mechanizm „include:” odwołuje się do własnego, dynamicznie aktualizowanego rekordu SPF danej usługi. Gdy usługa ta zaktualizuje swoje adresy IP, Twój rekord SPF automatycznie odzwierciedli te zmiany, bez konieczności wykonywania jakichkolwiek czynności z Twojej strony.
[Ilustracja: Schemat drzewa decyzyjnego — „Czy jest to serwer/adres IP, który posiadasz i nad którym sprawujesz kontrolę?” → TAK → Użyj adresu IPv4 / NIE → „Czy usługa udostępnia wartość include?” → TAK → Użyj include (zalecane) / NIE → Użyj adresu IPv4 + ustaw przypomnienie o kwartalnym przeglądzie]
[Tekst alternatywny: Schemat decyzyjny pokazujący, kiedy należy stosować adres IPv4, a kiedy mechanizm „include” w rekordach SPF]
Aby uzyskać więcej informacji na temat składni instrukcji include oraz najlepszych praktyk, zapoznaj się z pełnym przewodnikiem dotyczącym instrukcji include w SPF.
Typowe wartości w plikach SPF innych dostawców (tabela skrócona)
Dzięki tej tabeli nie trzeba już osobno szukać dokumentacji SPF dla każdej usługi. Dodaj ją do zakładek, aby mieć ją pod ręką, gdy dział marketingu zdecyduje się na wdrożenie nowego narzędzia.
| Usługi poczty elektronicznej | Wartość SPF | Uwagi |
|---|---|---|
| Google Workspace | obejmują:_spf.google.com | Obejmuje wszystkie wiadomości wysyłane w ramach Google Workspace |
| Microsoft 365 | w tym: spf.protection.outlook.com | Standard dla wszystkich dzierżawców M365 |
| Mailchimp | w tym: servers.mcsv.net | Standardowa wersja Mailchimp zawiera |
| SendGrid | w tym:sendgrid.net | Obejmuje wszystkie operacje wysyłania w SendGrid |
| Salesforce | obejmują:_spf.salesforce.com | Dotyczy wysyłania wiadomości e-mail w systemie Salesforce |
| Zendesk | obejmują:mail.zendesk.com | Adres e-mail działu pomocy technicznej Zendesk |
| Freshdesk | w tym: email.freshdesk.com | Adres e-mail działu pomocy technicznej Freshdesk |
| Amazon SES | w tym:amazonses.com | Obejmuje wysyłanie SES |
| Brevo | w tym: spf.brevo.com | Zaktualizowano z Sendinblue |
| Zoho Mail | w tym: zoho.com | Dotyczy Zoho Mail |
| Stempel pocztowy | zawiera: spf.mtasv.net | W przypadku wiadomości e-mailowych związanych z transakcjami Postmark |
| Klaviyo | w tym: spf.klaviyo.com | W ramach marketingu e-mailowego Klaviyo |
Tabela: Skrócony przegląd wartości SPF dla popularnych usług pocztowych. Zawsze należy sprawdzić aktualne wartości w oficjalnej dokumentacji danej usługi, ponieważ dostawcy od czasu do czasu je aktualizują.
Uwaga: Każde wkluczenie liczy się jako co najmniej jedno wyszukiwanie DNS, a wiele rekordów SPF stron trzecich zawiera zagnieżdżone wkluczenia, które zwiększają tę liczbę. Jeśli korzystasz z pięciu lub więcej usług, prawdopodobnie zbliżasz się do limitu 10 wyszukiwań. Zobacz następną sekcję, aby dowiedzieć się, jak sobie z tym poradzić.
Limit 10 wyszukiwań DNS i co zrobić, gdy go osiągniesz
Standard RFC 7208 ogranicza liczbę mechanizmów sprawdzania SPF do 10 zapytań DNS. Mechanizmy brane pod uwagę to: include, a, mx, redirect oraz exists. Mechanizmy, które NIE są brane pod uwagę, to: ip4, ip6 oraz all. Są one sprawdzane lokalnie, bez wysyłania zapytania DNS.
Gdy liczba sprawdzeń przekroczy 10, SPF zwraca błąd PermError. Wiele serwerów odbiorczych traktuje błąd PermError jako niepowodzenie weryfikacji SPF. Spada skuteczność dostarczania wiadomości e-mail, a użytkownik nie otrzymuje żadnego powiadomienia o tym fakcie.
Istnieje również mniej znane ograniczenie: limit dwóch nieudanych wyszukiwań. Jeśli podczas sprawdzania poprawności SPF więcej niż dwa zapytania DNS zwrócą wynik NXDOMAIN (domena nie znaleziona), weryfikacja SPF również zakończy się niepowodzeniem.
Oto trzy sposoby rozwiązania tego problemu, uszeregowane według praktyczności:
Opcja 1: Usunięcie nieużywanych mechanizmów
Zacznij od przeglądu. Usuń instrukcje `include:` dotyczące usług, z których już nie korzystasz. Usuń rekordy `A` i `MX`, jeśli nie wysyłasz wiadomości e-mail z adresów IP powiązanych z tymi rekordami w Twojej domenie. To najszybsze rozwiązanie, które często pozwala natychmiast zwolnić 2–3 operacje wyszukiwania.
Opcja 2: Ręczne spłaszczanie SPF
Zdefiniuj mechanizmy dołączania plików aż do poziomu adresów IP, na których działają, i wprowadź je jako stałe wpisy IPv4. Pozwoli to wyeliminować operacje sprawdzania DNS, które w przeciwnym razie byłyby wymagane przy dołączaniu tych plików.
Powoduje to ciągłe obciążenie związane z konserwacją. Dostawcy usług pocztowych zmieniają lub rozszerzają swoje zakresy adresów IP bez powiadamiania o tym użytkowników. Kiedy to robią, spłaszczony rekord staje się nieaktualny, a legalne wiadomości e-mail zaczynają się zawieszać. Ręczne spłaszczanie SPF przypomina koszenie trawnika. Działa, ale trzeba to powtarzać co kilka tygodni.
Opcja 3: Makra SPF lub automatyczne spłaszczanie
Współczesne podejście wykorzystuje makra SPF (zdefiniowane w RFC 7208 §7), które rozwijają się dynamicznie w momencie oceny, dzięki czemu wpis pozostaje poniżej limitu wyszukiwania bez konieczności ręcznej aktualizacji adresów IP.
Narzędzia do automatycznego ujednolicania adresów IP zajmują się tym na bieżąco, ponownie rozpoznając adresy IP dostawców zgodnie z harmonogramem i aktualizując opublikowany wpis.
| Osiągnąłeś limit 10 wyszukiwań?
PowerSPF wykorzystuje makra SPF, aby automatycznie utrzymywać Twój rekord na stałe poniżej limitu sprawdzania. Bez ręcznego spłaszczania, bez nieaktualnych adresów IP, bez konieczności konserwacji. PowerDMARC obsługuje również tradycyjne spłaszczanie SPF dla prostszych konfiguracji. Rozpocznij bezpłatny 15-dniowy okres próbny |
Sam współczynnik SPF to za mało: dlaczego DKIM i DMARC dopełniają obrazu
SPF porównuje adres IP nadawcy koperty (MAIL FROM) z Twoją listą autoryzowanych adresów. Działa to w przypadku, gdy wiadomość e-mail jest przesyłana bezpośrednio od nadawcy do odbiorcy, ale gdy wiadomość jest przekazywana dalej – za pośrednictwem list mailingowych, reguł automatycznego przekazywania, współdzielonych skrzynek pocztowych lub dowolnego serwera przekaźnikowego – adres IP nadawcy ulega zmianie. Wówczas mechanizm SPF przestaje działać, ponieważ adres IP serwera przekazującego nie figuruje w Twoim rekordzie SPF i nie powinien się tam znajdować.
DKIM (DomainKeys Identified Mail) działa inaczej. Dodaje on podpis kryptograficzny do treści wiadomości e-mail. Podpis ten pozostaje w wiadomości niezależnie od tego, przez który serwer jest ona przekazywana. DKIM zachowuje swoją ważność po przekazaniu wiadomości, a SPF nie.
Protokół DMARC (Domain-based Message Authentication, Reporting, and Conformity) łączy te elementy. Aby wiadomość przeszła kontrolę DMARC, wystarczy, by tylko JEDEN z protokołów – SPF lub DKIM – przeszedł pomyślnie i był zgodny z domeną nadawcy.
W praktyce DKIM jest bardziej niezawodnym mechanizmem weryfikacji, ponieważ nie ma na niego wpływu przekazywanie wiadomości.
Właśnie dlatego ważne jest, aby mieć jedno i drugie:
- Google wymaga stosowania protokołów SPF lub DKIM przez wszystkich nadawców, a także protokołu DMARC w przypadku nadawców masowych (ponad 5000 wiadomości dziennie). Od listopada 2025 r. wiadomości niezgodne z tymi wymogami będą trwale odrzucane.
- W maju 2025 roku firma Microsoft zaczęła odrzucać nieautoryzowane wiadomości e-mail wysyłane masowo.
- Yahoo stosuje te same wymagania w tych samych terminach co Google.
Jeśli SPF jest Twoim jedynym mechanizmem uwierzytelniania, Twoja domena nadal jest narażona na ryzyko podszywania się na każdym etapie przekazywania wiadomości e-mail i nie spełniasz w pełni wymagań dostawców skrzynek odbiorczych obowiązujących od 2026 roku.
Co dalej:
- Skonfiguruj DKIM dla każdej usługi, która wysyła wiadomości e-mail z Twojej domeny.
- Opublikuj rekord DMARC (zacznij od ustawienia p=none w celu monitorowania, a następnie przejdź do p=reject).
- Śledź zbiorcze raporty DMARC, aby sprawdzić, które źródła przechodzą lub nie przechodzą weryfikację SPF i DKIM.
| Chcesz poznać wszystkie szczegóły dotyczące uwierzytelniania wiadomości e-mail?
PowerDMARC monitoruje protokoły DMARC, SPF i DKIM we wszystkich Twoich domenach, udostępniając przejrzyste pulpity nawigacyjne, które pokazują, które wiadomości przechodzą pomyślnie, a które nie, oraz podają przyczyny tych wyników. |
Rekordy SPF dla domen, które nie wysyłają wiadomości e-mail
Jeśli posiadasz domeny, które są zaparkowane, nieaktywne lub służą wyłącznie do obsługi stron internetowych, nadal wymagają one ochrony SPF. Atakujący aktywnie podszywają się pod nieużywane domeny właśnie dlatego, że często pozostają one bez ochrony.
Rozwiązanie jest proste. Opublikuj następujący rekord SPF:
v=spf1 -all
Informuje to serwery odbiorcze, że nikt nie jest uprawniony do wysyłania wiadomości e-mail z tej domeny. Każda wiadomość rzekomo pochodząca z tej domeny powinna zostać odrzucona.
Aby zapewnić maksymalną ochronę, opublikuj również rekord DMARC z polityką odrzucania:
v=DMARC1; p=reject; rua=mailto:[email protected]
To połączenie skutecznie zapobiega spoofingowi w przypadku każdej domeny, którą posiadasz, niezależnie od tego, czy wysyła ona wiadomości e-mail, czy nie.
Typowe błędy związane z SPF i jak je naprawić
Błędy składniowe w SPF są bardzo powszechne, a najgorsze jest to, że nie powodują one żadnych widocznych komunikatów o błędzie. Oto osiem najczęstszych błędów, skutki ich popełnienia oraz sposoby ich naprawienia:
| Błąd | Co się dzieje | Jak to naprawić |
|---|---|---|
| Dwa rekordy SPF w jednej domenie | Błąd stały. Błąd weryfikacji SPF dla WSZYSTKICH wiadomości e-mail | Połącz oba rekordy w jeden rekord TXT |
| Brakuje v=spf1 na początku | Rekord jest całkowicie ignorowany | Upewnij się, że wpis zaczyna się dokładnie od v=spf1 |
| Mechanizmy umieszczone na końcu | Wszystko, co znajduje się po słowach „-all” lub „~all”, jest pomijane | Przenieś wszystko na sam koniec rekordu |
| Przekroczenie limitu 10 zapytań DNS | PermError. Błąd SPF nie powoduje wyświetlenia komunikatu | Usuń nieużywane pliki dołączane, spłaszcz strukturę lub skorzystaj z makr SPF |
| Użycie opcji +all | Umożliwia wszystkim użytkownikom Internetu wysyłanie wiadomości w imieniu Twojej domeny | Natychmiast zmień na -all lub ~all |
| Spacje lub literówki w adresach IP | Mechanizm jest nieprawidłowy, może spowodować błąd PermError | Sprawdź dokładnie wszystkie adresy IP; skorzystaj z narzędzia do generowania rekordów SPF |
| W tym przestarzały mechanizm ptr | W RFC 7208 odradza się stosowanie ptr; niektórzy odbiorcy ignorują tę opcję | Zastąp przez „ip4:” lub dodaj: |
| Nieaktualne adresy IP z wycofanych z eksploatacji serwerów | Może zostać przeniesiony. Potencjalne zagrożenie dla bezpieczeństwa | Co kwartał należy przeprowadzać audyt plików SPF; należy usuwać wycofane adresy IP |
Tabela: Najczęstsze błędy w rekordach SPF, ich skutki oraz sposoby ich naprawienia.
Aby dowiedzieć się więcej na temat rozwiązywania problemów związanych z błędami walidacji SPF, zapoznaj się z naszym przewodnikiem poświęconym tym błędom i sposobom ich usuwania.
Wniosek
Dodanie adresu IP do rekordu SPF to prosta operacja w systemie DNS, ale aby zrobić to poprawnie, trzeba zrozumieć składnię, wybrać między opcjami „ip4:” a „include:”, nie przekroczyć limitu 10 wyszukiwań DNS oraz sprawdzić poprawność wyniku po każdej zmianie.
SPF stanowi jeden z elementów kompleksowego systemu uwierzytelniania wiadomości e-mail. W 2026 roku, wraz z Google, Yahoo i Microsoft będą aktywnie egzekwować wymogi uwierzytelniania nadawców, sam SPF nie wystarczy. DKIM i DMARC są równie niezbędne do zapewnienia pełnej ochrony i zgodności z przepisami.
W miarę jak Twoja organizacja rozszerza zakres usług wysyłkowych, rekord SPF będzie się powiększał. Ręczne zarządzanie nie nadąża za tymi zmianami, a pojedynczy błąd może w sposób niezauważalny uniemożliwić dostarczanie wiadomości e-mail w całej domenie. Zautomatyzowane zarządzanie rekordami SPF nie jest już luksusem. To kwestia podstawowej higieny operacyjnej.
Nie musisz już ręcznie zarządzać rekordami SPF. PowerDMARC oferuje zautomatyzowane ujednolicanie SPF (PowerSPF), monitorowanie DMARC, zarządzanie DKIM oraz przejrzyste raporty dotyczące wszystkich Twoich domen – wszystko to na jednej platformie. Rozpocznij 15-dniowy bezpłatny okres próbny
Najczęściej zadawane pytania
1) Czy w tej samej domenie mogą znajdować się dwa rekordy SPF?
Nie. Specyfikacja RFC 7208 wymaga dokładnie jednego rekordu SPF typu TXT na domenę. Jeśli domena posiada dwa rekordy zaczynające się od „v=spf1”, serwery odbierające zwracają błąd PermError i traktują weryfikację SPF jako nieudaną dla każdej wiadomości. Jeśli chcesz autoryzować dodatkowe źródła, edytuj istniejący rekord, aby je dodać – nie twórz nowego.
2) Jaka jest różnica między -all a ~all?
-all to twardy błąd (hard fail) – nakazuje serwerom odbiorczym odrzucanie wiadomości e-mail pochodzących z nieautoryzowanych adresów IP. ~all to miękki błąd (soft fail) – oznacza nieautoryzowane wiadomości e-mail, ale nie nakazuje ich odrzucania. W praktyce, gdy polityka DMARC jest egzekwowana z ustawieniem p=quarantine lub p=reject, różnica jest minimalna, ponieważ polityka DMARC ma pierwszeństwo przed kwalifikatorem SPF. Jeśli polityka DMARC jest egzekwowana, oba ustawienia działają. Jeśli nie masz jeszcze wdrożonego DMARC, opcja -all zapewnia silniejszą ochronę.
3) Ile adresów IP można dodać do rekordu SPF?
Nie ma sztywnego limitu liczby mechanizmów typu „ip4:” lub „ip6:”. Nie są one wliczane do limitu 10 wyszukiwań DNS. Jednak całkowita długość rekordu SPF musi mieścić się w ograniczeniach dotyczących rozmiaru rekordu DNS TXT (255 znaków na ciąg, przy czym wiele ciągów połączonych razem może mieć długość do około 4096 znaków). W przypadku dużych list adresów IP należy używać notacji CIDR (np. ip4:192.0.2.0/24), aby efektywnie obejmować zakresy.
4) Po jakim czasie zaczynają działać filtry SPF?
Zależy to od wartości TTL (Time to Live) Twojego rekordu DNS. Jeśli wartość TTL wynosi 3600 (1 godzina), większość serwerów rozpoznających adresy wykryje zmianę w ciągu 1 godziny. Aby przyspieszyć ten proces: przed wprowadzeniem zmian zmniejsz wartość TTL do 300 (5 minut), poczekaj na upływ poprzedniego okresu TTL, a następnie wprowadź zmiany. Pozwoli to znacznie skrócić czas propagacji.
5) Jak sprawdzić, z jakich adresów IP wysyłane są obecnie wiadomości e-mail z mojej domeny?
Najbardziej niezawodną metodą jest raportowanie DMARC. Po opublikowaniu rekordu DMARC z tagiem „rua” serwery odbiorcze wysyłają codzienne zbiorcze raporty zawierające listę wszystkich adresów IP, które próbowały wysłać wiadomość e-mail z Twojej domeny, wraz z wynikami sprawdzania zgodności z SPF i DKIM. Bez DMARC pozostaje Ci tylko zgadywać. PowerDMARC przetwarza te raporty na przejrzyste, czytelne dla użytkownika pulpity nawigacyjne, dzięki czemu możesz dokładnie sprawdzić, kto wysyła wiadomości z Twojej domeny.
6) Czy mechanizmy IPv4 i IPv6 wliczają się do limitu 10 wyszukiwań DNS?
Nie. Do limitu wliczane są wyłącznie mechanizmy wymagające zapytania DNS: include, a, mx, redirect oraz exists. Mechanizmy ip4, ip6 oraz all są oceniane lokalnie i nie powodują żadnych zapytań DNS.


