SPF — jak ustawić rekord i nie stworzyć dwóch polityk?

SPF informuje serwer odbiorcy, które systemy mogą wysyłać pocztę w imieniu określonej domeny transportowej. Rekord wygląda niepozornie, ale jego bezpieczne wdrożenie wymaga spisania wszystkich źródeł wysyłki. Najczęstszy błąd polega na dodaniu drugiego rekordu zamiast połączeniu zmian w jednej polityce.

Krótka odpowiedź: najpierw spisz każdą usługę wysyłającą pocztę z domeny: skrzynki firmowe, WordPress, newsletter, faktury, CRM i automatyzacje. Odczytaj istniejące rekordy TXT. Dla jednej nazwy domenowej powinna istnieć jedna polityka zaczynająca się od v=spf1. Jeśli SPF już jest, połącz autoryzowane źródła zgodnie z instrukcjami dostawców — nie publikuj drugiej polityki. Po zmianie sprawdź DNS oraz nagłówki prawdziwych wiadomości.

Co dokładnie sprawdza SPF?

Serwer odbiorcy porównuje adres IP systemu przekazującego wiadomość z polityką domeny użytej podczas transportu SMTP. Najczęściej chodzi o domenę z adresu MAIL FROM, nazywaną też envelope sender. Gdy ten adres jest pusty, np. w części powiadomień o niedostarczeniu, oceniana może być domena z HELO lub EHLO.

To ważne, ponieważ SPF nie uwierzytelnia automatycznie adresu widocznego w polu From. Wiadomość może uzyskać spf=pass dla technicznej domeny dostawcy, a jednocześnie nie spełnić DMARC dla domeny widocznego nadawcy. Do DMARC potrzebne jest jeszcze wyrównanie domen, czyli alignment.

SPF nie jest również certyfikatem jakości wiadomości. Wynik pass mówi, że dane źródło zostało dopuszczone przez właściciela ocenianej domeny. Nie gwarantuje dostarczenia do skrzynki odbiorczej.

Krok 1: zrób inwentaryzację wysyłki

Nie zaczynaj od kopiowania rekordu znalezionego w poradniku. Najpierw odpowiedz, skąd faktycznie wychodzą wiadomości:

• skrzynki pracowników i aplikacje mobilne;
• powiadomienia z formularzy WordPress;
• sklep i wiadomości transakcyjne;
• platforma newsletterowa;
• system faktur lub rezerwacji;
• CRM, helpdesk i automatyzacje;
• serwer, który wysyła kopie zapasowe lub alerty;
• zewnętrzna agencja działająca w imieniu firmy.

Dla każdej pozycji zapisz właściciela, domenę w MAIL FROM, dostawcę, sposób uwierzytelnienia oraz oficjalny fragment SPF. Jeśli nie wiesz, czy usługa używa Twojej domeny, wyślij kontrolowaną wiadomość i przejrzyj pełne nagłówki.

Usuń z polityki system dopiero po potwierdzeniu, że przestał wysyłać. Stare wpisy nie powinny zostawać bez końca: niepotrzebnie poszerzają zbiór uprawnionych nadawców i komplikują ocenę.

Krok 2: odczytaj rekord przed zmianą

SPF publikuje się jako rekord TXT. Odczyt można wykonać narzędziem DNS, np.:

dig example.pl TXT

Wynik może zawierać kilka rekordów TXT do różnych celów. Szukaj wartości zaczynającej się od v=spf1. Dla jednej nazwy nie wolno tworzyć kilku rekordów SPF. Według RFC 7208 znalezienie więcej niż jednej pasującej polityki prowadzi do błędu permerror, a nie do ich automatycznego połączenia.

Jeśli panel DNS pokazuje już SPF, edytuj go. Gdy nie masz pewności, czy rekord dotyczy domeny głównej, subdomeny albo technicznego return-path, sprawdź pełną nazwę hosta. Polityka example.pl i polityka mail.example.pl to dwa różne miejsca oceny.

Jak czytać składnię SPF?

Przykład wyłącznie poglądowy:

v=spf1 include:_spf.dostawca.example ip4:192.0.2.10 -all

Elementy oznaczają:

• v=spf1 — wersję polityki;
• include: — ocenę wskazanej polityki dostawcy;
• ip4: i ip6: — konkretne adresy lub zakresy;
• a — adresy wynikające z rekordu A/AAAA wskazanej nazwy;
• mx — hosty obsługujące pocztę przychodzącą dla domeny;
• redirect= — przekazanie oceny do innej polityki;
• all — dopasowanie wszystkiego, zwykle umieszczane na końcu.

Mechanizmy mogą mieć kwalifikatory: + oznacza pass i jest domyślne, - fail, ~ softfail, a ? neutral. Samo użycie mx lub a, bo „brzmi bezpiecznie”, może dopuścić serwery, które nigdy nie powinny wysyłać poczty. Dodawaj tylko świadomie potrzebne mechanizmy.

Nie przepisuj przykładowego include ani adresu IP. Każdy dostawca publikuje własne wymagania, które mogą się zmieniać.

Limit zapytań DNS: dlaczego krótszy rekord nie zawsze jest prostszy?

Podczas jednej oceny SPF mechanizmy i modyfikatory powodujące dodatkowe zapytania DNS podlegają limitowi. RFC 7208 wskazuje maksymalnie 10 takich terminów; jego przekroczenie kończy się permerror. Do limitu należą m.in. include, a, mx, exists i redirect.

Jeden krótki include może wewnętrznie odwoływać się do kilku kolejnych polityk. Dlatego nie wystarczy policzyć słów widocznych w Twoim rekordzie. Trzeba ocenić całe drzewo zależności. Dostawca może też zmienić swoją strukturę bez modyfikacji Twojego wpisu.

Nie „spłaszczaj” automatycznie rekordów dostawcy do listy adresów IP. Taka kopia szybko się dezaktualizuje. Jeżeli zbliżasz się do limitu, usuń nieużywane usługi, rozdziel niezależne strumienie na kontrolowane subdomeny lub skonsultuj architekturę z administratorem poczty.

~all czy -all?

Końcowy mechanizm opisuje wynik dla źródeł, które nie pasowały wcześniej:

• ~all daje softfail;
• -all daje fail;
• ?all jest neutralne;
• +all dopuszcza wszystko i niweczy sens polityki.

Nie ma bezpiecznej reguły „zawsze wstaw -all od pierwszego dnia”. Twarde zakończenie ma sens, gdy inwentaryzacja jest kompletna i wiadomości z każdego legalnego systemu przeszły testy. W przeciwnym razie można oznaczyć własną pocztę jako nieuprawnioną. Z drugiej strony pozostawianie luźnej polityki bez planu jej uporządkowania również nie daje mocnej ochrony.

Zmianę podejmuj na podstawie obserwacji rzeczywistych strumieni i raportów DMARC, a nie samego wyniku internetowego walidatora.

Jak połączyć wpisy od kilku usług?

Załóżmy, że firma ma już politykę dla poczty biurowej, a uruchamia dostawcę wiadomości transakcyjnych. Nie dodaje kolejnego rekordu TXT zaczynającego się od v=spf1. Dopisuje nowy, oficjalny mechanizm przed końcowym all w istniejącej polityce.

Przed zapisaniem:

1. zachowaj poprzednią wartość i TTL;
2. sprawdź, czy mechanizm dotyczy właściwej domeny;
3. potwierdź składnię w dokumentacji dostawcy;
4. oceń limit zapytań DNS;
5. nie usuń przypadkiem wcześniejszych legalnych źródeł;
6. zaplanuj test i możliwość szybkiego wycofania zmiany.

Panel DNS może automatycznie dopisywać nazwę domeny do pola hosta. Dla domeny głównej zwykle używa się symbolu @ albo pustej nazwy, ale zależy to od operatora. Patrz na końcową, w pełni kwalifikowaną nazwę rekordu.

Jak przetestować SPF po publikacji?

Sam podgląd w panelu nie wystarczy. Wykonaj trzy rodzaje kontroli.

1. Odczyt publicznego DNS

Sprawdź rekord przez niezależny resolver po upływie czasu propagacji. Upewnij się, że widoczna jest dokładnie jedna polityka SPF i nie ma literówek.

2. Rzeczywista wiadomość z każdego źródła

Wyślij test osobno ze skrzynki, WordPressa, newslettera i pozostałych systemów. W pełnych nagłówkach szukaj Authentication-Results, wyniku SPF oraz domeny, dla której go policzono. spf=pass dla innej domeny niż oczekiwana może nie pomóc DMARC.

3. Test negatywny

Jeśli masz kontrolowane środowisko, sprawdź, jak polityka ocenia nieuprawnione źródło. Nie podszywaj się pod cudzą domenę i nie prowadź testów masowych. Celem jest potwierdzenie logiki we własnej infrastrukturze.

Dlaczego przekazywanie wiadomości może zepsuć SPF?

Gdy serwer pośredni przekazuje wiadomość dalej, odbiorca widzi adres IP pośrednika, a nie pierwotnego nadawcy. Jeśli pośrednik nie jest uprawniony przez ocenianą domenę, SPF może przestać przechodzić. To jedna z przyczyn, dla których domena powinna korzystać również z DKIM. Podpis DKIM może przetrwać przekazanie, o ile treść i podpisane nagłówki nie zostały zmienione w sposób unieważniający podpis.

Najczęstsze błędy SPF

• drugi rekord v=spf1 dla tej samej nazwy;
• bezrefleksyjne skopiowanie polityki z poradnika;
• pominięcie WordPressa, newslettera lub faktur;
• pozostawienie nieużywanych usług;
• przekroczenie limitu zapytań DNS;
• użycie +all;
• ustawienie -all bez pełnej inwentaryzacji;
• sprawdzenie tylko składni, bez wysłania wiadomości;
• uznanie spf=pass za gwarancję DMARC i dostarczenia.

SPF jako część większej konfiguracji

Dobra konfiguracja poczty nie kończy się na jednym TXT. WordPress powinien wysyłać przez kontrolowany transport, From musi reprezentować domenę firmy, DKIM powinien podpisywać wiadomości, a DMARC sprawdzać wyrównanie widocznego autora z uwierzytelnioną domeną.

Po każdej zmianie zapisz datę, osobę odpowiedzialną, poprzednią wartość, powód oraz wyniki testów. Taki rejestr jest znacznie cenniejszy niż anonimowy „zielony wynik” walidatora — pozwala później bezpiecznie usunąć usługę albo znaleźć moment, w którym legalny strumień przestał przechodzić uwierzytelnienie.

Checklista wdrożenia SPF

• ☐ Wszystkie systemy wysyłające pocztę zostały spisane.
• ☐ Odczytano istniejące rekordy TXT z publicznego DNS.
• ☐ Dla ocenianej nazwy istnieje tylko jedna polityka v=spf1.
• ☐ Każdy mechanizm pochodzi z aktualnej dokumentacji dostawcy.
• ☐ Usunięto nieużywane źródła.
• ☐ Sprawdzono pełne drzewo zapytań DNS i limit 10 terminów.
• ☐ Zakończenie all odpowiada zweryfikowanemu etapowi wdrożenia.
• ☐ Wysłano wiadomość z każdego legalnego systemu.
• ☐ Sprawdzono wynik i ocenianą domenę w nagłówkach.
• ☐ Zachowano poprzednią wartość oraz plan wycofania zmiany.