SPF w praktyce: zmapowanie wszystkich nadawców

Moduł 4: Dostarczalność: SPF, DKIM i DMARC w praktyce · Czas czytania: 12 minut

Cel lekcji: Po tej lekcji będą Państwo potrafili wykryć wszystkie usługi wysyłające pocztę w imieniu Państwa domeny, umieścić je w jednym rekordzie SPF, policzyć wyszukiwania rekurencyjnie aż do granicy dziesięciu, oraz świadomie wybrać między ~all a -all.

Kluczowe pojęcia: inwentaryzacja nadawców, nadawca koperty (Return-Path), jeden rekord SPF, include, redirect, limit 10 wyszukiwań DNS (RFC 7208, paragraf 4.6.4), puste wyszukiwania (void lookups, maksymalnie 2), liczenie rekurencyjne, permerror, flattening, SPF dla subdomen, SPF na domenie, która nie wysyła poczty, ~all i -all

Krótkie przypomnienie

Rekord SPF to rekord TXT w Państwa domenie, który zaczyna się od v=spf1 i wymienia serwery uprawnione do wysyłania poczty w imieniu Państwa domeny. Budowa rekordu, znaki + - ~ ? oraz trzy najczęstsze błędy (dwa rekordy, +all, więcej niż dziesięć wyszukiwań) zostały omówione w kursie DNS, w lekcji 4.3. Jeśli SPF jest dla Państwa tematem nowym, prosimy przeczytać najpierw tamtą lekcję. Ta lekcja dotyczy trudniejszej części: w praktyce niemal nikt nie wie dokładnie, kto wszystko wysyła pocztę w imieniu jego domeny.

Krok 1: inwentaryzacja

SPF działa tylko wtedy, gdy wszyscy nadawcy są w nim uwzględnieni. Jeśli pominą Państwo jednego, jego poczta trafi do spamu albo zostanie odrzucona, gdy tylko zaostrzą Państwo DMARC. Prosimy przejrzeć poniższą listę. W przeciętnej małej firmie szybko znajdą Państwo pięć lub sześć takich nadawców:

Dwa dobre sposoby, aby ich znaleźć:

1. Odczytanie nagłówków. Proszę wysłać z każdego systemu wiadomość do siebie (fakturę, przypomnienie hasła, testowy newsletter) i sprawdzić w nagłówkach pola Return-Path oraz Authentication-Results (lekcja 1.5). Widać tam, przez jaką domenę i jaki serwer wiadomość przyszła.
2. Raporty DMARC. Proszę ustawić DMARC na p=none z adresem do raportów (lekcja 4.4). Po kilku tygodniach zobaczą Państwo w raportach (lekcja 4.5) każdy serwer, który wysyłał pocztę w imieniu Państwa domeny, również ten, o którym Państwo zapomnieli. To najbardziej wiarygodna metoda inwentaryzacji.

Nie każda usługa powinna znaleźć się w Państwa SPF

To częste źródło błędów. SPF sprawdza nadawcę koperty (Return-Path), a nie adres z pola Od. Wiele usług newsletterowych i wysyłkowych wysyła wiadomości z Return-Path na własnej domenie, na przykład bounce-123@mail.mailer.example. Odbiorca sprawdza wtedy rekord SPF domeny mailer.example, a nie Państwa domeny. Dodanie include takiej usługi do Państwa rekordu nie daje wtedy żadnego efektu, poza kosztem jednego wyszukiwania.

To, czego taka usługa rzeczywiście potrzebuje, aby przejść przez DMARC, to podpis DKIM z Państwa domeną (lekcja 4.3) lub własna subdomena Return-Path należąca do Państwa (na przykład bounce.example.com jako CNAME do tej usługi). Proszę więc sprawdzić w instrukcji usługi, czego ona wymaga. Jeśli mówi „dodaj include: do swojego SPF”, proszę to zrobić. Jeśli mówi tylko „utwórz te rekordy CNAME dla DKIM i domeny zwrotów”, nic nie trzeba zmieniać w głównym rekordzie. Moduł 7 omawia to szerzej.

Krok 2: jeden rekord i dokładne liczenie

Wszyscy nadawcy trafiają do jednego rekordu. Załóżmy, że inwentaryzacja wykazała: serwer pocztowy dostawcy hostingu, Microsoft 365 dla kilku pracowników, program księgowy oraz helpdesk. Wtedy rekord może wyglądać tak:

example.com.  3600  IN  TXT  "v=spf1 a mx include:spf.hosting.example include:spf.protection.outlook.com include:_spf.boekhoud.example include:mail.helpdesk.example ~all"

Ile to wyszukiwań? Proszę policzyć każde a, mx, include, exists, ptr i redirect, a następnie policzyć też wszystko, co znajduje się w rekordach za każdym include:

Przy 11 odbiorca zwraca permerror: cały rekord SPF przestaje się wtedy liczyć, dla żadnego nadawcy. Poczta z Państwa własnego serwera pocztowego jest więc oceniana gorzej, bo helpdesk kosztuje trzy wyszukiwania. Problem polega też na tym, że rekord może dziś mieć wartość 9, a jutro 11, bez żadnej zmiany z Państwa strony, ponieważ jakaś usługa rozbudowuje swój własny rekord.

Dodatkowo: maksymalnie dwa puste wyszukiwania

RFC 7208 wprowadza również pojęcie void lookups: wyszukiwań, które niczego nie zwracają (nazwa nie istnieje albo nie ma rekordu SPF ani adresowego). Więcej niż dwa takie wyszukiwania również prowadzą do permerror. Dzieje się tak najczęściej przy starych includeach usług, których Państwo już nie używają i które usunęły swój rekord, albo przy a: wskazującym na serwer, który już nie istnieje. Warto więc regularnie porządkować rekord.

Krok 3: powrót poniżej dziesięciu

Jeśli są Państwo powyżej dziesięciu, istnieją cztery rozwiązania, od najlepszego do najmniej zalecanego:

1. Proszę usunąć to, co niepotrzebne. Usługi, z których Państwo już nie korzystają. Usługi wysyłające z własnym Return-Path (patrz wyżej), które w ogóle nie powinny znajdować się w Państwa SPF. a, jeśli Państwa strona sama nie wysyła poczty. mx, jeśli Państwa MX wskazuje na usługę, która już jest uwzględniona przez include w rekordzie.
2. Proszę skorzystać z subdomeny. Niech usługa wysyła z adresu nieuws.example.com albo factuur.example.com. Taka subdomena otrzyma własny rekord SPF zawierający tylko tę usługę i nie liczy się do limitu dziesięciu Państwa domeny głównej. Uwierzytelnianie (alignment) w DMARC (lekcja 4.4) domyślnie działa też dla subdomen.
3. Proszę używać ip4: i ip6: dla własnych stałych serwerów. One nie kosztują żadnego wyszukiwania. Proszę robić to wyłącznie dla adresów, którymi Państwo sami zarządzają i które się nie zmieniają.
4. Flattening (zastąpienie wszystkich includów adresami IP, które się aktualnie za nimi kryją). To sprowadza liczbę wyszukiwań do zera, ale rekord przestaje być zgodny z rzeczywistością, gdy tylko jakaś usługa zmieni swoje adresy, a duże usługi robią to regularnie. Proszę stosować to rozwiązanie wyłącznie z narzędziem, które aktualizuje je automatycznie, a najlepiej wcale.

redirect czy include?

redirect= oznacza: użyj rekordu SPF tamtej innej domeny zamiast tego rekordu. Kosztuje jedno wyszukiwanie, tak jak include. Jest to przydatne, gdy mają Państwo wiele domen, które powinny mieć dokładnie taką samą politykę: v=spf1 redirect=_spf.example.com na każdej domenie, a rzeczywisty rekord w jednym miejscu. Rekord z redirect= nie może zawierać all, ponieważ wtedy redirect zostaje zignorowany. Gmail sam z tego korzysta: domena gmail.com ma rekord v=spf1 redirect=_spf.google.com.

Krok 4: ~all czy -all?

Zalecenie tego kursu, zgodne z kursem DNS:

• Proszę zacząć od ~all (softfail). Poczta z serwera, którego nie ma w rekordzie, jest uznawana za podejrzaną, ale zwykle nie zostaje od razu odrzucona. Jeśli zapomną Państwo o jakimś nadawcy, szkoda jest ograniczona.
• Proszę przejść na -all (fail), gdy mają Państwo pewność, że wszyscy nadawcy są uwzględnieni, na przykład po kilku tygodniach analizy raportów DMARC, gdy nie pojawiają się już nieznane źródła.

W połączeniu z DMARC różnica jest mniejsza, niż się często sądzi. DMARC podejmuje decyzję na podstawie zasady „SPF lub DKIM zakończone sukcesem i uwierzytelnione (aligned)”. Softfail dla DMARC to po prostu „niepowodzenie”. Prawdziwa ochrona wynika więc z surowej polityki DMARC, a nie z -all. Niektórzy odbiorcy odrzucają wiadomość już przy -all, jeszcze przed oceną DMARC; to kolejny powód, by wybierać -all dopiero wtedy, gdy rekord jest naprawdę kompletny.

Domena, która nigdy nie wysyła poczty

Mają Państwo domeny, które nigdy nie wysyłają poczty (starą nazwę marki, domenę na literówkę)? Proszę zabezpieczyć je przed nadużyciem w ten sposób:

example.org.         IN  TXT  "v=spf1 -all"
_dmarc.example.org.  IN  TXT  "v=DMARC1; p=reject"
example.org.         IN  MX   0 .

Tutaj -all jest od razu właściwym wyborem: nikt nie ma prawa wysyłać poczty. Ostatnia linia to null MX (RFC 7505): „ta domena nie odbiera poczty”. Domena example.com ma skonfigurowane dokładnie to samo.

W praktyce: jak to wygląda w panelu

W pakiecie hostingowym WebOké domyślnie znajduje się rekord v=spf1 a mx include:webawere.nl ~all. Gdy dodają Państwo nową usługę, modyfikują Państwo ten rekord (w DirectAdmin: DNS Management, ikona ołówka przy rekordzie SPF, pole Dołącz domenę; w Moim WebOké: pomocnik SPF na karcie DNS). Proszę zostawić include:webawere.nl tak długo, jak długo Państwa poczta lub strona korzysta z tych serwerów. U innych dostawców domyślny include nazywa się inaczej, ale zasada jest taka sama: uzupełniać istniejący rekord, a nie tworzyć drugi.

Podsumowanie

• Proszę najpierw sporządzić inwentaryzację wszystkich nadawców; pomocne są w tym raporty DMARC i nagłówki wiadomości.
• Usługa z własnym Return-Path nie powinna znajdować się w Państwa SPF; potrzebuje ona DKIM z Państwa domeną.
• Proszę liczyć rekurencyjnie: każde include, a, mx, exists, ptr i redirect, również wewnątrz includów. Powyżej dziesięciu, lub przy więcej niż dwóch pustych wyszukiwaniach, występuje permerror.
• Proszę wrócić poniżej dziesięciu poprzez porządkowanie i korzystanie z subdomen; flattening tylko z automatycznym utrzymaniem.
• Proszę zacząć od ~all, przejść na -all, gdy mają Państwo pewność. Domeny, które nigdy nie wysyłają poczty: -all, DMARC reject i null MX.

Quiz

Zadanie

Zadanie Z4.2: Rekurencyjne zliczanie SPF dla Państwa domeny. Proszę wpisać własną domenę (lub sidn.nl, jeśli nie mają Państwo własnej domeny). Najpierw proszę samodzielnie policzyć, ile wyszukiwań DNS kosztuje rekord SPF, łącznie ze wszystkim wewnątrz includów, i wpisać tę liczbę razem z zakończeniem rekordu (~all, -all, ?all lub +all). Program policzy to na żywo, uwzględniając również puste wyszukiwania, i pokaże całe drzewo zależności.

Zadanie O4.2: Państwa inwentaryzacja nadawców. Na podstawie tabeli z tej lekcji proszę sporządzić listę wszystkich systemów wysyłających pocztę w imieniu Państwa domeny. Przy każdym proszę zaznaczyć: przez jaki serwer lub usługę, czy powinien znajdować się w Państwa SPF (własny Return-Path czy nie), oraz czy podpisuje wiadomości DKIM z Państwa domeną. Proszę wysłać z co najmniej dwóch systemów testową wiadomość do siebie i zanotować z nagłówków domenę Return-Path oraz domenę DKIM (d=).

Polecane materiały

Kroki opisane w tych artykułach dotyczą paneli WebOké; u innych dostawców działa to w podobny sposób.

• Bezpłatny kurs DNS 4.3: SPF: kto może wysyłać wiadomości w imieniu Państwa domeny?
• Instrukcja DirectAdmin 5.7: Ustawianie i uzupełnianie SPF
• Jak działa rekord SPF w DNS?
• Dodawanie lub zmiana rekordu SPF w DirectAdmin
• Podręcznik WebOké 5.5: Pomocnicy DNS: MX, SPF, DMARC, CAA i SRV
• RFC 7208 (SPF), paragraf 4.6.4 (limity) i 6.1 (redirect); RFC 7505 (null MX)