Rekord SPF: czym jest, składnia i limit 10 zapytań DNS

Rekord SPF to pojedynczy wpis TXT w DNS domeny, który wymienia serwery uprawnione do wysyłania poczty z tej domeny w polu envelope sender. Odbiorca pobiera ten wpis, porównuje z nim adres IP łączącego się serwera i zwraca wynik: pass, fail, softfail albo neutral. Rekord uwierzytelnia ścieżkę wysyłki, a nie treść wiadomości, i nic nie mówi o adresie From, który widzi człowiek.

Ta różnica tłumaczy większość zgłoszeń SPF, z jakimi mamy do czynienia w analizowanych nagłówkach.

Rekord SPF to lista nadawców opublikowana w DNS

SPF oznacza Sender Policy Framework i jest opisany w RFC 7208. Rekord to wpis TXT w korzeniu domeny, zaczynający się od v=spf1. Minimalny przykład wygląda tak:

example.com.  IN  TXT  "v=spf1 ip4:203.0.113.10 include:_spf.provider.example ~all"

Czytamy go od lewej do prawej. Odbiorca sprawdza kolejne mechanizmy i zatrzymuje się na pierwszym dopasowaniu. Końcowy termin all obejmuje wszystko, co nie zostało wcześniej dopasowane.

Sprawdzana domena nie jest nagłówkiem From. To domena z polecenia SMTP MAIL FROM, czyli envelope sender albo Return-Path. Jeśli jest pusta, jak w przypadku odbić, odbiorca używa nazwy z polecenia HELO.

Mechanizmy ip4, ip6, a, mx, include i exists opisują, kto wysyła pocztę

Każdy termin jest mechanizmem, opcjonalnie z kwalifikatorem. Sześć z nich wystarcza prawie zawsze.

• ip4: i ip6: dopasowują konkretny adres albo zakres CIDR. Nie generują zapytań DNS.

• a dopasowuje rekordy A/AAAA domeny. Kosztuje jedno zapytanie.

• mx dopasowuje hosty z rekordów MX. Kosztuje jedno zapytanie plus po jednym na każdy host.

• include: dopasowuje wszystko, co pasuje do rekordu SPF innej domeny. Kosztuje jedno zapytanie plus wszystko, co jest w nim zagnieżdżone.

• exists: dopasowuje dowolny rekord A dla zbudowanej nazwy. Kosztuje jedno zapytanie.

• ptr dopasowuje odwrotną nazwę DNS łączącego się IP. Kosztuje zapytania, a RFC 7208 odradza jego użycie.

Kwalifikatory określają wynik, gdy termin pasuje. + oznacza pass i jest domyślny, - oznacza fail, ~ softfail, ? neutral. Zatem -all znaczy „odrzuć wszystko, czego nie ma na liście”, a ~all znaczy „przyjmij, ale oznacz”.

Gdy kontrolujemy adres, lepiej użyć ip4: albo ip6:. Nie generują zapytań i nie przestają działać, gdy zmienia się DNS obcej firmy.

Limit 10 zapytań DNS łamie prawdziwe rekordy

RFC 7208 ogranicza jedną ewaluację SPF do 10 terminów wywołujących zapytania DNS: include, a, mx, ptr, exists oraz modyfikator redirect. Zagnieżdżone include też się liczą. Powyżej 10 wynik to permerror, czyli trwałe niepowodzenie, a nie powrót do innego sprawdzenia.

Jest też drugi limit, o którym mówi się mniej. Zapytania, które zwracają pustą odpowiedź albo NXDOMAIN, to void lookups, a specyfikacja każe przerwać po dwóch. Nieaktualny include: wskazujący na dostawcę, z którego zrezygnowano rok temu, to void lookup, za który wciąż płacimy.

Zespoły zwykle trafiają w ten sufit w ten sposób. Google Workspace to jeden include. Dostawca transakcyjny to kolejny. Platforma marketingowa to jeden, ale w środku zagnieżdża trzy następne. Helpdesk, CRM i narzędzie do rozliczeń dokładają cztery. Przy takim zestawie jesteśmy na 11 bez żadnych nietypowych decyzji.

Awaria jest cicha. Poczta nadal wychodzi i część odbiorców ją dostarcza, ale SPF przestaje cokolwiek uwierzytelniać. Jeśli DMARC opiera się na wyrównaniu przez SPF, ta ścieżka znika, dopóki nie spłaszczy się rekordu albo nie usunie nadawców.

Trzy poprawki działają, w kolejności preferencji:

1. Usunąć nadawców, z których już nie korzystamy. Include'y warto sprawdzić względem raportów zbiorczych DMARC z ostatnich 90 dni.

2. Przenieść masowy ruch na subdomenę, na przykład mail.example.com, z własnym rekordem SPF i własnym budżetem 10 zapytań.

3. Spłaszczyć include'y do literalnych zakresów ip4:, ale tylko z automatyzacją. Dostawcy rotują adresy, a ręcznie spłaszczony rekord starzeje się bez żadnego alertu.

Publikujmy dokładnie jeden rekord SPF na domenę

Domena nie może publikować dwóch rekordów SPF. Jeśli odbiorca znajdzie dwa wpisy v=spf1, wynik to permerror, tak samo jak przy przekroczeniu limitu. Dzieje się tak, gdy jedna osoba dodaje rekord dla nowego narzędzia, a druga ma już swój.

Poprawka jest mechaniczna. Scalmy terminy w jeden rekord, z jednym v=spf1 na początku i jednym all na końcu. Wszystko, co dokumentacja dostawcy każe dodać, trafia do istniejącego rekordu jako kolejny include:, nigdy jako nowy wpis TXT.

Dwie mniejsze pułapki. Ciąg TXT dłuższy niż 255 znaków trzeba podzielić na kilka cytowanych fragmentów w obrębie tego samego rekordu, co większość dostawców DNS robi automatycznie. Całą odpowiedź warto trzymać poniżej około 450 bajtów, bo większe odpowiedzi mogą przejść z UDP na TCP, a niektóre resolvery obsługują to źle.

Softfail czy hardfail: wybór zależy od tego, co widzimy

Termin all to deklaracja polityki, a popularna rada („używaj -all”) pomija to, co naprawdę ma znaczenie. Twarde odrzucenie jest bezpieczne tylko wtedy, gdy znamy wszystkich prawowitych nadawców.

Nasza zasada kciuka, wynikająca z czytania nagłówków:

• ~all, dopóki inwentaryzujemy nadawców albo gdy wiadomości są przekazywane i nie kontrolujemy ścieżki.

• -all, gdy raporty DMARC pokazują, że wszystkie prawowite źródła przechodzą przez kilka tygodni.

• Nigdy +all, które autoryzuje cały internet, i nigdy ?all na domenie produkcyjnej.

W praktyce różnica jest mniejsza, niż się wydaje. Więksi odbiorcy traktują SPF jako jeden sygnał wśród kilku, a przy polityce DMARC decyduje werdykt DMARC. Mimo to -all na niepełnym rekordzie to sposób, w jaki gubi się faktury.

SPF psuje się przy przekierowaniach i to jest zamierzone

SPF weryfikuje IP, które połączyło się z serwerem odbiorcy. Gdy wiadomość jest przekazywana, rozsyłana przez listę dyskusyjną albo przepuszczana przez usługę aliasów, łączącym się IP jest adres przekazującego, a nie nasz. Sprawdzenie SPF nie przechodzi, mimo że nie zrobiliśmy nic złego.

W ramach SPF tego nie da się naprawić. Dlatego obok niego istnieje DKIM: podpis przechodzi przez kolejne przeskoki, lista adresów IP już nie. Domena polegająca wyłącznie na SPF będzie widziała błędy uwierzytelnienia przy każdej przekazanej wiadomości.

Z tego samego powodu SPF sam w sobie nie spełnia DMARC dla poczty przekazywanej. Trzeba zakładać, że DKIM przeniesie te wiadomości.

Wyrównanie SPF: przejście nie oznacza zgodności z domeną From

Wiadomość może przejść SPF i nadal nie przejść DMARC. DMARC wymaga, by domena, która przeszła SPF, czyli domena Return-Path, zgadzała się z widoczną domeną From. Wielu współdzielonych dostawców domyślnie używa własnej domeny odbić, więc SPF przechodzi dla provider-mail.net i nic nie mówi o example.com.

Warto to sprawdzić w surowych nagłówkach. W linii Authentication-Results trzeba spojrzeć na smtp.mailfrom=. Jeśli nie jest to nasza domena albo jej subdomena, SPF przechodzi, a nam nie pomaga.

Rozwiązaniem jest własny Return-Path na subdomenie, co obsługuje większość poważnych nadawców. Postmark, Resend, Mailgun i SendGrid dokumentują taką konfigurację, choć nie zawsze jest ona włączona domyślnie.

Skrzynki odbiorcze oczekują uwierzytelnienia od każdego nadawcy

Od lutego 2024 roku Google wymaga od wszystkich nadawców uwierzytelnienia przez SPF lub DKIM, a nadawcy wysyłający do Gmaila ponad 5000 wiadomości dziennie muszą mieć SPF, DKIM i DMARC. Szczegóły znajdują się we wskazówkach Google dla nadawców poczty. Yahoo ustanowił podobne reguły w tym samym czasie.

To przesunęło SPF z kategorii „miło mieć” do warunku dostarczenia. Brakujący albo zepsuty rekord objawia się teraz odrzuceniami i trafianiem do spamu, a nie tylko niższą oceną reputacji.

Nasz wniosek po kilku latach analizy: reguły głównie łapią domeny bez żadnego uwierzytelnienia i nadawców z wysokim wskaźnikiem skarg na spam. Poprawny rekord SPF sam nie wprowadzi do skrzynki odbiorczej, ale brakujący będzie trzymał poza nią.

Sprawdzenie i naprawa rekordu SPF w czterech krokach

Wykonujmy je w tej kolejności i sprawdzajmy ponownie po każdej zmianie DNS.

1. Sprawdzić obecny rekord. Uruchomić dig +short TXT example.com i znaleźć wpis zaczynający się od v=spf1. Jeśli są dwa, trzeba je scalić.

2. Policzyć zapytania. Dodać include, a, mx, exists, redirect oraz wszystko zagnieżdżone w include'ach. Jeśli wynik to 8 lub więcej, zaplanować sprzątanie od razu, a nie przy jedenastym zapytaniu.

3. Spisać prawdziwych nadawców. Użyć raportów zbiorczych DMARC albo nagłówków Authentication-Results z testowych wysyłek. Dodawać tylko źródła, które się pojawiają.

4. Wysłać test i przeczytać nagłówek. Wynik powinien brzmieć spf=pass, a smtp.mailfrom powinien należeć do naszej domeny.

Zmiany DNS propagują się z opóźnieniem, a TTL obecnego rekordu decyduje, jak długo przetrwają stare odpowiedzi. Na jeden dzień przed planowaną zmianą warto obniżyć TTL do 300 sekund.

Przykładowy rekord dla firmy SaaS z trzema nadawcami

Weźmy produkt wysyłający z Google Workspace, od dostawcy transakcyjnego i z helpdesku. Czysty rekord wygląda tak:

example.com.  IN  TXT  "v=spf1 include:_spf.google.com include:spf.transactional.example include:spf.helpdesk.example -all"

To trzy include'y, a każdy ukrywa własne zagnieżdżone zapytania. Trzeba je policzyć przed publikacją, bo widoczna długość rekordu nic nie mówi o rzeczywistym budżecie. Rekord z trzema include'ami może już mieć 7 albo 8 zapytań.

Teraz warto podzielić według celu. Pocztę od ludzi zostawić na domenie głównej. Powiadomienia produktowe przenieść na notify.example.com z rekordem wskazującym wyłącznie dostawcę transakcyjnego. Rekord główny pozostaje krótki, subdomena dostaje własny budżet 10 zapytań, a problem z reputacją jednego strumienia nie ciągnie za sobą drugiego.

Podział ułatwia też czytanie raportów DMARC. Każdy strumień ma własną domenę Return-Path, więc błąd wskazuje jednego nadawcę, a nie cały stos podejrzanych.

Czego SPF nie zrobi

Nie zablokuje podszywania się pod adres From, bo nigdy nie patrzy na ten nagłówek. Niczego nie szyfruje. Nie powie, dlaczego wiadomość trafiła do spamu. I nie skaluje się poza budżet 10 zapytań bez stałej konserwacji.

Traktujmy go jako jeden z trzech rekordów publikowanych razem: SPF dla ścieżki wysyłki, DKIM dla integralności wiadomości, DMARC jako polityka łącząca je z domeną From. Jeśli mamy SPF i nic więcej, kolejnym konkretnym krokiem jest opublikowanie rekordu DMARC z p=none i czytanie raportów przez dwa tygodnie.