SPF permerror: za dużo zapytań DNS — jak to naprawić

Gdy serwer odbiorcy potrzebuje więcej niż dziesięciu zapytań DNS, żeby ocenić Twój rekord SPF, przerywa sprawdzanie i zwraca permerror — błąd trwały. Widać go jako spf=permerror w nagłówku Authentication-Results odebranej wiadomości albo jako ostrzeżenie „za dużo zapytań DNS” w narzędziu do sprawdzania SPF. Wiele serwerów traktuje permerror jak nieudane sprawdzenie, a DMARC nigdy nie uznaje go za pass, więc prawdziwa poczta może trafić do spamu albo zostać odrzucona.

Limit pochodzi z RFC 7208, sekcja 4.6.4, i chroni DNS przed rekordami, przez które każdy serwer odbiorcy wysyłałby dziesiątki zapytań na jedną wiadomość. Nie da się poprosić odbiorców o jego podniesienie — to rekord musi się zmniejszyć.

Co wlicza się do limitu

Liczą się tylko elementy rekordu, które zmuszają serwer do zapytania DNS:

Element	Liczy się	Uwagi
include:	po 1	plus wszystko w dołączonym rekordzie
a, a:host	po 1
mx, mx:domena	po 1	serwery poczty są rozwiązywane osobno (niżej)
ptr	po 1	w ogóle nie powinien być używany
exists:	po 1
redirect=	1	plus wszystko w rekordzie docelowym
ip4:, ip6:, all	nie
exp=	nie	pobierany dopiero po wyniku fail

Limit wynosi 10 na całą ocenę, łącznie ze wszystkimi zagnieżdżonymi include. Samo pobranie Twojego rekordu na początku nie jest elementem rekordu i się nie liczy.

Ta sama sekcja wprowadza jeszcze dwa limity:

• Serwery MX. Serwery poczty stojące za jednym mechanizmem mx mogą wymagać najwyżej dziesięciu zapytań o adresy; powyżej tej liczby mechanizm zwraca permerror.
• Puste zapytania (void lookups). Zapytanie, które nie zwraca danych — nazwa nie istnieje albo nie ma rekordu danego typu — to puste zapytanie. Serwery powinny dopuszczać najwyżej dwa; trzecie daje permerror. Zwykle biorą się z include usługi, która już nie istnieje, albo z a: dla usuniętego hosta.

Dlaczego błąd pojawia się „losowo”

Serwer odbiorcy czyta rekord od lewej do prawej i kończy na pierwszym pasującym mechanizmie (sekcja 4.6.2), licząc zapytania po drodze. Wiadomość z serwera dopasowanego wcześnie może przejść, zanim limit zostanie przekroczony, a wiadomość z serwera z końca listy — nie. Dokumentacja Microsoftu opisuje ten sam efekt. Dlatego Sprawdzanie SPF liczy najgorszy przypadek: nadawcę, który nie pasuje do niczego aż do końca rekordu.

Jak liczyć

Ten rekord ma na najwyższym poziomie tylko pięć elementów:

example.com.                TXT  "v=spf1 mx a include:_spf.mailhost.example include:spf.crm.example include:bounce.newsletter.example -all"
_spf.mailhost.example.      TXT  "v=spf1 include:_ip4.mailhost.example include:_ip6.mailhost.example ~all"
spf.crm.example.            TXT  "v=spf1 ip4:198.51.100.0/24 include:spf.cloud.example -all"
spf.cloud.example.          TXT  "v=spf1 ip4:203.0.113.0/24 ip6:2001:db8::/32 -all"
bounce.newsletter.example.  TXT  "v=spf1 a:out1.newsletter.example a:out2.newsletter.example mx ~all"

Przejdź przez każdy include i policz elementy wymagające DNS (zakładamy, że rekordy _ip4 i _ip6 zawierają tylko zakresy IP):

#	Element	Gdzie
1	mx	example.com
2	a	example.com
3	include:_spf.mailhost.example	example.com
4	include:_ip4.mailhost.example	_spf.mailhost.example
5	include:_ip6.mailhost.example	_spf.mailhost.example
6	include:spf.crm.example	example.com
7	include:spf.cloud.example	spf.crm.example
8	include:bounce.newsletter.example	example.com
9	a:out1.newsletter.example	bounce.newsletter.example
10	a:out2.newsletter.example	bounce.newsletter.example
11	mx	bounce.newsletter.example

Jedenaście, czyli o jedno za dużo. Sześć z nich znajduje się w rekordach, nad którymi nie masz kontroli, a dostawcy zmieniają swoje rekordy bez uprzedzenia — rekord, który w zeszłym miesiącu dawał dziewięć zapytań, dziś może dawać jedenaście.

Poprawki — w tej kolejności

1. Usuń to, czego nie używasz

Przy każdym include zadaj dwa pytania.

Czy ta usługa nadal wysyła pocztę w Twoim imieniu? Stare narzędzie do newslettera, poprzedni helpdesk, dostawca skrzynek sprzed migracji — usuń je. Martwe include to też najczęstsze źródło pustych zapytań.

Czy wysyła z Twoją domeną w adresie nadawcy z koperty? SPF jest sprawdzany dla domeny z Return-Path, a nie dla adresu From. Wiele usług używa własnej domeny odbić albo Twojej subdomeny z osobnym rekordem SPF — wtedy ich include w rekordzie domeny głównej nic nie daje. Amazon SES domyślnie korzysta na przykład z subdomeny amazonses.com, a przy własnej domenie MAIL FROM include:amazonses.com trafia do rekordu tej subdomeny. Otwórz prawdziwą wiadomość z każdej usługi i sprawdź Return-Path — Analizator nagłówków e-mail pokazuje go obok wyniku SPF.

W przykładzie: jeśli usługa newsletterowa wysyła z własną domeną odbić, include:bounce.newsletter.example można usunąć, co oszczędza cztery zapytania. SPF przechodzi wtedy dla domeny usługi, więc dla DMARC ta poczta opiera się na DKIM podpisanym Twoją domeną.

2. Zastąp a i mx przez ip4 i ip6

RFC 7208 nazywa rekord z adresami wpisanymi wprost „najlepszym”, a rekord z mx — „kosztownym” (sekcja 10.1.1). Jeśli Twoje serwery mają stałe adresy:

; przed: 2 zapytania za własne serwery
v=spf1 mx a include:_spf.mailhost.example -all

; po: 0 zapytań za własne serwery
v=spf1 ip4:192.0.2.25 ip4:192.0.2.80 include:_spf.mailhost.example -all

Sprawdź też, czy te hosty w ogóle wysyłają pocztę: a autoryzuje adres Twojej strony WWW, a mx — serwery poczty przychodzącej. Gdy pocztę wychodzącą wysyła za Ciebie dostawca skrzynek, oba są często pozostałością. Cena: po zmianie adresu serwera musisz ręcznie zaktualizować SPF.

3. Usuń ptr

RFC 7208 mówi, że ptr nie powinien być publikowany (sekcja 5.5): jest wolny, mniej niezawodny przy problemach z DNS i obciąża serwery odwrotnego DNS. Zastąp go faktycznymi zakresami adresów.

4. Przenieś wysyłkę masową i usługi zewnętrzne na subdomeny

SPF jest sprawdzany dla dokładnej domeny z koperty, więc każda subdomena ma własny rekord i własną pulę dziesięciu zapytań. Wysyłaj newslettery z news.example.com i ustaw ją w platformie marketingowej jako domenę odbić (return-path):

example.com.       TXT  "v=spf1 ip4:192.0.2.25 include:_spf.mailhost.example -all"
news.example.com.  TXT  "v=spf1 include:bounce.newsletter.example -all"

Microsoft zaleca subdomeny dla usług, nad którymi nie masz bezpośredniej kontroli — dzięki temu ich reputacja nie miesza się z pocztą Twoich pracowników. W trybie swobodnym (relaxed), domyślnym w DMARC, wynik SPF pass dla news.example.com nadal jest zgodny z adresem From w domenie example.com, o ile example.com publikuje rekord DMARC — przykład zgodności domen znajdziesz w poradniku SPF, DKIM i DMARC — różnice.

5. Spłaszczanie tylko w ostateczności

„Spłaszczanie” (SPF flattening) zastępuje include adresami IP, na które dziś się rozwiązują. Zmniejsza liczbę zapytań, ale:

• dostawcy zmieniają adresy bez uprzedzenia, więc spłaszczony rekord po cichu się dezaktualizuje i prawidłowa poczta przestaje przechodzić SPF;
• rekord rośnie: jeden ciąg TXT mieści najwyżej 255 znaków, a RFC 7208 zaleca, by cała odpowiedź DNS nie przekraczała około 450 bajtów i mieściła się w jednym pakiecie UDP (sekcja 3.4);
• Microsoft odradza spłaszczanie include:spf.protection.outlook.com, bo jego adresy często się zmieniają.

Jeśli musisz spłaszczać, rób to tylko dla dostawców publikujących stałe, udokumentowane zakresy i zautomatyzuj aktualizacje.

Co nie pomaga

• Drugi rekord SPF. Przy dwóch rekordach v=spf1 pod jedną nazwą każda ocena kończy się błędem permerror (sekcja 4.5).
• Ukrycie include we własnym rekordzie pomocniczym, np. include:_spf.example.com z tymi samymi include w środku. Zagnieżdżone zapytania nadal się liczą.
• Zmiana -all na ~all. Zmienia wynik dla serwerów spoza listy, a nie liczbę zapytań.
• Zmiana TTL. Pamięć podręczna wpływa na to, jak często pyta się DNS, a nie na to, ile elementów rekordu jest ocenianych.

Sprawdź efekt

1. Sprawdź domenę i każdą subdomenę, z której wysyłasz, w narzędziu Sprawdzanie SPF. Śledzi ono każdy include i redirect, pokazuje drzewo include z liczbą zapytań i pustych zapytań oraz oznacza problemy w rekordach dostawców, na które nie masz wpływu.
2. Wyślij wiadomość testową z każdej usługi na zewnętrzną skrzynkę i wklej nagłówki do Analizatora nagłówków e-mail. Szukasz spf=pass dla oczekiwanej domeny z koperty.
3. Daj zmianom czas: resolwery mogą zwracać stary rekord, dopóki nie minie jego TTL.

Podstawy działania SPF opisujemy w poradniku Co to jest SPF i jak działa?