Rekord SPF – czym jest i jak go poprawnie skonfigurować

Do czego służy SPF

SPF (Sender Policy Framework, RFC 7208) pozwala serwerowi odbiorcy zadać proste pytanie: czy serwer, który właśnie przekazuje mi tę wiadomość, może wysyłać pocztę w imieniu tej domeny? Odpowiedź znajduje się w rekordzie TXT, który publikujesz w DNS. Serwer odbiorcy pobiera rekord domeny z adresu nadawcy koperty (adres MAIL FROM, który trafia potem do nagłówka Return-Path), porównuje z nim adres IP połączenia i otrzymuje wynik: pass, fail, softfail i tak dalej.

Wynikają z tego dwie ważne rzeczy. Po pierwsze, SPF sprawdza nadawcę koperty, a nie adres From: widoczny w programie pocztowym – powiązanie obu adresów to zadanie wyrównania (alignment) w DMARC. Po drugie, SPF nie przetrwa przekierowania wiadomości, bo serwer przekazujący nie figuruje na Twojej liście. Dlatego SPF zawsze warto łączyć z podpisem DKIM, który przekierowanie przetrwa.

Składnia rekordu SPF

Rekord SPF to rekord TXT ustawiony na samej domenie (w panelach DNS zwykle oznaczanej jako @). Zaczyna się od znacznika wersji, po którym następują mechanizmy sprawdzane od lewej do prawej, aż któryś pasuje:

firma.pl.  3600  IN  TXT  "v=spf1 ip4:192.0.2.10 include:_spf.dostawca.example ~all"

Przed mechanizmem może stać kwalifikator: + pass (domyślny), - fail, ~ softfail i ? neutral. W praktyce ma on znaczenie tylko przy końcowym all. Mechanizm ptr jest przestarzały i nie należy go używać.

~all czy -all?

Zakończenie rekordu decyduje o tym, co się dzieje z pocztą z serwerów, których nie wymieniłeś. -all (fail) oznacza „odrzuć wszystko inne”, a ~all (softfail) – „traktuj wszystko inne jako podejrzane”. Oba warianty są w porządku i oba są nieporównanie lepsze niż brak rekordu SPF.

• Gdy masz już egzekwującą politykę DMARC, duzi operatorzy podejmują ostateczną decyzję na podstawie DMARC, więc różnica między ~all a -all jest w praktyce niewielka.
• Niektóre serwery odrzucają wiadomość z wynikiem SPF fail jeszcze przed sprawdzeniem DKIM i DMARC – możesz wtedy stracić poprawnie przekierowaną pocztę. Dlatego wielu dostawców, w tym AnyMail, generuje ~all.
• Jeśli domena w ogóle nie wysyła poczty, opublikuj v=spf1 -all, żeby nikt nie mógł się pod nią podszyć.
• Nigdy nie używaj +all (każdy może wysyłać jako Ty) ani ?all (brak opinii) – przekreślają sens całego rekordu.

Limit 10 zapytań DNS

Żeby sprawdzanie SPF było tanie, serwer odbiorcy wykona najwyżej 10 zapytań DNS podczas oceny Twojego rekordu. Liczy się każde include:, a, mx, exists: i redirect= – również te zagnieżdżone w rekordach, które dołączasz. Po przekroczeniu limitu wynikiem jest permerror, który większość serwerów traktuje jak niepowodzenie. Osobna reguła dopuszcza najwyżej dwa zapytania, które nic nie zwracają („void lookups”).

Jak zmieścić się w limicie:

• Usuń wpisy usług, z których już nie korzystasz – najczęściej to stare narzędzia do newsletterów albo CRM.
• Dla własnych serwerów używaj ip4:/ip6: – nie zużywają zapytań.
• Pocztę masową lub marketingową wysyłaj z subdomeny (np. newsletter.firma.pl) z osobnym rekordem SPF. Każda nazwa ma własny rekord, a zapytania subdomeny nie obciążają domeny głównej.
• Uważaj na „spłaszczanie SPF” (zastępowanie include: adresami IP, na które wskazuje): działa do czasu, aż dostawca zmieni adresy – a wtedy Twoja poczta zaczyna po cichu nie przechodzić weryfikacji.

Tylko jeden rekord SPF w domenie

Domena może mieć tylko jeden rekord TXT zaczynający się od v=spf1. Dwa takie rekordy dają permerror i to najczęstszy błąd: przy dodawaniu nowego dostawcy ktoś tworzy drugi rekord zamiast zmodyfikować istniejący. Jeśli wysyłasz pocztę przez kilka usług, połącz je w jednym rekordzie:

firma.pl.  TXT  "v=spf1 include:_spf.dostawca-a.example ~all"
firma.pl.  TXT  "v=spf1 include:_spf.dostawca-b.example ~all"

firma.pl.  TXT  "v=spf1 include:_spf.dostawca-a.example include:_spf.dostawca-b.example ~all"

Inne rekordy TXT pod tą samą nazwą (np. tokeny weryfikujące domenę) nie przeszkadzają – liczą się tylko te zaczynające się od v=spf1.

Najczęstsze błędy w rekordach SPF

Pominięty nadawca

Faktury z programu księgowego, powiadomienia ze sklepu internetowego, formularz kontaktowy na stronie – wszystko, co wysyła pocztę z Twoją domeną w adresie nadawcy koperty, musi być ujęte w rekordzie, inaczej nie przejdzie SPF.

Oczekiwanie, że subdomeny odziedziczą rekord

SPF nie jest dziedziczony. sklep.firma.pl czy mail.firma.pl potrzebują własnego rekordu, jeśli występują jako nadawcy koperty.

Długie rekordy i cudzysłowy

Pojedynczy ciąg znaków w rekordzie TXT może mieć najwyżej 255 znaków. Dłuższy rekord SPF trzeba podzielić na kilka ciągów w cudzysłowach w obrębie tego samego rekordu – serwery sklejają je bez dodawania spacji, więc dziel rekord między mechanizmami i zostaw spację na końcu pierwszej części. Większość paneli DNS robi to automatycznie; szczegóły znajdziesz w poradniku jak dodać rekordy DNS u rejestratora.

Literówki, które po cichu psują rekord

v=spf1 musi być na samym początku rekordu, mechanizmy oddziela pojedyncza spacja, a po include: podaje się nazwę domeny, a nie adres URL. Rekordu typu SPF (typ 99) nikt już nie czyta – SPF publikuje się wyłącznie jako TXT.

Jak sprawdzić rekord SPF

Sprawdź rekord poleceniem dig TXT firma.pl +short (w Windows: nslookup -type=TXT firma.pl) albo za pomocą narzędzia do sprawdzania domeny. Potem wyślij wiadomość na zewnętrzną skrzynkę i otwórz jej oryginalne nagłówki: gdy wszystko działa, nagłówek Authentication-Results zawiera spf=pass. Zmiana w DNS może docierać do wszystkich serwerów tak długo, jak wynosi TTL rekordu, więc przed ponownym testem odczekaj chwilę.

Gdy podłączasz domenę do AnyMail, panel pokazuje dokładnie, jaki rekord SPF opublikować, i sam go sprawdza. Jeśli masz już rekord SPF dla innej usługi, dopisz do niego wartość AnyMail zamiast tworzyć drugi rekord.