Kluczowe wnioski
- Protokół SPF pomaga sprawdzić, czy serwer wysyłający jest uprawniony do wysyłania wiadomości e-mail w imieniu Twojej domeny, ale najskuteczniej działa w połączeniu z protokołami DKIM i DMARC.
- Rekordy SPF wykorzystują mechanizmy, kwalifikatory i modyfikatory do definiowania autoryzowanych nadawców oraz do kontrolowania sposobu, w jaki serwery odbiorcze obsługują wiadomości niezgodne z regułami.
- Serwer odbiorcy sprawdza rekord SPF poprzez DNS lookup, aby zweryfikować autoryzację nadawcy.
- Wyniki sprawdzania SPF mogą to: „Pass”, „Fail”, „SoftFail”, „Neutral”, „None”, „TempError” lub „PermError”, w zależności od oceny rekordu i serwera odbierającego.
- Modyfikatory SPF, takie jak „exp” i „redirect”, zapewniają dodatkowe możliwości dostosowania procesu weryfikacji i obsługi wiadomości e-mail.
Jeśli kiedykolwiek zastanawiałeś się, dlaczego niektóre z Twoich legalnych wiadomości e-mail trafiają do folderów ze spamem lub są w ogóle blokowane, przyczyną może być sposób skonfigurowania uwierzytelniania poczty elektronicznej w Twojej domenie. Kluczowym czynnikiem jest tutaj składnia rekordu SPF, która odgrywa kluczową rolę w weryfikacji, czy Twoje wiadomości są wysyłane z autoryzowanych serwerów. Chociaż SPF pomaga zapobiegać oznaczaniu Twoich wiadomości jako podejrzanych, jego składnia może być trudna do zrozumienia, a prawidłowa konfiguracja – jeszcze trudniejsza.
W tym wpisie omówimy, jak działa składnia rekordu SPF oraz o czym należy pamiętać podczas konfigurowania go dla swojej domeny.
Czym jest składnia rekordu SPF?
Składnia rekordu SPF to zestaw reguł, które definiują sposób zapisu rekordu SPF (Sender Policy Framework) w DNS domeny. Mówiąc prościej, jest to "język" używany przez domenę do informowania odbierających serwerów pocztowych, które źródła są upoważnione do wysyłania wiadomości e-mail w jej imieniu.
Składnia rekordu SPF zazwyczaj obejmuje mechanizmy (takie jak ip4, ip6 lub include), kwalifikatory (np. +, -, ~ lub ?) oraz modyfikatory, które wspólnie decydują o tym, czy przychodząca wiadomość e-mail przejdzie kontrolę SPF, czy też nie.
Zrozumienie tej składni jest kluczowe, ponieważ nawet niewielki błąd, taki jak dodatkowa spacja, nieprawidłowy kwalifikator lub brakujący mechanizm, może spowodować, że wiadomości e-mail nie przejdą uwierzytelnienia i wylądują w spamie lub zostaną odrzucone.
Uwagadotycząca zgodności z DMARC: SPF weryfikuje domenę nadawcy koperty, a nie zawsze widoczny adres „Od”, który użytkownicy widzą w swojej skrzynce odbiorczej. Aby DMARC przeszedł pomyślnie przez SPF, domena w polu Return-Path musi być zgodna z widoczną domeną „Od”. Dlatego właśnie SPF powinien być stosowany w połączeniu z DKIM i DMARC.
Struktura i elementy składowe składni rekordu SPF
Rekord SPF składa się z czterech głównych części: znacznika wersji, mechanizmów, kwalifikatorów i modyfikatorów. Każda z tych części pełni określoną rolę, a wszystkie razem decydują o tym, w jaki sposób serwery pocztowe odbierające obsługują wiadomości e-mail, które rzekomo pochodzą z Twojej domeny.
| Komponent SPF | Cel | Przykład |
|---|---|---|
| Znacznik wersji | Określa rekord jako SPF | v=spf1 |
| Mechanizm | Określa autoryzowanych nadawców | ip4:203.0.113.5 |
| Kwalifikator | Określa wynik w przypadku dopasowania mechanizmu | -wszystkie, ~wszystkie |
| Modyfikator | Dodaje opcjonalne instrukcje przetwarzania | redirect=, exp= |
Tag wersji
Tag wersji stanowi punkt wyjścia rekordu SPF. Określa on, że rekord wykorzystuje składnię SPF, i gwarantuje, że serwery pocztowe poprawnie zinterpretują następujący tekst. Bez niego rekord nie będzie działał. Dozwolony jest tylko jeden tag wersji, który musi znajdować się na samym początku rekordu. Aktualny prawidłowy format: v=spf1.
Kwalifikatory SPF: +, -, ~ i ?
Kwalifikatory to symbole umieszczane przed mechanizmami. Określają one, jak ma postąpić serwer pocztowy odbierający wiadomość, jeśli mechanizm zostanie dopasowany. Jeśli kwalifikator nie zostanie określony, domyślnym działaniem jest „Przekaż dalej”.
| Kwalifikator | Wynik | Znaczenie | Typowy przypadek użycia | Poziom ryzyka |
|---|---|---|---|---|
| + | Pass | Nadawca zweryfikowany; wiadomość przyjęta | Domyślnie — rzadko zapisywane wprost | Niski |
| - | Fail | Nadawca nieuprawniony; wiadomość odrzucona | Rygorystyczne egzekwowanie przepisów po pełnym wdrożeniu | Niski, jeśli kompletny |
| ~ | SoftFail | Prawdopodobnie nieautoryzowane; zgłoszone | Wdrażanie testowe lub przejściowe | Średni |
| ? | Neutralny | Brak decyzji politycznej; decyzję podejmuje serwer | Rzadko stosowane w produkcji | Wysoki — brak ochrony |
Mechanizmy SPF: all, ip4, ip6, a, mx, exists oraz include
Mechanizmy to główne reguły zawarte w rekordzie SPF. Określają one, które serwery, adresy IP lub domeny są uprawnione do wysyłania wiadomości e-mail w imieniu danej domeny. Każdy mechanizm jest sprawdzany po kolei od lewej do prawej, a w przypadku znalezienia dopasowania stosowany jest powiązany kwalifikator.
| Mechanizm | Przykład składni | Co to uprawnia | Wyszukiwanie adresów DNS | Zalecane zastosowanie |
|---|---|---|---|---|
| wszystkie | -all | Pasuje do wszystkich nadawców — reguła „catch-all” na końcu | 0 | Zawsze kończ na -all lub ~all |
| ip4 | ip4:203.0.113.5 | Konkretny adres IPv4 lub zakres CIDR | 0 | Dedykowane serwery wychodzące |
| ip6 | ip6:2001:db8::1 | Konkretny adres IPv6 lub prefiks | 0 | Wysyłanie poczty za pośrednictwem protokołu IPv6 |
| a | a lub a:example.com | Adresy IP odpowiadające rekordom A/AAAA tej domeny | 1 | Gdy serwer WWW wysyła również wiadomości e-mail |
| mx | mx | Adresy IP serwerów MX tej domeny | 1 na MX | Gdy serwery MX wysyłają wiadomości wychodzące |
| ptr | ptr:example.com | Sprawdzenie odwrotnego DNS (przestarzałe zgodnie z RFC 7208) | Wiele | Unikać — przestarzałe |
| istnieje | istnieje:example.com | Zaliczone, jeśli domena jest rozpoznawana w systemie DNS | 1 | Zaawansowane wykorzystanie makr |
| zamieścić | obejmują:_spf.google.com | Nadawcy autoryzowani przez domenę, do której odnosi się odnośnik | 1 + zagnieżdżone | Nadawcy zewnętrzni |
Mechanizm „all”: -all vs ~all vs ?all
-all (błąd krytyczny): Każdy nadawca nieznajdujący się na liście jest wyraźnie odrzucany. Użyj tego ustawienia, gdy rekord SPF zostanie w pełni przetestowany i uwzględni wszystkich uprawnionych nadawców. Jest to zalecane ustawienie zapewniające ścisłe egzekwowanie zasad.
~wszyscy (SoftFail): Niewymienieni nadawcy są akceptowani, ale oznaczani. Należy korzystać z tej opcji podczas testów lub w fazie przejściowej wdrażania, gdy nie ma jeszcze pewności, że wszyscy legalni nadawcy znajdują się na liście.
?wszystkie (neutralne): W przypadku nadawców nieznajdujących się na liście nie są stosowane żadne zasady. Nie zapewnia to rzeczywistej ochrony i nie jest zalecane do użytku produkcyjnego.
+all (Przekaż wszystkim): Zezwala dowolnemu serwerowi na wysyłanie wiadomości w Twoim imieniu. Jest to niebezpieczne i nigdy nie powinno się z tej opcji korzystać.
Modyfikatory SPF: redirect i exp
redirect= (modyfikator): Przekazuje całą ocenę polityki SPF innej domenie. W przeciwieństwie do mechanizmu include, redirect całkowicie zastępuje bieżący rekord i nie można go łączyć z mechanizmem all. Mechanizm mechanizm „SPF include” działa inaczej. Dodaje on autoryzowanych nadawców z rekordu SPF domeny, do której odwołuje się rekord, nie zastępując przy tym własnego rekordu.
exp= (modyfikator): Zapewnia niestandardowy ciąg tekstowy wyjaśniający przyczyny niepowodzeń weryfikacji SPF. Gdy wiadomość nie przejdzie weryfikacji SPF, serwer odbiorczy może sprawdzić ten rekord TXT, aby uzyskać zrozumiałą dla człowieka przyczynę.
„include” a „redirect”: główna różnica
| zamieścić | przekierowanie | |
|---|---|---|
| Typ | Mechanizm | Modyfikator |
| Efekt | Dodaje nadawców z domeny, do której odwołuje się link | Zastępuje całą ocenę SPF |
| Czy można tego używać ze wszystkim? | Tak | Nie — wszystkie nadpisania powodują przekierowanie |
| Liczba wyszukiwań DNS | Wlicza się do limitu 10 wyszukiwań | Wlicza się do limitu 10 wyszukiwań |
Wyniki oceny SPF i ich znaczenie
Gdy serwer pocztowy odbierający wiadomość analizuje rekord SPF, zwraca jeden z siedmiu możliwych wyników. Zrozumienie każdego z tych wyników pomaga właścicielom domen zdiagnozować przyczyny niepowodzeń w dostarczaniu wiadomości oraz ulepszyć konfigurację SPF. Aby zapoznać się ze strategiami rozwiązywania typowych problemów związanych z SPF, zapoznaj się z naszym przewodnikiem pt. optymalizacji rekordu SPF.
Przykłady składni rekordów SPF
Prosty rekord SPF
v=spf1 ip4:203.0.113.5 -all
v=spf1 → znacznik wersji. ip4:203.0.113.5 → autoryzuje jeden adres IPv4. -all → wszystkie pozostałe serwery nie przejdą weryfikacji. Jest to typowa konfiguracja dla małej domeny wysyłającej wiadomości e-mail z jednego serwera.
Zaawansowany rekord SPF
v=spf1 ip4:203.0.113.0/24 include:_spf.google.com include:_spf.mailhost.com ~all exp=explain._spf.example.com
Ten rekord autoryzuje cały zakres adresów IP /24, dwóch nadawców zewnętrznych, akceptuje nadawców niefigurujących w liście z flagą SoftFail oraz zawiera niestandardowy opis błędu. Każdy mechanizm typu „include”, „a”, „mx”, „exists” oraz „redirect” powoduje wyszukiwanie w systemie DNS. Jeśli łączna liczba przekroczy 10, SPF zwraca błąd PermError.
Przykład rekordu SPF dla firmy
v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:sendgrid.net ~all
Taki wpis jest typowy dla organizacji korzystających z Google Workspace, Microsoft 365 oraz platformy dostarczającej usługi innych dostawców. Każde dodanie powoduje wykonanie zapytań DNS, dlatego zespoły powinny dokładnie sprawdzić poprawność danych, aby uniknąć błędów typu PermError.
Przykład zarządzania MSP SPF
Dla dostawców usług zarządzanych (MSP), którzy zarządzają wieloma domenami klientów, celem jest nie tylko utworzenie jednego prawidłowego rekordu SPF, ale także monitorowanie zmian we wszystkich domenach klientów. Scentralizowana weryfikacja SPF pomaga wykrywać zduplikowane rekordy, ryzyko przekroczenia limitów zapytań oraz uszkodzone wtyczki „include”, zanim klienci napotkają problemy z dostarczaniem wiadomości. Program partnerski PowerDMARC Program partnerski MSP/MSSP firmy PowerDMARC umożliwia dostawcom usług zarządzanie uwierzytelnianiem we wszystkich domenach klientów z poziomu jednego pulpitu nawigacyjnego, bez konieczności przełączania się między narzędziami lub ręcznego analizowania rekordów DNS.
Przykłady składni rekordów SPF TXT w podziale na scenariusze zastosowań
| Przykład zastosowania | SPF Rekord TXT | Wyjaśnienie | Uwaga |
|---|---|---|---|
| Tylko serwery MX | v=spf1 mx -all | Wysyłać mogą wyłącznie serwery MX | Wynik nieudany, jeśli wysłano z adresu innego niż MX |
| Pojedynczy adres IPv4 | v=spf1 ip4:203.0.113.5 -all | Zezwolono na korzystanie z jednego konkretnego adresu IP | Aktualizacja w przypadku zmiany adresu IP |
| Wielu nadawców | v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~all | Google + Microsoft 365 | Łączna liczba wyszukiwań na monitorze |
| Przekierowanie | v=spf1 redirect=_spf.example.com | Polityka przekazana | Nie łączyć z żadnym |
| Brak wysyłania | v=spf1 -all | Domena zawieszona, brak poczty elektronicznej | Używać wyłącznie do celów innych niż wysyłanie |
Jak korzystać z wielu mechanizmów „include” w składni rekordu SPF
v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:sendgrid.net include:_spf.salesforce.com ~all
Każdy mechanizm dołączania wyzwala co najmniej jedno wyszukiwanie DNS, a zagnieżdżone dołączenia powodują dodatkowe wyszukiwania. Łączna liczba wyszukiwań w całym łańcuchu nie może przekroczyć 10. Przetwarzanie SPF zatrzymuje się przy pierwszym dopasowaniu, więc kolejność ma znaczenie – umieść najczęściej używanych nadawców na początku. Jeśli liczba wyszukiwań zbliża się do 10, skorzystaj z narzędzia PowerDMARC narzędzia do spłaszczania SPF firmy PowerDMARC , aby automatycznie zoptymalizować swój rekord. W przypadku złożonych konfiguracji korporacyjnych warto skorzystać z makra SPF stanowią bardziej skalowalną alternatywę dla tradycyjnego spłaszczania, ponieważ rozwijają się dynamicznie w momencie oceny.
Zbyt duża liczba zapytań DNS w rekordach SPF
RFC 7208 ogranicza łączną liczbę zapytań DNS podczas oceny SPF do 10. Ograniczenie to dotyczy całego łańcucha zapytań — w tym zapytań zagnieżdżonych wywołanych przez mechanizmy include, a, mx, exists oraz redirect. Jeśli limit zostanie przekroczony, serwer odbierający zwraca błąd PermError, co powoduje całkowite niepowodzenie oceny SPF. Istnieje również mniej znane ograniczenie: limit dwóch bezowocnych zapytań. Jeśli więcej niż dwa zapytania DNS zwrócą kod NXDOMAIN, weryfikacja SPF również zakończy się niepowodzeniem. Szczegółowy przewodnik dotyczący sposobu rozwiązania tego problemu można znaleźć w artykule jak naprawić zbyt dużą liczbę wyszukiwań DNS.
Mechanizmy, które się liczą: obejmują (1 + zagnieżdżone), a (1), mx (1 na każde wyszukiwanie MX + A), exists (1), redirect (1 + zagnieżdżone), ptr (wiele — przestarzałe).
Mechanizmy, które NIE są brane pod uwagę: ip4 i ip6 nie powodują wyszukiwania w DNS.
Jak ograniczyć liczbę zapytań DNS: Usuń mechanizmy include dla nadawców, z których już nie korzystasz. Tam, gdzie to możliwe, zastąp mechanizmy a i mx jawnymi wartościami IPv4. Unikaj ptr. Użyj PowerSPF (Hosted SPF) , aby skonsolidować mechanizmy „include” i zmieścić się w limicie bez konieczności ręcznej konserwacji DNS. Więcej informacji na temat samego procesu spłaszczania znajdziesz w artykule Spłaszczanie SPF: od przeciążenia DNS do usprawnionego SPF.
Jak opublikować rekord SPF typu TXT w systemie DNS
Rekord SPF jest publikowany jako rekord TXT w systemie DNS Twojej domeny na poziomie domeny głównej (np. example.com) lub w odpowiedniej subdomenie. Skorzystaj z naszego bezpłatnego generatora rekordów SPF , aby natychmiast utworzyć prawidłowy rekord przed opublikowaniem.
| Pole DNS | Wartość do wprowadzenia | Uwagi |
|---|---|---|
| Host/nazwa | @ lub puste pole dla domeny głównej | W przypadku rekordów SPF dla subdomen należy używać nazwy subdomeny |
| Typ | TXT | Starszy typ SPF (typ 99) został wycofany; należy zawsze stosować rekord TXT |
| Wartość | Pełny wpis SPF, np. v=spf1 include:_spf.google.com -all | Należy zacząć od v=spf1 |
| TTL | 3600 (1 godzina) | Niższa wartość TTL przyspiesza propagację podczas wprowadzania zmian |
Ważne: Domena może posiadać tylko jeden rekord TXT typu SPF. Opublikowanie wielu rekordów TXT zaczynających się od v=spf1 powoduje błąd PermError.
Proces walidacji składni SPF
Krok 1: Sporządź wykaz wszystkich źródeł wysyłki — Microsoft 365, Google Workspace, systemy CRM, narzędzia marketingowe, systemy pomocy technicznej, systemy płacowe oraz regionalni nadawcy.
Krok 2: Utwórz lub zaktualizuj rekord SPF — dodaj wyłącznie autoryzowane mechanizmy i elementy „includes”.
Krok 3: Sprawdź liczbę wyszukiwań — upewnij się, że rekord nie przekracza limitu 10 wyszukiwań DNS.
Krok 4: Sprawdź poprawność składni — skorzystaj z narzędzia do sprawdzania SPF w celu wykrycia problemów związanych z formatowaniem, duplikatami i przestarzałymi mechanizmami.
Krok 5: Monitorowanie wyników uwierzytelniania — Przejrzyj raporty DMARC, aby upewnić się, że legalni nadawcy spełniają wymagania zgodności z SPF i DKIM.
Zasady składni rekordów SPF, sprawdzanie poprawności i typowe błędy
Pisanie rekordu SPF polega na umieszczeniu mechanizmów i kwalifikatorów we właściwej kolejności i upewnieniu się, że rekord faktycznie działa zgodnie z przeznaczeniem. Nawet niewielkie błędy składniowe, takie jak brakujący znacznik lub dodatkowa spacja, mogą spowodować niepowodzenie rekordu, skutkując odrzuceniem wiadomości e-mail, oznaczeniem ich jako spam lub pozostawieniem domeny podatnej na spoofing.
Ta sekcja obejmuje trzy kluczowe obszary: najlepsze praktyki dotyczące pisania składni SPF, typowe błędy, których należy unikać oraz sposób walidacji rekordu przed opublikowaniem go na żywo.
Postępuj zgodnie z najlepszymi praktykami dotyczącymi składni SPF
Właściwy SPF zaczyna się od przestrzegania kilku złotych zasad, które sprawiają, że nagranie jest zarówno skuteczne, jak i niezawodne:
- Zawsze zaczynaj od poprawnego znacznika wersji: v=spf1.
- Limit DNS wyszukiwania, aby uniknąć przekroczenia limitu 10 wyszukiwańco spowoduje uszkodzenie rekordu.
- Należy użyć include aby uniknąć pętli lub odwołań cyklicznych.
- Dokumentację należy sporządzać w sposób jak najbardziej zwięzły — zbyt skomplikowane konfiguracje są trudniejsze w utrzymaniu i bardziej podatne na awarie.
- Regularnie sprawdzaj rekordy SPF, zwłaszcza jeśli zmienia się infrastruktura poczty e-mail lub jeśli dodajesz/usuwasz dostawców.
Zarządzanie składnią SPF dla dostawców usług zarządzanych (MSP) i dostawców usług bezpieczeństwa zarządzanych (MSSP)
W przypadku dostawców usług zarządzanych (MSP) i dostawców usług bezpieczeństwa zarządzanych (MSSP), którzy zarządzają SPF w wielu domenach klientów, najlepsze praktyki wykraczają poza samo utworzenie jednego poprawnego wpisu. Do kluczowych kwestii operacyjnych należą:
- Ujednolicenie szablonów SPF dla typowych konfiguracji klientów (na przykład Google Workspace + Microsoft 365), aby przyspieszyć wdrażanie i ograniczyć liczbę błędów składniowych.
- Zautomatyzuj monitorowanie liczby wyszukiwań , aby otrzymywać powiadomienia, zanim rekord SPF klienta przekroczy limit 10 wyszukiwań DNS — zwłaszcza gdy klienci dodają nowe narzędzia SaaS.
- Korzystaj ze scentralizowanych pulpitów nawigacyjnych w celu jednoczesnego wykrywania zduplikowanych rekordów SPF, uszkodzonych odwołań lub brakujących mechanizmów we wszystkich domenach klientów.
- Zmiany w dokumentach za każdym razem, gdy do środowiska klienta dodawany jest nowy nadawca, w celu zapewnienia dokładnej ścieżki audytu na potrzeby zapewnienia zgodności z przepisami i rozwiązywania problemów.
Unikaj typowych błędów składni
Wiele problemów z SPF wynika z prostych, ale szkodliwych błędów. Uważaj na te pułapki:
- Brakuje znacznika wersji: każdy wpis musi zaczynać się od v=spf1.
- Zduplikowane kwalifikatory: użycie więcej niż jednego kwalifikatora dla tego samego mechanizmu jest nieprawidłowe.
- Nadmierne mechanizmy: długie, rozbudowane rekordy zwiększają ryzyko błędów i przekraczają limity DNS.
- Problemy z formatowaniem składni: nieprawidłowo umieszczone spacje, literówki lub znaki nieobsługiwane mogą spowodować niepowodzenie rejestracji.
- Wiele rekordów SPF: domena może mieć tylko jeden rekord SPF — jeśli istnieje więcej niż jeden, walidacja zakończy się niepowodzeniem.
- Mechanizmy wycofane: należy unikać ptr, które nie jest już zalecane i może nie być obsługiwane przez wszystkie serwery.
Pamiętaj: nawet jeśli intencja rekordu jest poprawna, błędy składni spowodują całkowite niepowodzenie SPF.
Sprawdź składnię rekordu SPF
Przed opublikowaniem rekordu SPF, walidacja ma kluczowe znaczenie. Walidatory sprawdzają, czy składnia jest poprawna i czy rekord nie przekracza limitów wyszukiwania DNS lub nie zawiera nieobsługiwanych mechanizmów.
- Skorzystaj z narzędzi do sprawdzania rekordów SPF, takich jak narzędzie PowerDMARC narzędzia do sprawdzania SPF, aby szybko zidentyfikować problemy.
- Walidacja pomaga zapewnić spójne działanie rekordu na różnych serwerach odbierających pocztę.
- Testowanie nowych lub zaktualizowanych rekordów w środowisku przejściowym jest zalecane przed zastosowaniem ich na żywo.
- Regularna walidacja po zmianach zapewnia aktualność i funkcjonalność polityki SPF.
Dzięki walidacji zmniejsza się ryzyko, że wiadomości e-mail zostaną odrzucone, trafią do spamu lub pozostawią domenę podatną na spoofing.
Składnia rekordów SPF w akcji
Prawidłowa składnia rekordu SPF ma kluczowe znaczenie dla bezpiecznego dostarczania wiadomości e-mail i ochrony przed spoofingiem. Każda część — znacznik wersji, mechanizmy, kwalifikatory i modyfikatory — współdziała z pozostałymi, określając sposób, w jaki serwery pocztowe przetwarzają Twoje wiadomości.
W miarę jak popularność SPF stale rośnie, a globalny wskaźnik pozytywnych wyników testów wynosi obecnie 80,24%, organizacje inwestujące w poprawną i zweryfikowaną składnię SPF zyskują wymierną przewagę w zakresie dostarczalności, zgodności z przepisami oraz poziomu bezpieczeństwa.
Aby zapoznać się ze szczegółową instrukcją krok po kroku dotyczącą wstępnej konfiguracji, zobacz jak skonfigurować rekordy SPF. Aby mieć pewność, że spełniasz najnowsze wymogi zgodności, zapoznaj się z wymagania Google i Yahoo dotyczące uwierzytelniania poczty elektronicznej na rok 2026.
Najczęściej zadawane pytania
1. Jak utworzyć rekord SPF?
Zacznij od v=spf1, dodaj mechanizmy służące do wymienienia autoryzowanych nadawców (takie jak ip4: dla konkretnych adresów IP lub include: dla usług stron trzecich), a na końcu dodaj kwalifikator, np. -all, aby zablokować wszystko inne. Opublikuj ten wpis jako pojedynczy rekord DNS typu TXT w katalogu głównym swojej domeny.
2. Co się stanie, jeśli składnia mojego rekordu SPF będzie nieprawidłowa?
Serwery pocztowe mogą odrzucać Twoje wiadomości e-mail lub oznaczać je jako spam, a Twoja domena staje się bardziej narażona na spoofing. Błąd składniowy, taki jak brak tagu wersji, zduplikowane rekordy SPF lub przekroczenie limitu 10 wyszukiwań DNS, może spowodować całkowitą awarię mechanizmu SPF.
3. Jaki jest przykład rekordu SPF wykorzystującego MX?
Rekord SPF wykorzystujący MX ma następujący wygląd: v=spf1 mx -all, co pozwala wyłącznie serwerom pocztowym danej domeny na wysyłanie wiadomości e-mail w jej imieniu.
4. Ile zapytań DNS można wykonać w ramach jednego rekordu SPF?
Zgodnie z definicją zawartą w RFC 7208 protokół SPF dopuszcza maksymalnie 10 zapytań DNS na jedną ocenę. Mechanizmy uwzględniane przy liczeniu to: include, a, mx, exists, redirect oraz ptr. W przypadku przekroczenia tego limitu protokół SPF zwraca błąd PermError.
5. Czy dla jednej domeny można mieć wiele rekordów SPF?
Nie. Domena musi zawierać tylko jeden rekord TXT typu SPF. Wystąpienie wielu rekordów zaczynających się od „v=spf1” powoduje błąd PermError. Należy połączyć wszystkich autoryzowanych nadawców w jeden rekord.
6. Jaka jest różnica między SPF -all a ~all?
-all (twardy błąd) nakazuje odbiorcom odrzucanie wiadomości od nadawców nieznajdujących się na liście. ~all (miękki błąd) nakazuje odbiorcom akceptowanie wiadomości, ale z oznaczeniem ich jako podejrzane. Należy używać opcji ~all podczas testów, a po potwierdzeniu wszystkich legalnych nadawców przełączyć się na opcję -all.
7. Czy sam wskaźnik SPF zapobiega fałszowaniu adresów e-mail?
Nie. SPF weryfikuje jedynie nadawcę koperty (Return-Path), a nie widoczny adres „Od”. Aby zapewnić pełną ochronę przed podszywaniem się i phishingiem, należy go stosować w połączeniu z DKIM i DMARC.
8. Czym jest spłaszczanie SPF i kiedy jest mi to potrzebne?
Funkcja „SPF flattening” zastępuje mechanizmy „include” rozpoznanymi adresami IP, co ogranicza liczbę zapytań DNS. Jest to konieczne, gdy rekord SPF przekracza lub zbliża się do limitu 10 zapytań DNS. Narzędzia automatyczne, takie jak PowerSPF, radzą sobie z tym dynamicznie.
9. Jak długo trwa propagacja rekordu SPF?
Propagacja DNS trwa zazwyczaj od 1 do 4 godzin, w zależności od dostawcy usług DNS i ustawień TTL. W niektórych przypadkach może to potrwać nawet do 48 godzin. Po opublikowaniu zawsze należy sprawdzić poprawność rekordu.
- Firma PowerDMARC uznana za lidera w dziedzinie oprogramowania DMARC już 13. kwartał z rzędu – 28 sierpnia 2026 r.
- Kwarantanna Microsoftu: Jak znaleźć i przywrócić wiadomości e-mail umieszczone w kwarantannie w programie Outlook - 22 sierpnia 2026 r.
- Co się dzieje, gdy chatboty oparte na sztucznej inteligencji ujawniają poufne dane firmowe? – 21 sierpnia 2026 r.