SPF permerror – jak naprawić błąd „too many DNS lookups”

Co oznacza ten błąd

Widzisz go w narzędziu do sprawdzania domeny, w raporcie DMARC albo w nagłówku wiadomości: spf=permerror, często z dopiskiem w rodzaju „too many DNS lookups”. permerror oznacza, że serwer odbiorcy w ogóle nie zdołał ocenić Twojego rekordu SPF – nie chodzi o to, że serwer nadawczy nie był uprawniony, tylko o to, że sam rekord jest zepsuty. Dla DMARC to po prostu „SPF nie przeszedł” i dotyczy to każdej wiadomości, także tych z poprawnie wpisanych serwerów.

Wiadomości, które mają też ważny, wyrównany podpis DKIM, nadal przechodzą DMARC – dlatego ten problem potrafi pozostać niezauważony przez wiele miesięcy. Ale każdy nadawca, który opiera się wyłącznie na SPF, i każdy serwer, który ocenia SPF osobno, odczuje skutki. Ten poradnik wchodzi głębiej niż ogólny poradnik o SPF: co dokładnie się liczy, jak to policzyć i jak zejść poniżej limitu.

Dwa limity z RFC 7208

Oba limity określa sekcja 4.6.4 RFC 7208, czyli specyfikacji SPF:

• 10 elementów wymagających zapytań DNS. Mechanizmy include, a, mx, ptr i exists oraz modyfikator redirect mogą łącznie wystąpić najwyżej 10 razy podczas jednej oceny SPF. Przekroczenie tego limitu musi dać wynik permerror.
• 2 puste zapytania („void lookups”). To zapytania DNS, które nie zwracają żadnego rekordu – albo „taka nazwa nie istnieje” (NXDOMAIN), albo „nazwa istnieje, ale nie ma rekordu tego typu”. Serwery powinny dopuszczać najwyżej dwa; trzecie daje permerror.

Limity istnieją po to, żeby jedna wiadomość nie mogła zmusić serwera odbiorcy do wykonania dziesiątek zapytań DNS – inaczej SPF stałby się narzędziem do zalewania serwerów DNS ruchem. Traktuj je jako twarde granice: serwer zgodny z RFC zwraca permerror w chwili ich przekroczenia, a nie wiesz, które serwery są bardziej pobłażliwe.

Co się liczy, a co nie

Samo pobranie rekordu SPF Twojej domeny nie jest elementem rekordu i się nie liczy; pobranie każdego rekordu dołączanego to właśnie to, za co liczy się include:. Dwie rzeczy są często źle rozumiane:

• Zagnieżdżone include się sumują. include: nie wkleja treści cudzego rekordu do Twojego, ale jego ocena wykonuje elementy tamtego rekordu – więc dostawca, którego rekord SPF zawiera trzy kolejne include, kosztuje Cię cztery zapytania, a nie jedno.
• Include domeny bez rekordu SPF to osobny permerror, niezależnie od liczby zapytań. Tak dzieje się, gdy dostawca wycofa starą nazwę hosta SPF, a Ty wciąż ją dołączasz.

„Ale przecież dla części wiadomości działało”

Limit dotyczy zapytań wykonanych w trakcie oceny, a ocena kończy się na pierwszym pasującym mechanizmie. Wiadomość z serwera wpisanego na początku rekordu może zostać zaakceptowana, zanim w ogóle dojdzie do jedenastego zapytania, a wiadomość z serwera wpisanego na końcu – nie. To sprawia, że rekord ponad limitem jest gorszy, a nie lepszy: zawodzi w nieprzewidywalny sposób. Licz najgorszy przypadek – każdy element, każde zagnieżdżone include – i utrzymuj tę liczbę poniżej 10.

Jak policzyć zapytania

Zacznij od własnego rekordu, a potem podążaj za każdym include: i redirect= i licz elementy w każdym rekordzie, do którego dotrzesz. Oto przykładowa domena korzystająca z dwóch usług:

firma.pl.  TXT  "v=spf1 mx include:_spf.crm.example include:spf.newsletter.example ~all"

_spf.crm.example.         TXT  "v=spf1 include:_s1.crm.example include:_s2.crm.example -all"
_s1.crm.example.          TXT  "v=spf1 ip4:198.51.100.0/24 -all"
_s2.crm.example.          TXT  "v=spf1 ip4:203.0.113.0/24 -all"
spf.newsletter.example.   TXT  "v=spf1 a include:servers.newsletter.example ~all"
servers.newsletter.example. TXT "v=spf1 ip6:2001:db8:100::/48 -all"

Siedem to dziś bezpieczny wynik, ale dostawcy zmieniają swoje rekordy bez uprzedzenia – jedno dodatkowe include w _spf.crm.example i domena ma już osiem. Zostaw sobie zapas. Ręczne liczenie poleceniem dig TXT nazwa +short działa, ale jest żmudne; narzędzie do sprawdzania domeny przechodzi całe drzewo include za Ciebie, pokazuje, ile zapytań zużywa każdy rekord, liczy puste zapytania i wskazuje include prowadzące do domen bez rekordu SPF.

Jak zejść poniżej limitu

1. Usuń to, z czego już nie korzystasz

Zwykle winna jest historia: narzędzie do newsletterów porzucone dwa lata temu, testowy CRM, poczta firmy hostingowej, z której nikt nie korzystał. Jeśli nie masz pewności, czy dana usługa wciąż wysyła pocztę z Twojej domeny, zajrzyj do zbiorczych raportów DMARC – widać w nich, z jakich adresów IP wychodzi poczta z Twoją domeną. Usługa, której adresy nigdy się tam nie pojawiają, to kandydat do usunięcia.

2. Zastąp a, mx i ptr wpisami ip4: i ip6:

a i mx są wygodne, ale każdy kosztuje zapytanie, a mx bywa po prostu błędny: serwery, które odbierają Twoją pocztę, niekoniecznie są tymi, które ją wysyłają – przy hostowanej poczcie zwykle nie są. Dla serwerów, które utrzymujesz sam, wpisz ich adresy przez ip4: i ip6:, które nic nie kosztują. ptr usuń bez wahania.

3. Sprawdź, które usługi naprawdę muszą być w rekordzie

SPF sprawdza domenę nadawcy koperty (MAIL FROM, widoczny jako Return-Path), a nie adres From:. Wiele usług wysyłkowych używa jako nadawcy koperty własnej domeny albo hostowanej przez siebie subdomeny Twojej domeny do obsługi zwrotek. Przy ich poczcie rekord SPF Twojej domeny głównej w ogóle nie jest sprawdzany, więc ich include zużywa zapytanie na darmo. Otwórz wiadomość wysłaną przez daną usługę i zajrzyj do nagłówka Return-Path: jeśli nie ma w nim Twojej domeny, include nic tej poczcie nie daje. Wyrównanie DMARC zapewnia wtedy DKIM – upewnij się, że usługa podpisuje wiadomości Twoją domeną.

4. Przenieś nadawców do subdomen

Każda nazwa ma własny rekord SPF z własną pulą 10 zapytań. Wysyłaj newslettery z newsletter.firma.pl, powiadomienia z narzędzia korzystającego z mail.firma.pl, a rekord każdej subdomeny niech dołącza tylko usługi, które jej faktycznie używają. Przy okazji oddzielasz reputację poczty masowej od codziennej korespondencji. Pamiętaj, że subdomeny nie dziedziczą SPF: każda, która występuje jako nadawca koperty, potrzebuje własnego rekordu.

5. Usuń duplikaty

Dwa include tego samego dostawcy – stara i nowa nazwa hosta albo wariant regionalny obok globalnego – to częsta pamiątka po migracjach. Zostaw ten, który dostawca obecnie podaje w dokumentacji.

Spłaszczanie SPF – możliwe, ale ryzykowne

„Spłaszczanie” (flattening) polega na zastąpieniu include adresami IP, na które w danej chwili wskazują – wtedy nie zużywają zapytań. Działa, ale ma swoją cenę:

• Po cichu się dezaktualizuje. Dostawcy dodają i zmieniają adresy nadawcze, kiedy tylko potrzebują. Twoja spłaszczona kopia za tym nie nadąża, a poczta z nowych adresów zaczyna nie przechodzić SPF bez żadnego sygnału po Twojej stronie.
• Rekordy robią się długie. Duzi dostawcy mają wiele zakresów adresów. RFC 7208 (sekcja 3.4) zaleca, żeby odpowiedzi SPF mieściły się w 512-bajtowej odpowiedzi DNS, a pojedynczy ciąg w rekordzie TXT może mieć najwyżej 255 znaków, więc długie listy trzeba dzielić na kilka ciągów.
• Automatyczne usługi spłaszczania aktualizują listę za Ciebie – ale wtedy dołączasz ich nazwę hosta, czyli powierzasz komuś trzeciemu listę serwerów uprawnionych do wysyłania poczty w imieniu Twojej domeny.

Spłaszczaj tylko to, nad czym masz kontrolę – adresy własnych serwerów – a dostawców zostaw jako include. Jeśli musisz spłaszczyć dostawcę, zautomatyzuj to i regularnie sprawdzaj wynik.

Jak pozbyć się pustych zapytań

Puste zapytania biorą się z elementów, które prowadzą donikąd: include: domeny, która już nie istnieje, a: dla usuniętej nazwy hosta, mx dla domeny bez rekordów MX. Jedno czy dwa niczego nie psują, ale to oznaki zaniedbania – usuń je, zanim trzecie zamieni cały rekord w permerror.

Po poprawce

Opublikuj skrócony rekord jako jeden rekord TXT – domena może mieć tylko jeden rekord zaczynający się od v=spf1 – odczekaj TTL starego rekordu i sprawdź ponownie. Potem wyślij wiadomość na zewnętrzną skrzynkę i upewnij się, że nagłówek Authentication-Results zawiera spf=pass. Jeśli wysyłasz pocztę przez AnyMail, jego część Twojego rekordu to jedno include:anymail.tech; ten rekord zawiera obecnie wyłącznie adresy IP, więc kosztuje jedno zapytanie.