Definicja
Rekord SPF (rekord Sender Policy Framework) to rekord zasobu DNS TXT publikowany w publicznej strefie DNS domeny, który wylicza adresy IP, prefiksy IPv6 i nazwy hostów serwerów pocztowych upoważnione do wysyłania email w imieniu tej domeny. Gdy odbierający serwer pocztowy akceptuje przychodzącą wiadomość, odpytuje DNS nadawcy o rekord SPF i porównuje łączący się adres IP z polityką. Jeśli IP nie jest wymieniony, serwer odbierający może oznaczyć wiadomość jako softfail, odrzucić ją wprost lub oznaczyć do dalszej oceny — w zależności od kwalifikatora polityki ustawionego przez właściciela domeny.
SPF zostało po raz pierwszy sformalizowane jako standard IETF w RFC 4408 (2006) i później zaktualizowane do bieżącej autorytatywnej specyfikacji w RFC 7208, opublikowanym przez Internet Engineering Task Force (IETF) w kwietniu 2014 roku. Jest to jeden z trzech komplementarnych standardów uwierzytelniania email obok DKIM (DomainKeys Identified Mail) i DMARC (Domain-based Message Authentication, Reporting, and Conformance).
Jak to działa
Proces oceny SPF obejmuje kilka sekwencyjnych kroków wykonywanych przez silnik SMTP odbierającego serwera pocztowego podczas fazy MAIL FROM uzgadniania SMTP.
Właściciel domeny publikuje rekord SPF TXT w DNS. Typowy rekord przestrzega tej składni: v=spf1 include:_spf.google.com ip4:203.0.113.5 ~all. Komponenty to: v=spf1 (identyfikator wersji), jeden lub więcej mechanizmów (include, ip4, ip6, a, mx, exists) oraz końcowy kwalifikator (+all, -all, ~all, ?all). Kwalifikator -all oznacza twardą porażkę — żaden serwer nie wymieniony wprost nie jest upoważniony. Kwalifikator ~all (softfail) przepuszcza wiadomość, ale odnotowuje rozbieżność polityki, powszechnie używany podczas okresów migracji.
Gdy wiadomość przybywa, odbierający MTA (Mail Transfer Agent) wyodrębnia domenę nadawcy koperty (adres MAIL FROM, zwany również adresem RFC5321.MailFrom) i wykonuje wyszukiwanie DNS TXT dla _spf.<domain> lub bezpośrednio na korzeniu domeny. Biblioteka SPF ocenia każdy mechanizm w kolejności, aż jeden się dopasuje lub osiągnięty zostanie limit dziesięciu wyszukiwań DNS (limit „SPF PermError” zdefiniowany w RFC 7208 sekcja 4.6.4). Wynik — Pass, Fail, SoftFail, Neutral, TempError lub PermError — jest wstawiany do nagłówka Received-SPF wiadomości i przekazywany do filtru spamu i każdego silnika polityki DMARC.
Krytyczne jest zauważenie, że SPF uwierzytelnia nadawcę koperty (MAIL FROM), a nie widoczny nagłówek From w treści wiadomości. To rozróżnienie oznacza, że samo SPF nie zapobiega fałszowaniu nazwy wyświetlanej w klientach email, dlatego wyrównanie DMARC — wymagające, aby wyniki SPF lub DKIM dopasowywały się do domeny RFC5322.From — jest niezbędne dla pełnej ochrony.
Gdzie się z tym spotkasz
Rekordy SPF pojawiają się w każdym kontekście, gdzie liczy się dostarczalność email i reputacja nadawcy. Infrastruktura email transakcyjnego obsługiwana przez usługi takie jak Amazon SES, SendGrid, Mailgun, Postmark i SparkPost wymaga, aby właściciele domen dodawali mechanizmy SPF include wskazujące na infrastrukturę wysyłkową dostawcy, zanim wiadomości przejdą kontrole uwierzytelniania.
Platformy konkursowe wysyłające emaile potwierdzające głos — w tym Woobox, ShortStack i niestandardowe systemy wykorzystujące Mailchimp Transactional (Mandrill) — polegają na tym, że domena nadawcy ma ważny rekord SPF. Dostawcy skrzynek pocztowych, w tym Google (Gmail), Microsoft (Outlook / Exchange Online Protection) i Yahoo Mail, oceniają SPF jako wejście do swoich algorytmów dostarczalności. Brakujący lub źle skonfigurowany rekord SPF znacząco zwiększa prawdopodobieństwo, że emaile potwierdzające zostaną po cichu dostarczone do folderów spam lub odrzucone całkowicie, powodując, że głosy pozostaną niepotwierdzone.
Panele hostingu DNS od dostawców takich jak Cloudflare, AWS Route 53, GoDaddy i Namecheap udostępniają edycję rekordów SPF TXT przez swoje interfejsy zarządzania. Narzędzia diagnostyczne, takie jak MXToolbox SPF Lookup, Google Admin Toolbox i SPF Surveyor od DMARCIAN, pozwalają właścicielom domen sprawdzać i walidować opublikowane rekordy.
Praktyczne przykłady
Platforma konkursowa wysyła emaile potwierdzenia głosu z [email protected]. Domena votes.example.com ma rekord SPF v=spf1 include:sendgrid.net -all. Gdy Gmail otrzymuje wiadomość potwierdzającą, jego przychodzący serwer SMTP odpytuje DNS o rekord SPF votes.example.com, rozszerza mechanizm include sendgrid.net i sprawdza łączący się IP względem upoważnionej listy serwerów SendGrid. Jeśli IP się dopasowuje, wynik SPF to Pass i wiadomość przechodzi do skrzynki odbiorczej. Gdyby domena nie miała rekordu SPF, filtr Gmaila traktowałby wiadomość jako nieuwierzytelnioną, redukując prawdopodobieństwo umieszczenia w skrzynce odbiorczej.
Konkurs regionalnej gazety zmienia dostawcę email transakcyjnego z Mailchimp na Amazon SES bez aktualizacji rekordu SPF. Emaile potwierdzające zaczynają zawodzić kontrole SPF w Microsoft Outlook i są kierowane do folderu hurtowego, powodując, że wyborcy przegapiają okno potwierdzenia. Administrator konkursu diagnozuje problem za pomocą MXToolbox, dodaje include:amazonses.com do rekordu SPF, a dostarczalność powraca w oknie propagacji DNS (zwykle 0–48 godzin w zależności od ustawień TTL).
Powiązane pojęcia
SPF to jeden z filarów trzy-standardowego stosu uwierzytelniania email: zobacz DKIM dla weryfikacji podpisu kryptograficznego oraz DMARC dla warstwy polityki, która działa na wynikach SPF i DKIM. Praktyczny wpływ na operacje konkursowe jest opisany w Email Confirmation Vote, gdzie dostarczalność wiadomości potwierdzającej jest najbardziej krytyczną zależnością operacyjną. BIMI (Brand Indicators for Message Identification), nowszy standard budujący na DMARC, pozwala zweryfikowanym nadawcom wyświetlać logo marki u wspierających dostawców skrzynek pocztowych — wyłaniający się sygnał zaufania nieomówiony tutaj.
