SPF Softfail vs SPF Hardfail: Jaka jest różnica?

Poznaj różnicę między SPF Softfail i Hardfail, najlepsze praktyki oraz sposoby zabezpieczenia firmowej poczty elektronicznej za pomocą PowerDMARC. Kompletny przewodnik dla menedżerów IT i administratorów poczty elektronicznej.

Z SPF (Sender Policy Framework) można elastycznie skonfigurować system tak, aby reagował na błędy uwierzytelniania na dwa sposoby: Hardfail lub Softfail. W tym blogu eksperci PowerDMARC omówią różnice między hardfail i softfail w SPF, sposoby konfiguracji każdego z nich oraz rzeczywiste przypadki użycia dla zespołów IT i bezpieczeństwa. Zacznijmy więc!

Co to jest awaria SPF?

Zanim przejdziemy do omówienia różnic między twardą a miękką awarią, należy zrozumieć, co stanowi awarię SPF i jak działa uwierzytelnianie SPF.

SPF (Sender Policy Framework) to protokół uwierzytelniania wiadomości e-mail, który umożliwia właścicielom domen określenie, które adresy IP są uprawnione do wysyłania wiadomości e-mail w imieniu ich domeny. Po otrzymaniu wiadomości e-mail serwer odbiorczy sprawdza adres IP nadawcy w rekordzie SPF domeny, aby ustalić, czy nadawca jest uprawniony.

Sprawdzenie SPF jest wykonywane względem domeny ścieżki zwrotnej, która reprezentuje daną tożsamość podlegającą uwierzytelnieniu. Bardzo ważne jest, aby rekord SPF był opublikowany poprawnie, aby zapewnić prawidłowe uwierzytelnianie SPF i uniknąć problemów z dostarczaniem wiadomości e-mail.

Wyniki uwierzytelniania SPF

• Pass: Adres IP nadawcy jest autoryzowany w rekordzie SPF.
• Niepowodzenie (Hard Fail): Adres IP nadawcy jest wyraźnie nieautoryzowany (-all)
• Błąd miękki: adres IP nadawcy prawdopodobnie nie jest autoryzowany (~wszystkie)
• Neutralny: Brak oświadczenia dotyczącego nadawcy (?wszyscy)
• Brak: Nie istnieje żaden rekord SPF dla tej domeny.
• TempError: Tymczasowa awaria wyszukiwania DNS
• PermError: Stały błąd w składni rekordu SPF

Każdy wynik SPF stanowi jednoznaczne stwierdzenie dotyczące statusu autoryzacji nadawcy. Wynik „fail” jest jednoznacznym stwierdzeniem, że nadawca nie jest autoryzowany, natomiast wynik „softfail” jest słabym stwierdzeniem wskazującym na prawdopodobny, ale nie ostateczny brak autoryzacji.

Błąd SPF występuje, gdy kontrola uwierzytelniająca zwraca wynik „Fail” lub „Soft Fail”, co oznacza, że serwer wysyłający może nie być uprawniony do wysyłania wiadomości e-mail dla tej domeny.

SPF Hard Fail a Soft Fail: wyjaśnienie kluczowych różnic

Poniższa tabela wyjaśnia podstawową różnicę między SPF hardfail i softfail.

Uwaga: Mechanizm hardfail („-all”) został zaprojektowany w celu zapewnienia maksymalnej ochrony przed phishingiem i fałszywymi wiadomościami e-mail poprzez odrzucanie wiadomości od nieautoryzowanych nadawców. Jednak nieprawidłowa konfiguracja może spowodować, że wiadomości e-mail nie będą dostarczane, a wskaźnik odrzuceń dla nieautoryzowanych źródeł wyniesie 100%.

W składni rekordu SPF tylko adres lub adresy IP określone w rekordzie SPF są uprawnione do wysyłania wiadomości e-mail w imieniu domeny. Wszystkie inne źródła są traktowane jako nieautoryzowani nadawcy i mogą zostać zablokowane lub oznaczone jako podejrzane, w zależności od typu błędu.

SPF Hardfail kontra Softfail: zgodnie z definicją zawartą w RFC 

Zgodnie z RFC 7208:

• Wynik "Fail" dla SPF bezpośrednio wskazuje, że nadawca wiadomości e-mail nie jest autoryzowany przez domenę wysyłającą. "Fail" jest synonimem wyniku Hardfail (-all), który wyraźnie wskazuje na nieautoryzowane użycie domeny. 
• Jednak znacznie bardziej elastycznym podejściem jest konfiguracja SPF Softfail, które wskazuje na „prawdopodobne” użycie domeny bez upoważnienia.

Obsługa awarii odbiorcy w przypadku awarii Hardfail i Softfail 

W sekcji 8.4RFC definiuje następujące scenariusze obsługi wyników dla wyników SPF hardfail i SPF softfail: 

1. SPF Hardfail / Fail 

W przypadku wyniku "Fail" lub "Hardfail" serwer odbiorcy może odrzucić wiadomość e-mail, która jest nieautoryzowana. Jeśli jest to transakcja SMTP, powinien zostać zwrócony kod błędu 550 5.7.1 z odpowiednim opisem błędu. 

JEŚLI serwer odbiorcy nie odrzuci wiadomości e-mail podczas transakcji SMTP, RFC zaleca odbiorcom rejestrowanie wyników SPF w nagłówku Received-SPF lub Authentication-Results. 

2. SPF Softfail

Jako bardziej elastyczna polityka, Softfail wskazuje, że domena zarządzania administracyjnego podejrzewa, że wiadomość e-mail jest nieautoryzowana, ale nie chce jej od razu odrzucać. W takim przypadku wiadomość jest dostarczana, ale z ostrzeżeniem do dalszej weryfikacji.  

Który tryb awarii SPF należy zastosować?

Większość domen, w tym domeny dużych organizacji i firm technologicznych, stosuje kombinację zasad SPF w zależności od konkretnych potrzeb i praktyk dotyczących poczty elektronicznej. Wybór między twardym a miękkim błędem SPF zależy od infrastruktury poczty elektronicznej organizacji, wymagań bezpieczeństwa i tolerancji ryzyka. Oto schemat decyzyjny, który pomoże Ci dokonać wyboru:

Wybierz opcję SPF Hard Fail (-all) w następujących przypadkach:

• Masz pełną kontrolę nad wszystkimi źródłami wysyłania wiadomości e-mail.
• Twoja infrastruktura poczty elektronicznej jest dojrzała i dobrze udokumentowana.
• Bezpieczeństwo jest ważniejsze niż dostarczalność
• Rzadko korzystasz z usług poczty elektronicznej innych firm.
• Masz wdrożony kompleksowy system monitorowania DMARC.

Wybierz SPF Soft Fail (~all) Kiedy:

• Wdrażasz SPF po raz pierwszy
• Korzystasz z wielu usług poczty elektronicznej innych firm.
• Dostarczalność wiadomości e-mail ma kluczowe znaczenie dla działalności biznesowej.
• Masz złożone ustawienia przekazywania lub retransmisji wiadomości e-mail.
• Nadal identyfikujesz wszystkie legalne źródła wiadomości e-mail.

Typowe przypadki użycia funkcji SPF Hard Fail i Soft Fail

Przypadki użycia funkcji SPF Hard Fail:

• Instytucje finansowe: Banki i spółdzielcze kasy oszczędnościowo-kredytowe wymagające ścisłej weryfikacji tożsamości w wiadomościach e-mail
• Agencje rządowe: Organizacje o wysokich wymaganiach bezpieczeństwa
• Domeny służące ochronie marki: Domeny używane wyłącznie do ochrony marki
• Domeny e-mailowe do transakcji: Dedykowane domeny dla automatycznych wiadomości e-mail

Przykłady zastosowań funkcji SPF Soft Fail:

• Domeny marketingowe: Domeny korzystające z wielu platform marketingu e-mailowego
• Firmy SaaS: Organizacje posiadające złożoną infrastrukturę poczty elektronicznej
• Instytucje edukacyjne: Uniwersytety z wieloma wydziałami i systemami poczty elektronicznej
• Środowiska testowe: Domeny w fazie wdrażania SPF

Sytuacja z życia wzięta: Jeśli jesteś menedżerem IT odpowiedzialnym za bezpieczeństwo poczty elektronicznej w średniej wielkości firmie SaaS korzystającej z Google Workspace, Salesforce i Mailchimp, możesz zacząć od miękkiej porażki, aby zapewnić dostarczanie wszystkich legalnych wiadomości e-mail, jednocześnie monitorując i udoskonalając swój rekord SPF.

Kiedy należy stosować twardą lub miękką porażkę SPF?

W przypadku przekazywania wiadomości e-mail SMTP, można rozważyć SPF softfail jako bezpieczniejszy zakład przeciwko hardfail. Dowiedzmy się jak to zrobić: 

Przekazywanie wiadomości e-mail SMTP to automatyczny transfer wiadomości z jednego serwera na inny. Oznacza to, że wiadomość e-mail jest przekazywana do serwera, którego adres IP nie jest wymieniony w rekordzie SPF domeny. Sprawia to, że jest to nieautoryzowany nadawca wiadomości e-mail, chociaż w praktyce jest on legalny. 

Czy masz jakąkolwiek kontrolę nad tym działaniem? Odpowiedź brzmi: nie, ponieważ wiadomość e-mail jest przekazywana automatycznie po stronie odbiorcy. W takich okolicznościach SPF nie powiedzie się dla przekazywanych wiadomości e-mail. 

Oto, gdzie posiadanie polityki SPF hardfail może wpędzić Cię w kłopoty! Jak już wiemy, mechanizmy hardfail mogą prowadzić do odrzucenia nieudanych wiadomości. W związku z tym, te przekazywane wiadomości e-mail mogą nie zostać dostarczone, jeśli domena jest skonfigurowana z polityką hardfail. 

Najgorsze? Działania podjęte przez polityki dotyczącej awarii SPF zastąpią DMARC i DKIM . Zasadniczo, nawet jeśli DKIM, a następnie DMARC przejdą pomyślnie, wiadomość e-mail nadal może nie zostać dostarczona.   

Jak określono w RFC 7489 Sekcja 10.1 jeśli kontrole SPF są wykonywane przed operacjami DMARC, obecność prefiksu "-" w mechanizmie SPF nadawcy, takiego jak "-all", może prowadzić do natychmiastowego odrzucenia wiadomości e-mail. Odrzucenie to następuje na wczesnym etapie procesu obsługi wiadomości e-mail, nawet przed rozpoczęciem przetwarzania DMARC.

W związku z tym, jeśli polityka SPF nadawcy wiadomości e-mail zawiera mechanizm „-all”, wskazujący na ścisłą politykę odrzucania wiadomości e-mail, które nie przeszły kontroli SPF, może to spowodować odrzucenie wiadomości przed zastosowaniem jakichkolwiek zasad DMARC lub przetworzeniem. Takie wczesne odrzucenie może nastąpić niezależnie od tego, czy wiadomość e-mail ostatecznie przejdzie uwierzytelnianie DMARC.

W związku z tym, w tych okolicznościach, mechanizm SPF Soft fail przeważa nad mechanizmem Hard fail. Jest to podejście o znacznie niższym ryzyku, które pozostawia miejsce na weryfikację poprzez zwykłe oznaczanie autoryzowanych wiadomości e-mail zamiast ich odrzucania. 

Luki w zabezpieczeniach związane z omijaniem SPF i przekazywaniem wiadomości

Zrozumienie potencjalnych słabych punktów wdrożenia SPF ma kluczowe znaczenie dla utrzymania solidnego bezpieczeństwa poczty elektronicznej:

Typowe scenariusze obejścia SPF:

• Przekazywanie wiadomości e-mail: legalne wiadomości e-mail przekazywane za pośrednictwem usług stron trzecich mogą nie przejść weryfikacji SPF.
• Serwery list mailingowych: wiadomości wysyłane za pośrednictwem list mailingowych często zmieniają adres IP nadawcy.
• Usługi poczty elektronicznej w chmurze: Dynamiczne zakresy adresów IP w usługach chmurowych mogą powodować błędy SPF.
• Mobilne klienty poczty elektronicznej: wiadomości e-mail wysyłane z urządzeń mobilnych za pośrednictwem różnych sieci

Najlepsze praktyki w zakresie łagodzenia skutków:

• Wdrożenie DKIM wraz z SPF w celu dodatkowego uwierzytelniania
• Użyj DMARC, aby płynnie radzić sobie z błędami SPF
• Regularnie kontroluj i aktualizuj rekordy SPF.
• Monitoruj raporty uwierzytelniania poczty elektronicznej pod kątem anomalii.

Jak działają rekordy SPF?

Aby wdrożyć SPF dla swoich wiadomości e-mail, należy utworzyć i opublikować rekord SPF w DNS swojej domeny. Typowy przykład rekordu SPF jest następujący:

v=spf1 include:_spf.google.com ~all

W tym rekordzie SPF autoryzujesz wszystkie wiadomości e-mail pochodzące z adresów IP wymienionych w rekordzie SPF Google. Mechanizm niepowodzenia jest zdefiniowany na samym końcu rekordu (~all), czyli Softfail. 

W związku z tym rekord SPF definiuje używaną wersję protokołu, autoryzowane źródła wysyłania i mechanizm niepowodzenia. Publikując ten rekord w DNS, zapewniasz, że tylko autoryzowani nadawcy mogą wysyłać wiadomości e-mail w imieniu Twojej domeny. Jeśli nieautoryzowane źródło próbuje się pod ciebie podszyć, SPF kończy się niepowodzeniem z typem mechanizmu niepowodzenia zdefiniowanym w rekordzie. 

Bezpieczne strategie wdrażania SPF

Optymalne wdrożenie SPF jest niezbędne do ochrony komunikacji e-mailowej przed nieautoryzowanym spoofingu i phishingu . Stosując najlepsze praktyki, organizacje mogą zwiększyć bezpieczeństwo poczty elektronicznej i chronić reputację swojej marki. Oto kilka strategii i wytycznych dotyczących bezpiecznego wdrażania SPF:

1. Użyj narzędzia do generowania rekordów SPF

Proces wdrażania SPF rozpoczyna się od wygenerowania rekordu. Rekord można utworzyć ręcznie, mając odpowiednie zrozumienie tagów SPF. Metoda ta jest jednak podatna na błędy ludzkie. Idealnym rozwiązaniem jest skorzystanie z naszego zautomatyzowanego Generator SPF narzędzie. Pomaga ono stworzyć bezbłędny, dokładny rekord SPF, który jest dostosowany do potrzeb Twojej organizacji.

2. Stosowanie odpowiednich mechanizmów SPF

Wykorzystaj mechanizmy SPF, takie jak "include", "a" i "IP4", aby określić dozwolone źródła wysyłania. Rozsądnie wybieraj mechanizmy w oparciu o swoją infrastrukturę poczty e-mail i upewnij się, że dokładnie odzwierciedlają one twoje praktyki wysyłania wiadomości e-mail.

3. Utrzymanie i optymalizacja rekordu SPF

Rekord Sender Policy Framework musi być utrzymywany i optymalizowany, aby zapobiec jego nieprawidłowemu działaniu. SPF ma tendencję do awarii, gdy autoryzowani nadawcy przekroczą limit 10 wyszukiwań DNS po stronie odbiorcy. Aby utrzymać optymalny limit wyszukiwań, nasz hostowane rozwiązanie SPF jest najlepszym rozwiązaniem! Pomagamy właścicielom domen zoptymalizować SPF za pomocą jednego kliknięcia, aby pozostać poniżej limitów wyszukiwania i unieważnień oraz utrzymać bezbłędny SPF. 

4. Połączenie SPF z DMARC

Wdrażanie DMARC (Domain-based Message Authentication, Reporting, and Conformance) wraz z SPF zapewnia dodatkową (ale niezbędną) warstwę bezpieczeństwa. DMARC umożliwia właścicielom domen określenie zasad obsługi wiadomości e-mail, w tym działań, jakie należy podjąć w przypadku wiadomości e-mail, które nie spełniają SPF.

DMARC wykazał udowodnione wyniki w minimalizowaniu oszustw e-mailowych, kompromitacji i ataków podszywania się. 

5. Wdrożenie rygorystycznych zasad obsługi błędów SPF

Skonfiguruj rekord tak, aby traktował Niepowodzenia uwierzytelniania SPF z rygorystycznymi zasadami, takimi jak odrzucanie lub oznaczanie wiadomości e-mail z domen, w których wystąpiły błędy. W tym celu można zaimplementować SPF hardfail lub SPF softfail zamiast neutralnej polityki.

6. Monitorowanie wyników uwierzytelniania SPF

Wdrożenie Raporty DMARC do monitorowania wyników uwierzytelniania SPF, takich jak SPF pass i fail, a także błędów wyrównania. A Analizator DMARC może pomóc w analizowaniu i analizowaniu danych uwierzytelniania SPF w zorganizowany, czytelny dla człowieka sposób.

Słowa końcowe

Nie ma bezpośredniej odpowiedzi na pytanie "Co jest lepsze? SPF hardfail czy softfail". Podczas gdy znacznik hardfail może zapewnić lepsze bezpieczeństwo, wybór właściwego rozwiązania do monitorowania źródeł wysyłania staje się kluczowy. 

Zaawansowane uwierzytelnianie domen PowerDMARC platformy uwierzytelniania domen i raportowania zapewnia kompleksowe rozwiązania SPF i DMARC dla firm każdej wielkości. 

Wypróbuj platformę z certyfikatem SOC2, której zaufały tysiące organizacji na całym świecie. Rozpocznij bezpłatny okres próbny już dziś!

Najczęściej zadawane pytania

1. Jaka jest przyczyna miękkiej awarii SPF?

Błąd SPF soft fail występuje, gdy wiadomość e-mail jest wysyłana z adresu IP, który nie jest wyraźnie autoryzowany w rekordzie SPF domeny, ale właściciel domeny skonfigurował mechanizm „~all” zamiast „-all”. Oznacza to, że nadawca „prawdopodobnie nie jest autoryzowany”, ale pozwala na dostarczenie wiadomości e-mail z flagą ostrzegawczą zamiast jej całkowitego odrzucenia.

2. Co to jest błąd 550 5.7.0 SPF hard fail?

Błąd „550 5.7.0 SPF hard fail” występuje, gdy serwer poczty elektronicznej odrzuca wiadomość, ponieważ adres IP nadawcy nie jest autoryzowany w rekordzie SPF domeny kończącym się na „-all”. Jest to trwała awaria, która uniemożliwia dostarczenie wiadomości e-mail i wskazuje, że serwer odbiorczy stosuje rygorystyczne zasady egzekwowania SPF.

3. Kiedy można uzyskać twardy błąd SPF?

Otrzymujesz komunikat o poważnej awarii SPF, gdy: 1) adres IP nadawcy nie jest wymieniony w rekordzie SPF domeny, 2) rekord SPF kończy się na „-all” (polityka poważnych awarii), 3) wiadomość e-mail została wysłana z nieautoryzowanego serwera lub usługi, 4) w rekordzie SPF występują błędy konfiguracji lub 5) domena wdrożyła surowe zasady uwierzytelniania wiadomości e-mail.

4. Co oznacza symbol „hard fail” w SPF?

Symbolem całkowitej porażki w SPF jest znak minus „-” poprzedzony słowem „all” (zapisywanym jako „-all”). Mechanizm ten nakazuje serwerom pocztowym odrzucanie wszystkich wiadomości e-mail, które nie są zgodne z autoryzowanymi adresami IP lub domenami wymienionymi w rekordzie SPF. Jest to najsurowsza polityka SPF, zapewniająca najwyższy poziom bezpieczeństwa uwierzytelniania wiadomości e-mail.

5. Czy w mojej firmie powinienem stosować twardą czy miękką awarię SPF?

W przypadku większości firm zaleca się rozpoczęcie od ustawienia SPF soft fail (~all) podczas fazy wdrażania i testowania, aby uniknąć blokowania legalnych wiadomości e-mail. Po zidentyfikowaniu wszystkich autoryzowanych źródeł wysyłania i przeprowadzeniu dokładnych testów należy rozważyć przejście na ustawienie hard fail (-all) w celu zapewnienia maksymalnego bezpieczeństwa. Organizacje posiadające złożoną infrastrukturę poczty elektronicznej lub korzystające z usług stron trzecich powinny dokładnie ocenić ryzyko blokowania legalnych wiadomości e-mail przed wdrożeniem ustawienia hard fail.

• O
• Latest Posts

Yunes Tarada

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

Yunes jest liderem zespołu operacyjnego w PowerDMARC z wiedzą ekspercką w zakresie uwierzytelniania i bezpieczeństwa poczty elektronicznej. Yunes jest certyfikowanym przez Microsoft Azure Administrator Associate z certyfikatami CompTIA A+ i wieloma innymi.

Najnowsze posty autorstwa Yunes Tarada (zobacz wszystkie)

• DMARCbis – co się zmienia i jak się przygotować - 16 kwietnia 2026 r.
• Nieprawidłowy format numeru seryjnego SOA: przyczyny i sposoby rozwiązania - 13 kwietnia 2026 r.
• Jak wysyłać bezpieczne wiadomości e-mail w Gmailu: przewodnik krok po kroku - 7 kwietnia 2026 r.