SPF permerror

SPF permerror to trwały błąd weryfikacji wynikający z niepoprawnej składni rekordu SPF.

SPF permerror — czym jest ten błąd poczty elektronicznej

SPF permerror oznacza trwały błąd podczas odczytu albo interpretacji polityki SPF opublikowanej dla domeny nadawcy. SPF, czyli Sender Policy Framework, służy do sprawdzania, czy serwer wysyłający wiadomość jest uprawniony do korzystania z określonej domeny w adresie nadawcy. Informacja o takich uprawnieniach znajduje się w rekordzie TXT zapisanym w systemie DNS. Jeżeli rekord jest zbudowany niezgodnie z regułami SPF, mechanizm weryfikujący nie może go poprawnie przetworzyć. W takiej sytuacji nie chodzi wyłącznie o brak dopasowania adresu IP do listy dozwolonych serwerów, lecz o problem z samą konstrukcją polityki.

W praktyce należy odróżnić SPF permerror od wyniku SPF fail. Wynik fail oznacza, że rekord można było odczytać, ale wskazany serwer nie spełnił warunków zapisanych w polityce. Permerror wskazuje natomiast, że polityka zawiera błąd uniemożliwiający prawidłowe wykonanie kontroli. Odbiorca może wtedy zastosować bardziej restrykcyjne traktowanie wiadomości, oznaczyć ją jako podejrzaną, skierować do kwarantanny albo odrzucić. Ostateczna reakcja zależy od konfiguracji serwera odbiorczego, reputacji domeny, dodatkowych mechanizmów uwierzytelniania oraz lokalnych reguł antyspamowych.

SPF permerror w kontekście DNS, składni i limitów

Rekord SPF jest przechowywany jako rekord TXT w strefie DNS domeny. Zwykle zaczyna się od elementu v=spf1, po którym występują mechanizmy określające dozwolone źródła wysyłki, na przykład ip4, ip6, a, mx albo include. Na końcu może znaleźć się kwalifikator opisujący reakcję na brak dopasowania, między innymi ~all lub -all. Każdy fragment jest interpretowany według określonej składni, dlatego pozornie drobna literówka, błędny separator czy niewłaściwe użycie parametru może doprowadzić do permerror.

Częstą przyczyną jest opublikowanie więcej niż jednego rekordu SPF dla tej samej domeny. Rekordy TXT mogą występować wielokrotnie, lecz polityka SPF powinna być logicznie zebrana w jednym rekordzie rozpoczynającym się od v=spf1. Dwa niezależne rekordy SPF nie są automatycznie łączone w jedną listę. Serwer odbiorczy może uznać taki układ za błąd trwały, nawet jeśli każdy z rekordów osobno wygląda poprawnie. Z tego powodu podczas porządkowania DNS trzeba sprawdzić wszystkie rekordy TXT, a nie tylko pierwszy wynik pokazany przez wybrane narzędzie.

Drugą grupę problemów stanowią odwołania include oraz mechanizmy powodujące dodatkowe zapytania DNS. SPF ma limit dziesięciu wyszukiwań DNS wykonywanych przez mechanizmy takie jak include, a, mx, ptr i exists. Zagnieżdżone odwołania do zewnętrznych polityk mogą szybko zwiększyć tę liczbę. Po przekroczeniu limitu weryfikacja może zakończyć się permerror, mimo że zapis wygląda poprawnie pod względem składniowym. Warto również pamiętać, że rekord TXT może być podzielony na kilka ciągów tekstowych przez system DNS, jednak podział techniczny nie powinien tworzyć kilku odrębnych polityk SPF.

SPF permerror a typowe problemy z konfiguracją domeny

Jednym z typowych błędów jest wpisanie adresu serwera w formie nieobsługiwanej przez mechanizm SPF. Adres IPv4 powinien być poprzedzony właściwym mechanizmem, na przykład ip4:, a adres IPv6 odpowiednio ip6:. Sam ciąg cyfr i kropek umieszczony bez właściwego prefiksu nie tworzy prawidłowej deklaracji. Problematyczne bywa także wykorzystanie nieaktualnego adresu, niepełnej maski sieciowej albo literówki w nazwie domeny wskazywanej przez include.

Błąd może powstać po zmianie dostawcy poczty, systemu do wysyłki biuletynów, formularza kontaktowego albo platformy transakcyjnej. Do istniejącej polityki dodawany jest wtedy kolejny fragment, lecz nie jest sprawdzane, czy podobne uprawnienie już występuje. Innym scenariuszem jest usunięcie usługi, która pozostawiła w DNS niepotrzebny wpis. Z czasem rekord staje się długi, zawiera sprzeczne deklaracje i odwołuje się do zasobów, które nie są już używane.

Do permerror może doprowadzić również nieprawidłowe użycie kwalifikatorów. Znak +, -, ~ lub ? powinien być przypisany do konkretnego mechanizmu, a nie umieszczony w przypadkowym miejscu. Końcowy mechanizm all zwykle powinien występować na końcu logicznej polityki, ponieważ wszystko, co znajduje się za nim, może nie mieć praktycznego znaczenia. Błędne cudzysłowy, dodatkowe znaki, nieprawidłowe odstępy lub przypadkowe skopiowanie fragmentu konfiguracji z dokumentacji również wymagają sprawdzenia.

• Występują co najmniej dwa rekordy TXT zaczynające się od v=spf1.
• Odwołania include tworzą zbyt rozbudowany łańcuch zapytań DNS.
• Wpis zawiera błędny prefiks adresu, literówkę albo nieprawidłową nazwę domeny.
• Rekord został skrócony, uszkodzony lub rozdzielony w sposób zmieniający jego znaczenie.
• W konfiguracji pozostały odwołania do wyłączonych usług wysyłkowych.

SPF permerror — praktyczne wskazówki diagnostyczne

Diagnozę najlepiej rozpocząć od odczytania aktualnych rekordów TXT bezpośrednio z DNS. Należy sprawdzić zarówno domenę główną, jak i subdomenę używaną w adresie koperty SMTP, ponieważ system SPF ocenia domenę związaną z mechanizmem MAIL FROM, a nie zawsze tę widoczną w polu From. Warto zapisać pełny wynik i przeanalizować go jako całość. Pojedynczy podgląd w panelu operatora może nie pokazywać rekordów odziedziczonych po wcześniejszej konfiguracji albo wpisów dodanych przez inną usługę.

Następnie trzeba policzyć odwołania wymagające zapytań DNS. Szczególnej uwagi wymagają zagnieżdżone elementy include, ponieważ jeden prosty fragment może prowadzić do kolejnych rekordów. Przydatne jest prześledzenie całego łańcucha oraz sprawdzenie, czy każda wskazana domena odpowiada poprawnym rekordem SPF. Jeżeli pojawiają się zbędne mechanizmy, warto usunąć nieużywane źródła zamiast dodawać następne wyjątki. W rozbudowanych środowiskach można rozważyć ograniczenie liczby odwołań przez uporządkowanie adresów IP i usunięcie powtarzających się deklaracji.

Nie powinno się poprawiać rekordu metodą przypadkowego dopisywania kolejnych wartości. Każda zmiana musi uwzględniać rzeczywiste systemy wysyłające wiadomości w imieniu domeny. Zbyt szerokie zezwolenie może ułatwiać podszywanie się pod domenę, natomiast zbyt wąska polityka może powodować odrzucanie prawidłowych wiadomości. Po zapisaniu zmiany trzeba uwzględnić czas propagacji DNS i ponownie wykonać odczyt z kilku niezależnych resolverów. Wynik testu należy porównać z nagłówkami wiadomości, aby upewnić się, że analizowana domena i serwer wysyłający są właściwe.

SPF permerror — kiedy zgłosić problem do serwisu

Do serwisu warto zgłosić się wtedy, gdy permerror pojawia się mimo poprawnego pozornie rekordu, problem dotyczy kilku domen albo konfiguracja była zmieniana przez różne osoby i nie ma pewności, które usługi nadal wysyłają korespondencję. Dotyczy to również sytuacji, w której wiadomości z formularza kontaktowego, systemu powiadomień lub platformy mailingowej znikają u odbiorców, trafiają do spamu albo są odrzucane bez jasnego komunikatu. Analiza powinna objąć rekordy DNS, nagłówki przykładowych wiadomości, ustawienia domeny oraz zależności między używanymi usługami.

W Warszawskim Pogotowiu Komputerowym 24/7 można zlecić uporządkowanie takiej konfiguracji i sprawdzenie, czy przyczyna leży w składni SPF, nadmiarowych rekordach, limitach zapytań DNS czy w błędnym wskazaniu domeny. Przydatne jest przygotowanie kilku przykładów wiadomości oraz informacji o tym, z jakich systemów są wysyłane. Pozwala to odróżnić problem z polityką SPF od kłopotów z DKIM, DMARC, reputacją adresu IP lub filtrowaniem po stronie odbiorcy.

Po usunięciu przyczyny należy wykonać ponowną walidację z perspektywy serwera odbiorczego. Sam fakt, że panel DNS pokazuje zapis bez komunikatu o błędzie, nie potwierdza jeszcze poprawności całej polityki. Potrzebne jest sprawdzenie liczby odwołań, poprawności każdego elementu oraz zgodności z faktycznym sposobem wysyłki. Dobrze przygotowana konfiguracja powinna być możliwie krótka, zrozumiała i regularnie aktualizowana po każdej zmianie dostawcy poczty albo narzędzia wysyłkowego.