SPF softfail vs hardfail — co wybrać dla swoich maili?

Jeden znak w rekordzie DNS może zadecydować o tym, czy Twoje maile trafiają do skrzynki odbiorczej, czy lądują w spamie — albo nie docierają wcale. Różnica między SPF softfail (~all) a SPF hardfail (-all) jest właśnie tak subtelna i jednocześnie tak istotna. Ten artykuł wyjaśnia, czym różnią się obie opcje, jak wpływają na dostarczalność maili i którą wybrać w zależności od Twojej sytuacji.

Czym jest rekord SPF i dlaczego w ogóle ma znaczenie?

SPF (Sender Policy Framework) to mechanizm uwierzytelniania poczty opisany w RFC 7208. Działa prosto: właściciel domeny publikuje w DNS listę serwerów i adresów IP, które są uprawnione do wysyłania maili w jego imieniu. Serwer odbiorczy sprawdza, czy wiadomość przyszła z dozwolonego źródła, i na tej podstawie decyduje, co z nią zrobić.

Konfiguracja SPF to jeden z trzech filarów uwierzytelniania poczty — obok DKIM i DMARC. Bez poprawnego rekordu SPF Twoje wiadomości są bardziej narażone na odrzucenie lub oznaczenie jako spam, a Twoja domena jest łatwiejszym celem dla spoofingu.

Co oznacza mechanizm „all" w rekordzie SPF?

Na końcu każdego rekordu SPF znajduje się dyrektywa all, poprzedzona jednym z czterech kwalifikatorów. To ona decyduje, co serwer odbiorczy ma zrobić z wiadomością wysłaną z adresu IP nieuwzględnionego na liście dozwolonych nadawców.

Cztery kwalifikatory — szybki przegląd

W praktyce interesują nas głównie dwie ostatnie opcje: softfail i hardfail. To między nimi toczy się większość dyskusji w kontekście konfiguracji SPF.

SPF softfail (~all) — łagodna polityka z konsekwencjami

Softfail to sygnał: „ten serwer prawdopodobnie nie jest uprawniony, ale nie jestem tego pewien — potraktuj wiadomość z ostrożnością". Serwer odbiorczy może oznaczyć taką wiadomość nagłówkiem X-Spam, obniżyć jej reputację w filtrze antyspamowym lub skierować ją do folderu spam — jednak nie odrzuci jej automatycznie.

Kiedy softfail ma sens?

• Wdrożenie SPF od zera — gdy nie masz pewności, czy zebrałeś wszystkie źródła wysyłki (np. zewnętrzne systemy CRM, platformy marketingowe, narzędzia do faktur). Softfail pozwala obserwować ruch bez ryzyka utraty legalnych wiadomości.
• Środowisko z wieloma nadawcami — duże organizacje z dziesiątkami systemów wysyłających maile w imieniu domeny. Zanim wszystko zostanie ujęte w rekordzie, softfail jest bezpieczniejszym buforem.
• Brak wdrożonego DMARC — bez DMARC i tak to serwer odbiorcy decyduje, co zrobi z wynikiem SPF. Softfail daje mu większą swobodę.

Wady softfail

• Słabsza ochrona przed spoofingiem — phisherzy mogą wysyłać maile z Twojej domeny, a część serwerów je przyjmie.
• Niższy sygnał bezpieczeństwa dla dużych dostawców (Gmail, Microsoft 365), którzy preferują jednoznaczne polityki.
• Przy wdrożeniu DMARC z p=reject softfail może dawać niespójne wyniki, jeśli DKIM nie pokrywa wszystkich wiadomości.

SPF hardfail (-all) — twarda polityka, wyższe ryzyko błędu

Hardfail to jednoznaczny komunikat: „każda wiadomość spoza tej listy jest nieautoryzowana i powinna zostać odrzucona". Serwer odbiorczy dostaje jasną instrukcję i w teorii powinien odrzucić wiadomość na poziomie SMTP (kod 550) lub przynajmniej potraktować ją jako spam wysokiego ryzyka.

Kiedy hardfail jest właściwym wyborem?

• Dojrzała infrastruktura wysyłki — wiesz dokładnie, z jakich serwerów i adresów IP wysyłasz maile i masz je wszystkie ujęte w rekordzie SPF.
• Wdrożone DMARC z egzekwowaniem — hardfail w połączeniu z p=reject w DMARC tworzy kompletną tarczę przed spoofingiem domeny.
• Domeny nieużywane do wysyłki — jeśli masz domenę parkingową lub subdomenę, która nigdy nie wysyła maili, v=spf1 -all to idealne zabezpieczenie.

Wady hardfail i typowe SPF record błędy

Hardfail jest bezlitosny dla pomyłek. Najczęstsze błędy w konfiguracji SPF, które przy -all kończą się niedostarczeniem maili:

• Pominięcie zewnętrznego dostawcy — np. system do wysyłki newsletterów, platforma helpdesk lub narzędzie do faktur elektronicznych, które nie zostało dodane do rekordu SPF.
• Przekroczenie limitu 10 lookupów DNS — RFC 7208 dopuszcza maksymalnie 10 zapytań DNS podczas weryfikacji SPF. Każde include:, a, mx to osobne zapytanie. Przy hardfail przekroczenie tego limitu skutkuje wynikiem PermError, który wiele serwerów traktuje jak fail.
• Forwarding poczty — gdy odbiorca przekazuje maile dalej (np. z uczelnianej skrzynki na prywatną), adres IP serwera pośredniczącego nie figuruje w Twoim SPF. Hardfail może spowodować odrzucenie takiej wiadomości.

Jak ~all i -all wpływają na dostarczalność maili?

Wpływ na dostarczalność maili SPF zależy od tego, jak serwery odbiorcze interpretują wyniki weryfikacji — a tu nie ma jednej reguły. Gmail, Microsoft 365, Yahoo i inne duże providery mają własne algorytmy, które traktują wynik SPF jako jeden z wielu sygnałów reputacyjnych.

Co mówią dane i praktyka?

W praktyce sam wynik SPF (softfail vs hardfail) rzadko jest jedynym czynnikiem decydującym o tym, czy mail trafi do skrzynki. Kluczowe jest to, czy masz wdrożone DMARC — bo to właśnie DMARC określa, co serwer odbiorcy ma zrobić z wynikiem SPF. Bez DMARC serwer może zignorować nawet hardfail i dostarczyć wiadomość.

Natomiast przy wdrożonym DMARC (p=quarantine lub p=reject) wynik SPF ma bezpośrednie przełożenie na losy wiadomości. Softfail przy DMARC p=reject może być problematyczny — jeśli DKIM też nie przejdzie, wiadomość zostanie odrzucona mimo że SPF nie był jednoznacznym failem.

Tabela porównawcza: softfail vs hardfail

Jak poprawnie skonfigurować rekord SPF — praktyczne wskazówki

Niezależnie od tego, czy wybierzesz softfail czy hardfail, konfiguracja SPF musi być precyzyjna. Oto co sprawdzić przed publikacją rekordu:

1. Zbierz wszystkie źródła wysyłki

Wypisz każdy system, który wysyła maile z Twojej domeny: własne serwery SMTP, platformy marketingowe, systemy CRM, narzędzia do fakturowania, helpdesk. Każde z nich musi być ujęte w rekordzie — albo przez ip4:/ip6:, albo przez include: wskazujące na rekord SPF dostawcy.

2. Pilnuj limitu 10 lookupów DNS

Policz zapytania DNS generowane przez Twój rekord. Każde include:, a, mx, ptr, exists to osobne zapytanie. Jeśli zbliżasz się do limitu, rozważ spłaszczenie rekordu SPF (tzw. SPF flattening) — zastąpienie include: bezpośrednimi adresami IP.

3. Używaj narzędzi do weryfikacji

Przed wdrożeniem sprawdź rekord narzędziami takimi jak MXToolbox SPF Checker czy dmarcian SPF Surveyor. Wykryją błędy składniowe, nadmiarowe lookups i niespójności. Jeśli wysyłasz kampanie przez własne serwery SMTP — np. korzystając z MailerPRO — upewnij się, że adresy IP tych serwerów są wprost wymienione w rekordzie SPF Twojej domeny.

4. Testuj przed przełączeniem na hardfail

Zacznij od softfail i przez 2-4 tygodnie monitoruj raporty DMARC (jeśli masz wdrożone DMARC z rua). Raporty pokażą, czy któreś źródło wysyłki nie figuruje jeszcze w rekordzie. Dopiero gdy masz pewność, że lista jest kompletna — przełącz na -all.

Jedna prosta rekomendacja

Jeśli dopiero konfigurujesz SPF lub nie masz pewności co do wszystkich źródeł wysyłki — zacznij od softfail (~all) i wdróż DMARC w trybie monitorowania (p=none). Analizuj raporty, uzupełniaj rekord, a gdy masz kompletną listę — przejdź na hardfail (-all) i podnieś DMARC do p=quarantine lub p=reject. To jedyna droga, która daje i bezpieczeństwo, i pewność, że żaden legalny mail nie przepadnie przez pomyłkę w konfiguracji.