Wdrażaj i regularnie testuj SPF

Regularne wdrażanie i testowanie SPF pomaga utrzymać skuteczną ochronę przed podszywaniem się pod domenę.

Rola rekordu SPF w weryfikacji nadawcy

SPF, czyli Sender Policy Framework, pozwala właścicielowi domeny opublikować w systemie DNS informację o tym, jakie serwery mogą wysyłać pocztę w jej imieniu. Reguła jest zapisywana najczęściej jako rekord TXT, którego wartość zaczyna się od v=spf1. Serwer odbierający wiadomość odczytuje ten rekord i porównuje adres IP systemu nawiązującego połączenie z mechanizmami wskazanymi przez właściciela domeny. W praktyce SPF ogranicza możliwość skutecznego podszycia się pod domenę w polu koperty pocztowej, czyli w adresie używanym podczas polecenia SMTP MAIL FROM.

Wynik kontroli SPF może mieć między innymi wartości pass, fail, softfail, neutral, none, temperror albo permerror. Wynik pass oznacza, że adres IP został dopuszczony przez opublikowaną politykę. Fail wskazuje, że nadawca nie spełnia tej polityki, natomiast permerror zwykle oznacza błąd trwały, na przykład nieprawidłową składnię rekordu albo obecność więcej niż jednego rekordu SPF dla tej samej nazwy. SPF nie szyfruje wiadomości, nie podpisuje jej treści i nie gwarantuje, że osoba widoczna w nazwie nadawcy nie została podrobiona. Jest jednym z elementów kontroli poczty, a nie samodzielnym mechanizmem potwierdzającym tożsamość całej wiadomości.

Budowa polityki i kontrola źródeł wysyłki

Rekord SPF może zawierać adresy IPv4 i IPv6 za pomocą mechanizmów ip4 oraz ip6, a także wskazywać inne domeny przez include. Mechanizm a odwołuje się do adresów uzyskanych z rekordu A lub AAAA, a mx wykorzystuje adresy hostów wymienionych w rekordach MX. Przykładowa polityka v=spf1 ip4:203.0.113.25 -all dopuszcza wskazany adres IPv4 i odrzuca pozostałe źródła. Adres z zakresu dokumentacyjnego 203.0.113.0/24 jest przeznaczony do przykładów, więc w rzeczywistej konfiguracji trzeba użyć faktycznego, autoryzowanego adresu serwera.

Końcowy mechanizm, taki jak -all, ~all albo ?all, powinien wynikać ze znajomości wszystkich systemów wysyłających pocztę. Przed zaostrzeniem polityki należy uwzględnić firmową skrzynkę pocztową, formularze kontaktowe, systemy transakcyjne, narzędzia do wysyłki powiadomień i zewnętrzne platformy mailingowe. Nie wolno dodawać do SPF przypadkowych adresów tylko dlatego, że występują w nagłówku otrzymanej wiadomości. Trzeba ustalić, czy dany system rzeczywiście wysyła pocztę dla domeny oraz jaki adres domenowy znajduje się w polu MAIL FROM. Mechanizm include powinien wskazywać dokumentację dostawcy, ponieważ jego zawartość może być utrzymywana po stronie tej usługi.

Testowanie DNS, limitów i rzeczywistych wiadomości

Test powinien rozpocząć się od sprawdzenia rekordu TXT w publicznym DNS. W systemie Windows można użyć polecenia nslookup -type=TXT example.pl, a w systemach z narzędziem dig polecenia dig TXT example.pl. Wynik należy ocenić zarówno pod kątem składni, jak i kompletności. Dla jednej domeny nie powinno być kilku niezależnych rekordów SPF zaczynających się od v=spf1; wpisy trzeba połączyć w jedną politykę. Zmiana w DNS może być widoczna z różnym opóźnieniem zależnie od wartości TTL i pamięci podręcznej resolverów, dlatego test należy wykonać z więcej niż jednego niezależnego resolvera.

RFC 7208 ogranicza liczbę mechanizmów i modyfikatorów SPF powodujących wyszukiwania DNS do 10 podczas pojedynczej oceny. Zagnieżdżone rekordy include, mechanizmy mx, a, exists oraz przekierowania mogą szybko wyczerpać ten limit. Przekroczenie limitu skutkuje permerror, nawet jeśli każdy pojedynczy rekord wygląda poprawnie. Po publikacji zmian trzeba wysłać wiadomości testowe z każdego zatwierdzonego systemu i sprawdzić nagłówek Authentication-Results, w którym odbiorca może zapisać wynik w rodzaju spf=pass lub spf=fail. Należy także przetestować źródło nieautoryzowane, korzystając z kontrolowanego konta i bez wysyłania niechcianej korespondencji.

Powiązanie SPF z dostarczalnością i pracą serwisu

Regularne testowanie SPF jest szczególnie ważne po zmianie dostawcy poczty, adresu publicznego, usługi newsletterowej, konfiguracji formularza albo sposobu wysyłania powiadomień z aplikacji. Jeżeli uprawniony system nie został dopisany do polityki, jego wiadomości mogą otrzymywać wynik fail i być odrzucane lub kierowane do spamu. Z kolei zbyt szeroka reguła może przepuszczać nieautoryzowane źródła. Warto prowadzić listę usług wysyłających wiadomości, porównywać ją z rekordem DNS i okresowo analizować wyniki SPF rejestrowane przez odbiorców.

SPF działa na domenie użytej w kopercie SMTP, dlatego nie zawsze zabezpiecza widoczny adres w nagłówku From. Do oceny zgodności tych domen służy DMARC, a do kryptograficznego podpisywania wiadomości DKIM. Poprawny SPF nie zastępuje tych mechanizmów i nie naprawi błędnej reputacji adresu IP, konfiguracji DNS ani problemów z treścią wiadomości. Warszawskie Pogotowie Komputerowe zajmuje się profesjonalną naprawą laptopów, komputerów PC i ich podzespołów, a przy diagnostyce stanowiska może również sprawdzić lokalne ustawienia klienta poczty, działanie DNS oraz poprawność wysyłania wiadomości testowych.