Sprawdzanie rekordów SPF w Exchange: jak zweryfikować, opublikować i poprawić rekordy SPF w Exchange

W maju 2025 r. firma Microsoft zaczęła odrzucać wiadomości e-mail od nadawców wysyłających duże ilości wiadomości, którzy nie posiadali prawidłowych rekordów SPF, DKIM i DMARC. Jeśli Twoja domena wysyła ponad 5 000 wiadomości dziennie do serwisu Outlook.com lub Hotmail.com bez odpowiedniego uwierzytelnienia, wiadomości te nigdy nie trafią do skrzynki odbiorczej.

W lutym 2024 r. firmy Google i Yahoo wprowadziły podobne wymagania w lutym 2024 r. Według zespołu ds. bezpieczeństwa poczty elektronicznej Google ta wcześniejsza runda egzekwowania przepisów zmniejszyła liczbę nieautoryzowanych wiadomości otrzymywanych przez użytkowników Gmaila o około 75%.

Według raportu FBI IC3 dotyczącego przestępczości internetowej z 2023 r.. 

Problem w środowiskach Exchange polega na tym, że błędy SPF przebiegają bez żadnych sygnałów ostrzegawczych. Usługa Exchange Online nie powiadamia o uszkodzeniu rekordu. Nie ma wbudowanego panelu kontrolnego pokazującego wskaźniki poprawności. Większość zespołów dowiaduje się o tym dopiero po kilku tygodniach, gdy użytkownicy zgłaszają, że wiadomości e-mail są odrzucane, lub gdy dział marketingu informuje o gwałtownym spadku wskaźników otwarć.

W niniejszym przewodniku opisano cztery metody sprawdzania rekordu SPF w usłudze Exchange, sposób publikowania prawidłowego rekordu dla usług Exchange Online, lokalnych i hybrydowych, a także sposoby naprawiania najczęstszych błędów SPF (w tym limit 10 wyszukiwań, który uniemożliwia działanie SPF w większości średnich firm), jak Exchange Online faktycznie ocenia SPF „pod maską” oraz jak monitorować SPF na bieżąco, zamiast sprawdzać go raz i o tym zapomnieć.

Jak sprawdzić rekord SPF w usłudze Exchange (krok po kroku)

Istnieją cztery sprawdzone sposoby sprawdzenia rekord SPF, od najszybszego do najbardziej kompleksowego. Użyj metody 1 do szybkiej weryfikacji, a metody 4 do bieżącej widoczności operacyjnej.

Metoda 1: Skorzystaj z narzędzia do wyszukiwania adresów SPF (najszybsza metoda)

1. Otwórz dowolne narzędzie do sprawdzania SPF (np. narzędzie do sprawdzania SPF firmy PowerDMARC jest bezpłatny i nie wymaga rejestracji)
2. Wpisz swoją domenę (np. twojadomena.com, bez przedrostka http://) i 
3. Sprawdź wynik

Wynik wyszukiwania zawiera kilka wyników weryfikacji SPF. Oto, co oznaczają poszczególne pola wyników i na co należy zwrócić uwagę podczas ich przeglądania: 

Rekord może zostać poprawnie przetworzony, a liczba wyników wyszukiwania może wynosić sześć, ale nadal może brakować prawidłowego źródła wysyłki. Narzędzie do sprawdzania SPF weryfikuje zawartość serwera DNS, ale nie wie, które adresy IP powinny być autoryzowane.

Metoda 2: Sprawdź w Centrum administracyjnym Microsoft 365

Zaloguj się do Centrum administracyjnego Microsoft 365. Przejdź do sekcji Ustawienia → Domeny → wybierz swoją domenę → Rekordy DNS. W sekcji Microsoft Exchange sprawdź, czy status rekordu TXT to „OK”.

Jeśli status brzmi „Nieprawidłowy wpis”, oznacza to, że rekord SPF albo nie istnieje, albo nie zawiera wymaganego wpisu include:spf.protection.outlook.com. To najszybszy sposób na sprawdzenie poprawności rekordu SPF bez opuszczania portalu administracyjnego.

Metoda 3: Sprawdź za pomocą wiersza poleceń (nslookup / dig)

W przypadku rozwiązywania problemów po stronie serwera lub sytuacji, w których nie masz dostępu do przeglądarki, możesz sprawdzić rekord TXT SPF swojej domeny bezpośrednio z wiersza poleceń.

Wprowadź jedno z poniższych poleceń: 

# Windows

nslookup -type=txt twojadomena.com

# Linux 

/ macOSdig txt twojadomena.com +short

Wynik zwraca surowy rekord TXT. Poszukaj wiersza zaczynającego się od v=spf1. Jeśli widzisz dwa takie wiersze, oznacza to, że masz wiele rekordów SPF, co powoduje natychmiastowy błąd PermError. Napraw to, zanim zrobisz cokolwiek innego.

Metoda 4: Sprawdź za pomocą zbiorczych raportów DMARC (złoty standard)

Zestawione raporty od odbiorców, takich jak Gmail, Yahoo, Microsoft, Mail.ru czy regionalni dostawcy usług internetowych, pokazują wskaźniki pozytywnych i negatywnych wyników SPF dla wszystkich wiadomości e-mail wysłanych z Twojej domeny, a nie tylko dla jednej wiadomości testowej. To jedyny sposób na uzyskanie bieżącego, pełnego obrazu stanu SPF.

Jeśli publikujesz rekordy DMARC z tagiem `rua=`, to już zbierasz te raporty. Większość organizacji je posiada, ale tylko nieliczne je analizują, ponieważ surowy kod XML jest nieczytelny bez platformy umożliwiającej jego przetworzenie.

PowerDMARC codziennie pobiera te raporty i udostępnia dane analityczne dotyczące SPF na specjalnym pulpicie nawigacyjnym, zawierającym wskaźniki pozytywnych i negatywnych wyników dla poszczególnych źródeł wysyłki, śledzenie wyników wyszukiwania DNS oraz powiadomienia w przypadku pojawienia się nowego, nieautoryzowanego nadawcy.

Metoda 5: Weryfikacja na podstawie nagłówków wiadomości Exchange (weryfikacja w warunkach rzeczywistych)

Aby sprawdzić, w jaki sposób SPF jest oceniany przez rzeczywistego odbiorcę:

• Wyślij wiadomość testową ze swojej domeny na adres zewnętrzny (może to być osobiste konto Gmail).
• Otwórz wiadomość i pobierz pełne nagłówki. W programie Outlook: Plik → Właściwości → Nagłówki internetowe. W OWA lub Gmailu: Wyświetl źródło / Pokaż oryginał.
• Znajdź nagłówek „Authentication-Results” i odszukaj pole „spf=”.

Oto jak wygląda ten fragment kodu z dodanymi komentarzami:

Wyniki uwierzytelniania: 

spf=pass (adres IP nadawcy to 40.107.22.83)  

smtp.mailfrom=twojadomena.com;  

dkim=pass (podpis został zweryfikowany)  

header.d=twojadomena.com;  

dmarc=pass action=none  

header.from=twojadomena.com;  

compauth=hasło powód=100

Wynik „spf=pass” potwierdza, że adres IP nadawcy został autoryzowany przez Twój rekord SPF. Jeśli pojawi się komunikat „spf=fail”, „spf=softfail” lub „spf=permerror”, konkretny wynik wskaże, co jest nie tak:

• spf=fail: Adres IP nadawcy nie występuje w Twoim rekordzie SPF.
• spf=softfail: Adres IP nie jest autoryzowany, ale w Twoim rekordzie użyto ~all zamiast -all.
• spf=permerror: Twój rekord SPF zawiera błąd strukturalny (ponad 10 wyszukiwań, wiele rekordów, błąd składniowy).

Jak wygląda prawidłowy rekord SPF w systemie Exchange

Jak opublikować rekord SPF dla usługi Exchange Online (M365)

Opublikowanie rekordu SPF dla usługi Exchange Online jest proste. Jednak większość zespołów popełnia błędy właśnie na etapie wprowadzania danych.

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

Zanim zaczniesz wprowadzać zmiany w DNS, sprawdź wszystkie systemy, które wysyłają wiadomości e-mail w imieniu Twojej domeny. Większość organizacji zaniża liczbę takich systemów o 30–50%.

• Microsoft 365 / Exchange Online → dodaj:spf.protection.outlook.com
• Automatyzacja marketingu (HubSpot, Mailchimp, Marketo, Pardot) → każda z nich ma własny plik include
• CRM (Salesforce, Microsoft Dynamics) → zapoznaj się z dokumentacją dostawcy dotyczącą SPF
• E-maile transakcyjne (SendGrid, Amazon SES, Postmark, Mailgun) → pliki szablonów dostosowane do poszczególnych dostawców
• Pomoc techniczna / system zgłoszeń (Zendesk, Freshdesk, ServiceNow) → pliki dostosowujące do konkretnego dostawcy
• Kadry / płace (BambooHR, Gusto, Workday) → sprawdź, czy wysyłają powiadomienia z Twojej domeny
• Starsze serwery lokalne → IPv4: z adresami IP widocznymi publicznie

Najpewniejszym sposobem na wykrycie nadawców, o których wcześniej nie wiedziałeś, jest raporty zbiorcze DMARC. Pojawiają się tam wszystkie legalne (i nielegalne) źródła wysyłające wiadomości z Twojej domeny.

Krok 2: Utwórz rekord SPF

Zacznij od znacznika wersji, dodaj autoryzowane źródła, a na koniec umieść kwalifikator.

Podstawowy przykład M365:

v=spf1 

dodaj:spf.protection.outlook.com -all

Typowa firma z segmentu średnich przedsiębiorstw korzystająca z HubSpot i SendGrid:

v=spf1 

w tym: spf.protection.outlook.com 

obejmują:_spf.hubspot.com 

pokaż:sendgrid.net -wszystkie

Podczas tworzenia kodu należy liczyć liczbę wyszukiwań DNS. Każde użycie mechanizmów include:, a:, mx:, ptr: oraz exists: powoduje jedno wyszukiwanie. Mechanizmy ip4: i ip6: nie są brane pod uwagę. Zagnieżdżone instrukcje include: również się liczą, ponieważ sama instrukcja include:spf.protection.outlook.com generuje wewnętrznie 2–4 dodatkowe wyszukiwania, przechodząc przez infrastrukturę firmy Microsoft.

Krok 3: Opublikuj wpis w systemie DNS

Proces publikacji różni się nieco w zależności od dostawcy usług DNS, ale przebiega według tego samego schematu:

Ustawienia, których należy konsekwentnie używać:

• Typ rekordu: TXT
• Host / Nazwa: @ (lub puste pole, w zależności od dostawcy)
• TTL: 3600 (1 godzina) podczas testów, a po ustabilizowaniu się stanu – 86400 (24 godziny)

Ważne: Tylko jeden rekord SPF na domenę. Drugi rekord TXT typu v=spf1 to błąd PermError, który tylko czeka, by zostać wykryty. Jeśli proces konfiguracji Twojego dostawcy DNS automatycznie tworzy rekord podczas dodawania usługi, natychmiast sprawdź, czy nie ma duplikatów.

Krok 4: Sprawdź opublikowany wpis

• Poczekaj 5–60 minut na propagację DNS (w zależności od wartości TTL i dostawcy).
• Wykonaj ponownie wyszukiwanie SPF zgodnie z metodą 1, aby sprawdzić, czy rekord jest poprawnie rozpoznawany.
• Sprawdź Centrum administracyjne M365 (metoda 2). Status rekordu TXT powinien teraz wskazywać „OK”.
• Wyślij wiadomość testową na adres zewnętrzny i sprawdź, czy w nagłówkach znajduje się wpis „spf=pass”.
• Sprawdź, czy liczba wyszukiwań DNS nie przekracza 10.

Jeśli nie chcesz tworzyć rekordu ręcznie, skorzystaj z generator SPF PowerDMARC wygeneruje poprawnie sformatowany rekord po podaniu przez Ciebie źródeł wysyłania.

SPF dla hybrydowych środowisk Exchange: lokalne + chmura

W środowiskach hybrydowych Exchange konfiguracja SPF staje się znacznie bardziej złożona, ponieważ wiadomości e-mail mogą pochodzić jednocześnie zarówno z platformy Microsoft 365, jak i z infrastruktury lokalnej. Szczególnie podczas migracji ścieżki przepływu poczty często nakładają się na siebie w sposób powodujący niewidoczne błędy SPF, o ile nie uwzględni się prawidłowo każdej trasy wychodzącej.

Wyzwanie związane z rozwiązaniem hybrydowym: dwie ścieżki pocztowe, jeden rekord SPF

W środowisku hybrydowym poczta wychodząca może być wysyłana trzema różnymi drogami:

• Bezpośrednio w usłudze Exchange Online: dla skrzynek pocztowych hostowanych w usłudze M365
• Lokalne serwery Exchange lub Edge Transport: dla skrzynek pocztowych nadal znajdujących się w siedzibie firmy
• Inteligentne serwery lub serwery przekaźnikowe innych dostawców: gdy poczta jest kierowana na serwery zewnętrzne, zanim trafi do publicznej sieci internetowej

Każda ścieżka przekazuje serwerowi odbiorczemu inny adres IP źródłowy. System SPF nie bierze pod uwagę, która ścieżka była zamierzona, ponieważ sprawdza jedynie, czy adres IP, który faktycznie otrzymał, jest autoryzowany. Obie ścieżki muszą być uwzględnione w jednym rekordzie SPF, ponieważ dla każdej domeny dozwolony jest tylko jeden rekord SPF.

Jak skonfigurować SPF dla serwera Exchange Hybrid

Należy uwzględnić obie ścieżki autoryzacji:

v=spf1 include:spf.protection.outlook.com ip4:203.0.113.10 ip4:203.0.113.11 -all

Adresy IP w sieci lokalnej to adresy publiczne, z których korzysta serwer pocztowy podczas wysyłania wiadomości do Internetu, a nie wewnętrzne adresy zgodne ze standardem RFC 1918. Sprawdź łączniki wysyłające serwera Edge Transport oraz wszelkie reguły NAT lub zapory sieciowej, które określają adres IP publiczny. Jeśli korzystasz z redundancji geograficznej lub wielu ścieżek wychodzących, w rekordzie muszą znajdować się wszystkie adresy IP publiczne, z których mogą być wysyłane wiadomości.

SPF podczas migracji (stan przejściowy)

Migracja etapowa lub przełączająca powoduje, że przez pewien czas skrzynki pocztowe istnieją w obu lokalizacjach, a wiadomości mogą być wysyłane z obu ścieżek. Polityka SPF musi obejmować obie lokalizacje przez cały ten okres.

• Przed rozpoczęciem migracji: Upewnij się, że rekord SPF obejmuje zarówno lokalne wpisy ip4:, jak i zawiera: spf.protection.outlook.com.
• W trakcie migracji: Pozostaw oba upoważnienia bez zmian. Monitoruj wskaźniki zgodności SPF za pomocą zbiorczych raportów DMARC. Jeśli zmiany w routingu spowodują, że poczta będzie przechodzić przez nieoczekiwane ścieżki, raporty pokażą to, zanim zauważą to użytkownicy.
• Po zakończeniu migracji: Usuń lokalne wpisy ip4:. Pozostawienie nieaktualnych adresów IP w rekordzie SPF stanowi zagrożenie dla bezpieczeństwa. Jeśli te stare adresy IP zostaną ponownie przypisane przez dostawcę usług internetowych lub dostawcę usług w chmurze, nowy użytkownik będzie mógł wysyłać uwierzytelnioną pocztę jako Twoja domena.

Częstym błędem jest usuwanie lokalnych adresów IP w trakcie migracji pod pretekstem, że przełączenie jest „prawie zakończone”. Wystarczy, że choć jedna skrzynka pocztowa nadal będzie kierowana starą ścieżką, aby uniemożliwić uwierzytelnianie poczty tego użytkownika.

Poddomeny w Exchange: reguły SPF nie są dziedziczone

Istotna kwestia, która sprawia trudności wielu organizacjom o strukturze hybrydowej: subdomeny nie dziedziczą rekordu SPF domeny nadrzędnej. Jeśli domena marketing.twojadomena.com wysyła wiadomości e-mail za pośrednictwem odrębnego dostawcy usług e-mailowych (ESP), musi posiadać własny rekord TXT typu SPF. Protokół nie obsługuje rekordów SPF z symbolami wieloznacznymi. Każda subdomena wysyłająca pocztę musi mieć opublikowany we własnym katalogu głównym DNS własny rekord typu v=spf1.

Oznacza to również, że korzystanie z subdomen stanowi skuteczną strategię rozłożenia obciążenia SPF. Należy kierować wiadomości marketingowe przez domenę marketing.twojadomena.com, a wiadomości transakcyjne przez domenę mail.twojadomena.com, tak aby każda subdomena otrzymała własny limit 10 zapytań. Rozwiązanie to jest zgodne z RFC, dobrze obsługiwane przez dostawców usług e-mailowych (ESP) i powszechnie stosowane w środowiskach korporacyjnych.

Czy usługa Exchange Online sprawdza rekordy SPF w przypadku wiadomości wysyłanych wewnątrz tej samej dzierżawy?

Nie. Usługa Exchange Online traktuje wiadomości wysyłane w obrębie tego samego dzierżawcy jako pocztę wewnętrzną i nie przeprowadza weryfikacji SPF. Wiadomości przesyłane między różnymi dzierżawcami, nawet w przypadku zaufanych organizacji partnerskich, podlegają kontroli SPF, ponieważ poczta ta przechodzi przez publiczną ścieżkę routingu poczty.

W przypadku organizacji posiadających wiele domen w ramach jednego dzierżawcy usługi M365 każda domena musi mieć własny rekord SPF. Współdzielenie jednego rekordu między domenami za pomocą CNAME nie jest standardową praktyką i nie działa niezawodnie.

Typowe błędy związane z polityką SPF w usłudze Exchange i sposoby ich usuwania

Każdy z poniższych scenariuszy rozwiązywania problemów ma tę samą strukturę diagnostyczną: Objaw → Przyczyna → Rozwiązanie.

Błąd stały: Zbyt wiele operacji wyszukiwania DNS

• • Objaw: SPF zwraca błąd PermError. Odbiorcy mogą oznaczyć Twoją wiadomość jako spam lub ją odrzucić. Nie udaje się uzyskać zgodności z DMARC.
  • Przyczyna: Ponad 10 wyszukiwań DNS w rekordzie SPF, wliczając zagnieżdżone włączenia. Jest to najczęstsza przyczyna niepowodzeń SPF w organizacjach korzystających z wielu usług SaaS.

• Rozwiązanie (5-etapowa procedura):

• • Krok 1: Sprawdź aktualną liczbę odwołań za pomocą narzędzia do sprawdzania SPF, które rekurencyjnie zlicza zagnieżdżone pliki include.
  • Krok 2: Usuń nieaktualne pliki include dla usług, których już nie używasz.
  • Krok 3: Zastąp mechanizmy typu „include:” mechanizmami typu „ip4:” w przypadkach, gdy adresy IP dostawcy są stabilne i udokumentowane.
  • Krok 4: Przenieś nadawców wysyłających duże ilości wiadomości, którzy nie są firmami (marketing, wiadomości transakcyjne), do subdomen z własnymi rekordami SPF.
  • Krok 5: Jeśli nadal masz ponad 10, wdroż spłaszczanie SPF lub makra przy użyciu narzędzia takiego jak PowerSPF, aby automatycznie przekształcać include w wpisy IPv4 i aktualizować rekord, gdy dostawcy zmieniają adresy IP.

Przykład przed i po:

Wcześniej (14 wyszukiwań: PermError):

v=spf1 include:spf.protection.outlook.com include:_spf.hubspot.com include:sendgrid.net include:servers.mcsv.net include:_spf.salesforce.com include:zendesk.com include:spf.freshdesk.com a mx -all

Po (7 wyszukiwań: poniżej limitu):

v=spf1 include:spf.protection.outlook.com include:_spf.hubspot.com include:sendgrid.net ip4:198.2.128.0/24 ip4:192.254.113.0/24 -all# Salesforce i Zendesk przeniesiono do mail.twojadomena.com# Freshdesk zastąpiono spłaszczonymi wpisami ip4# usunięto mechanizmy a i mx (nadmiarowe przy jawnych include)

Znaleziono wiele rekordów SPF

• Objaw: Narzędzie do sprawdzania SPF zwraca błąd „wiele rekordów SPF”. Wszystkie operacje sprawdzania SPF kończą się niepowodzeniem.
• Przyczyna: Dla tej samej domeny istnieją co najmniej dwa rekordy TXT zaczynające się od v=spf1. Zjawisko to występuje najczęściej wtedy, gdy w trakcie procesu konfiguracji dostawca usług SaaS tworzy drugi rekord bez wiedzy administratora.
• Poprawka: Połącz w jeden rekord. W jednym rekordzie może znajdować się wiele mechanizmów include: i ip4:, ale tylko jeden rekord TXT v=spf1 na domenę. Usuń zbędny wpis.

SPF przestaje działać po dodaniu nowego narzędzia SaaS

• Objaw: Wiadomości e-mail wysyłane przez nowo dodane narzędzie nie przechodzą testu SPF. Inni nadawcy również mogą napotkać problemy, jeśli nowe dołączenie spowoduje, że łączna liczba wyszukiwań przekroczy 10.
• Przyczyna: Nowa usługa nie została dodana do SPF lub jej dodanie przekroczyło limit wyszukiwań.
• Rozwiązanie: Dodaj plik do włączenia, a następnie ponownie sprawdź łączną liczbę odwołań. Jeśli liczba ta przekracza teraz 10, problemem jest liczba odwołań, a nie sam plik do włączenia. Zastosuj powyższy 5-etapowy proces.

Błąd SPF w serwerze Hybrid Exchange (brak adresu IP lokalnego)

• Objaw: Wiadomości e-mail wysyłane z lokalnego serwera Exchange nie przechodzą testu SPF, podczas gdy wiadomości pochodzące z M365 przechodzą ten test.
• Przyczyna: Publiczny adres IP serwera lokalnego nie znajduje się w rekordzie SPF. Jest to szczególnie częste po częściowej migracji, w której administrator zaktualizował rekord SPF dla Exchange Online, ale zapomniał, że poczta nadal jest kierowana przez lokalną ścieżkę.
• Rozwiązanie: Dodaj adres ip4:x.x.x.x dla każdego lokalnego adresu IP wychodzącego. Jeśli poczta jest kierowana przez serwer Edge Transport, host inteligentny lub serwer przekaźnikowy innej firmy, należy również uwzględnić publiczny adres IP tego serwera przekaźnikowego.

Błąd SPF po migracji do Exchange Online

• Objaw: Wiadomości e-mail wysłane po migracji nie przechodzą testu SPF.
• Przyczyna: DNS nadal wskazuje stare lokalne adresy IP, w tym: nie dodano include:spf.protection.outlook.com lub poczta jest kierowana przez nieoczekiwane ścieżki podczas przejścia.
• Rozwiązanie: Sprawdź, czy rekord SPF zawiera zarówno stare (lokalne), jak i nowe (Exchange Online) ścieżki autoryzacji w trakcie migracji. Usuń stare wpisy dopiero po potwierdzeniu, że 100% skrzynek pocztowych zostało przeniesionych. Przez cały czas monitoruj sytuację za pomocą zbiorczych raportów DMARC. Pokazują one dokładnie, jakimi ścieżkami przechodzi Twoja poczta z perspektywy odbiorców.

Wiadomość z linkiem została dostarczona, ale trafiła do folderu spam

• Objaw: Nagłówki pokazują spf=pass, ale wiadomość trafia do folderu ze spamem odbiorcy.
• Przyczyna: SPF to tylko jeden z wielu sygnałów. Reputacja nadawcy, treść, DKIM lub DMARC mogą nie spełniać wymagań. Każdy z tych czynników może unieważnić pozytywny wynik SPF.
• Rozwiązanie: Sprawdź zgodność DKIM, politykę DMARC, reputację nadawcy (status na czarnej liście, wiek domeny, ostatnie zmiany w natężeniu ruchu) oraz reputację treści/linków. Narzędzie Domain Analyzer firmy PowerDMARC zwraca ocenę wszystkich tych elementów w ramach jednego skanowania.

SPF nie działa w przypadku wiadomości e-mail przekazanych dalej

• Objaw: Wiadomości przekazywane automatycznie, wiadomości z list mailingowych lub wiadomości kierowane przez reguły transportowe nie przechodzą testu SPF.
• Przyczyna: Adres IP serwera przekazującego nie znajduje się w rekordzie SPF pierwotnego nadawcy. Jest to ograniczenie architektury SPF, a nie błąd konfiguracji.
• Rozwiązanie: Traktuj niepowodzenie SPF w przypadku przekazywanej poczty jako oczekiwane zachowanie. Upewnij się, że DKIM jest poprawnie skonfigurowany dla Twojej domeny. Podpisy DKIM pozostają nienaruszone podczas przekazywania, co pozwala DMARC przejść przez weryfikację zgodności DKIM nawet w przypadku niepowodzenia SPF. ARC (Authenticated Received Chain) w Exchange Online dodatkowo zachowuje wyniki uwierzytelniania w zaufanych łańcuchach przekazywania.

Jak usługa Exchange Online faktycznie przetwarza wyniki SPF (wyjaśnienie działania „czarnej skrzynki”)

Większość administratorów platformy Exchange boryka się z tym samym problemem: w jaki sposób usługa Exchange Online Protection (EOP) faktycznie traktuje błędy SPF? Niektóre źródła podają, że błąd typu „hard fail” oznacza automatyczne odrzucenie wiadomości. Inne sugerują, że SPF jest jedynie drugorzędnym wskaźnikiem spamu. Oto, jak to faktycznie działa.

Potok wielosygnałowy (SPF to tylko jedno wejście)

Usługa Exchange Online Protection nie podejmuje decyzji dotyczących dostarczania wiadomości wyłącznie na podstawie danych SPF. Dane SPF stanowią jeden z elementów złożonej oceny uwierzytelniania, która obejmuje:

• Wynik SPF: pozytywny, negatywny, częściowo negatywny, neutralny, PermError lub TempError
• Wynik DKIM: pozytywny, negatywny lub brak
• Wynik DMARC: uzyskany na podstawie porównania SPF lub DKIM z domeną z nagłówka „From”
• Reputacja nadawcy: reputacja adresu IP, reputacja domeny, historyczne wzorce wysyłania
• Ocena poziomu pewności spamu (SCL): wewnętrzna skala firmy Microsoft od -1 (bezpieczny nadawca) do 9 (spam o wysokim poziomie pewności)
• Filtrowanie treści: słowa kluczowe, reputacja adresów URL, analiza załączników

EOP wykorzystuje łączny wynik uwierzytelniania, a nie wynik pojedynczego protokołu, do ustalenia ostatecznego sposobu postępowania z wiadomością.

Jak EOP radzi sobie z poszczególnymi wynikami SPF

PermError to poważna awaria, którą EOP traktuje niemal identycznie jak całkowitą porażkę SPF, co powoduje kaskadowy efekt w DMARC, całkowicie uniemożliwiając uwierzytelnienie. Dlatego właśnie limit 10 wyszukiwań stanowi strukturalny punkt awarii.

Gdzie sprawdzić wyniki SPF w platformie Exchange

Trzy miejsca, w kolejności rosnącej pod względem kompletności:

• Nagłówki wiadomości (Authentication-Results): Każda wiadomość przetwarzana przez EOP jest opatrzona oznaczeniem spf=pass/fail/softfail/permerror/temperror wraz z oceną domeny nadawczej i adresu IP.
• Śledzenie wiadomości w Exchange: Pokazuje status dostarczenia, źródłowy adres IP, odbiorcę i ostateczny wynik, ale nie wyświetla w widoczny sposób oceny SPF. Jeśli polegasz wyłącznie na śledzeniu wiadomości w celu uzyskania wglądu w SPF, działasz na ślepo.
• Zestawienia raportów DMARC (RUA): Jedyne źródło danych, które pokazuje, jak odbiorcy na całym świecie oceniają Twój SPF. Raporty RUA przedstawiają wskaźniki pozytywnych i negatywnych wyników SPF dla poszczególnych adresów IP i źródeł na każdym serwerze odbiorczym, który przetwarza Twoją pocztę.

Konfigurowanie wymuszania twardego błędu SPF w usłudze EOP

Domyślnie usługa Exchange Online uwzględnia wyniki SPF w swojej ocenie złożonej, ale nie odrzuca wiadomości wyłącznie na podstawie SPF. Aby wyraźnie skonfigurować usługę EOP tak, by oznaczała wiadomości z poważnym błędem SPF jako spam:

W centrum administracyjnym Exchange Online: przejdź do sekcji „Ochrona” → „Filtr antyspamowy” → „Opcje zaawansowane” i ustaw przełącznik „Rekord SPF: twardy błąd” w pozycji „Włączone”. Można też uruchomić następujący polecenie cmdlet w PowerShell:

Get-HostedContentFilterPolicy | Where-Object {$_.IsDefault -eq $true} | Set-HostedContentFilterPolicy -MarkAsSpamSpfRecordHardFail On

Najlepsze praktyki dotyczące SPF w środowiskach Exchange w 2026 roku

• Jako domyślny kwalifikator należy używać opcji -all (twardy błąd). W połączeniu z DMARC opcja -all stanowi standard. Jedynym wyjątkiem jest początkowy okres wdrażania, zanim system DMARC zostanie w pełni uruchomiony.
• Nigdy nie używaj opcji +all. Umożliwia ona wszystkim użytkownikom w sieci wysyłanie wiadomości z Twojej domeny. Jeśli zauważysz opcję +all w swoim wpisie, potraktuj to jako aktywny incydent bezpieczeństwa.
• W przypadku usługi M365 należy zawsze uwzględniać adres spf.protection.outlook.com, nawet jeśli poczta wychodząca jest kierowana przez bramę innej firmy. Usługa Exchange Online generuje zaproszenia do kalendarza, automatyczne odpowiedzi, powiadomienia o niedostarczeniu wiadomości (NDR) oraz potwierdzenia odczytu, które są wysyłane bezpośrednio z infrastruktury firmy Microsoft.
• Sprawdzaj swój rekord SPF co najmniej raz na kwartał. Dostawcy usług SaaS zmieniają zakresy adresów IP. Dział marketingu wdraża nowe narzędzia bez informowania działu IT. Kwartalne kontrole pozwalają wykryć odchylenia, zanim spowodują one błąd PermError. Ciągłe monitorowanie za pomocą raportów DMARC pozwala wykrywać odchylenia w czasie rzeczywistym.
• Wprowadź SPF wraz z DKIM i DMARC. Sam SPF nie zapobiega fałszowaniu pola „From” w nagłówku. Sam DKIM nie weryfikuje nadawcy koperty. Tylko egzekwowanie DMARC, sprawdzające zgodność SPF lub DKIM z domeną w polu „From” nagłówka, zapewnia kompleksową ochronę.
• Należy spełnić wymagania dotyczące nadawców stawiane przez wszystkich głównych odbiorców. W 2026 r. firmy Google, Yahoo, Microsoft i Apple będą wymagały od nadawców masowych wiadomości stosowania protokołów SPF, DKIM i DMARC. Standard PCI DSS w wersji 4.0, obowiązkowy od marca 2025 r., wyraźnie wymaga stosowania wszystkich trzech protokołów jako środków zabezpieczających przed phishingiem.

Jak stale monitorować współczynnik SPF 

Największą różnicą między organizacjami, które „wdrożyły SPF”, a tymi, które faktycznie są chronione przez ten mechanizm, jest monitorowanie. Jednorazowa konfiguracja to łatwa część zadania, ale to właśnie wykrywanie ukrytych awarii w kolejnych miesiącach odróżnia skuteczne uwierzytelnianie poczty elektronicznej od teoretycznego.

Dlaczego jednorazowe sprawdzanie współczynnika SPF stwarza fałszywe poczucie bezpieczeństwa

Zapisy SPF ulegają ciągłym zmianom, ponieważ dostawcy modyfikują swoje autoryzowane zakresy adresów IP, a łańcuchy „include” odwołują się do różnych adresów IP, z których jeden może spowodować przekroczenie limitu zapytań. Zespoły wdrażają nowe narzędzia SaaS bez aktualizacji SPF. Migracje zmieniają trasy poczty wychodzącej w sposób, którego system DNS nie odzwierciedla. Pozostają stare wpisy dotyczące usług, z których organizacja przestała korzystać już wiele lat temu.

Jak wygląda ciągłe monitorowanie SPF

Cztery elementy, z których każdy dotyczy konkretnego rodzaju awarii:

• Codziennie gromadzone są zbiorcze raporty DMARC od odbiorców z całego świata. Zawierają one wyniki SPF w podziale na adresy IP i źródła dla każdego serwera odbiorczego, który przetworzył Twoją pocztę. PowerDMARC automatycznie pobiera te dane i wyświetla je na dedykowanym panelu analitycznym SPF, gdzie dostępne są wskaźniki pozytywnych i negatywnych wyników w podziale na źródła, statystyki liczby wyszukiwań DNS oraz wykresy trendów historycznych.
• Automatyczne powiadomienia w momencie przekroczenia progu błędów SPF, pojawienia się nowego, nieautoryzowanego źródła wysyłki lub gdy zmiana w DNS wpływa na Twój rekord. PowerAlerts firmy PowerDMARC przekazuje je za pośrednictwem poczty e-mail, Slacka lub Discorda, dzięki czemu odpowiedni zespół widzi problem w godzinach pracy.
• Automatyczne spłaszczanie SPF , które aktualizuje się, gdy zewnętrzni dostawcy zmieniają adresy IP. Rozwiązania oferowane przez PowerSPF rozwiązuje łańcuchy include: w wpisy ip4: i utrzymuje Twój rekord na stałe poniżej 10 wyszukiwań bez konieczności ręcznej edycji DNS.
• Monitorowanie czarnych list i reputacji. Jeśli Twoje adresy IP wysyłające trafią na listę blokowanych, SPF może przejść pomyślnie, ale dostarczalność nadal będzie się pogarszać. Zintegrowane monitorowanie reputacji wykrywa awarie, których sam SPF nie dostrzega.

Specjalnie dla dostawców usług zarządzanych (MSP): gdy dostawca klienta zmienia swój zakres adresów IP, dowiadujecie się o tym, zanim przestaną działać wiadomości e-mail klienta. 

Panel MSP firmy PowerDMARC umożliwia scentralizowane monitorowanie SPF we wszystkich domenach klientów z poziomu jednego ekranu, z możliwością szczegółowego przeglądu danych dla poszczególnych klientów. Dzięki temu zarządzanie SPF przestaje być jedynie reaktywnym gaszeniem pożarów, a staje się profesjonalną linią usług.

Rozpocznij 15-dniowy bezpłatny okres próbny i przekonaj się sam. 

Najczęściej zadawane pytania

Jak sprawdzić rekordy SPF w usłudze Exchange Online?

Skorzystaj z narzędzia do sprawdzania rekordów SPF, takiego jak PowerDMARC SPF Checker, wprowadź swoją domenę i sprawdź rekord, składnię oraz liczbę wyszukiwań. Możesz to również zweryfikować w centrum administracyjnym Microsoft 365 w sekcji Ustawienia → Domeny → Rekordy DNS. Aby sprawdzić poprawność po stronie odbiorcy, sprawdź nagłówek Authentication-Results w wiadomości testowej wysłanej na adres zewnętrzny.

Jakiego rekordu SPF potrzebuję do korzystania z usługi Microsoft 365?

Co najmniej: v=spf1 include:spf.protection.outlook.com -all. Jeśli korzystasz z dodatkowych usług wysyłania wiadomości (HubSpot, SendGrid, Salesforce, Zendesk), dodaj ich wpisy przed -all. Upewnij się, że łączna liczba wyszukiwań DNS nie przekracza 10, wliczając w to wyszukiwania zagnieżdżone w każdym wpisie include:.

Dlaczego usługa SPF nie działa, mimo że mój wpis wygląda na poprawny?

Najczęstsze przyczyny: przekroczenie limitu 10 wyszukiwań DNS (PermError), obecność wielu rekordów SPF w tej samej domenie, przekierowane wiadomości e-mail (zgodnie z założeniami protokół SPF przestaje działać w przypadku przekierowania) lub zmiana autoryzowanych zakresów adresów IP przez dostawcę bez powiadomienia. Sprawdź nagłówek „Authentication-Results”, aby poznać konkretny wynik spf=.

Jaka jest różnica między -all a ~all?

-all (twardy błąd) nakazuje odbiorcom odrzucanie lub oznaczanie jako błędne wiadomości pochodzących z nieautoryzowanych adresów IP. ~all (miękki błąd) jest bardziej liberalne. W 2026 roku, po wdrożeniu DMARC, polityka DMARC będzie regulować egzekwowanie zasad niezależnie od użytego kwalifikatora. Jeśli nie korzystasz jeszcze z DMARC, opcja -all zapewnia znacznie silniejszą ochronę.

Ile zapytań DNS generuje adres include:spf.protection.outlook.com?

Włączenie z serwerów Microsoftu liczy się jako jedno wyszukiwanie, ale powoduje łańcuch zagnieżdżonych włączeń, które wymagają około 2–4 dodatkowych wyszukiwań. Dokładna liczba zmienia się wraz z aktualizacjami infrastruktury Microsoftu. Zawsze należy to zweryfikować za pomocą narzędzia sprawdzającego, które rekurencyjnie zlicza zagnieżdżone wyszukiwania.

Czy SPF wystarczy, by zapobiec fałszowaniu adresów e-mail?

Nie. Sam protokół SPF nie zapobiega sfałszowaniu widocznego adresu nadawcy (nagłówek „From”). Służy on jedynie do weryfikacji nadawcy koperty (Return-Path). Kompleksowa ochrona wymaga protokołu DKIM do podpisywania wiadomości oraz protokołu DMARC do egzekwowania zgodności. Współpraca wszystkich trzech protokołów oraz ich ciągłe monitorowanie to standard w 2026 roku.