Walidacja rekordu SPF oznacza sprawdzenie go względem reguł, które odbierające serwery pocztowe faktycznie egzekwują - specyfikacji Sender Policy Framework (RFC 7208). Rekord może wyglądać poprawnie, a mimo to zostać odrzucony, oto więc, co oznacza "poprawny" i jak naprawić usterki, które znajduje ten walidator.
Co oznacza "poprawny" według RFC 7208
Poprawny rekord SPF spełnia jednocześnie każdy z tych warunków: jest jedynym rekordem TXT v=spf1 w domenie, zaczyna się od tagu v=spf1, używa wyłącznie rozpoznawanych mechanizmów i kwalifikatorów, rozwiązuje się w dziesięciu lub mniej zapytaniach DNS, generuje nie więcej niż dwa zapytania void i kończy się kwalifikatorem all. Niespełnienie któregokolwiek z nich sprawia, że odbiorcy mogą zwrócić PermError i traktować rekord tak, jakby nigdy nie został opublikowany.
Reguły składni egzekwowane przez walidator
- Tylko jeden rekord. RFC 7208 dopuszcza dokładnie jeden rekord
v=spf1na domenę. Drugi to automatyczny PermError - oba są ignorowane. - Poprawna kolejność. Tag wersji
v=spf1musi występować jako pierwszy, a mechanizmalljako ostatni. - Wyłącznie poprawne mechanizmy i kwalifikatory. Dozwolone mechanizmy to
include,a,mx,ip4,ip6,existsiall; każdy może nieść kwalifikator+,-,~lub?. Literówki takie jakip:czyincludes:zawodzą. - Długość łańcucha. Każdy pojedynczy łańcuch znaków w rekordzie TXT musi mieścić się w 255 znakach, a cały rekord w 512 bajtach, w przeciwnym razie DNS go obcina.
Limity 10 zapytań i 2 zapytań void
Dwa liczbowe limity wychwytują większość rekordów "poprawna składnia, a mimo to zawodzi". Pierwszy to dobrze znany pułap dziesięciu mechanizmów odpytujących DNS na ewaluację - każdy include, a, mx, ptr i exists się liczy, a zagnieżdżone include liczą się rekurencyjnie. Drugi, mniej znany limit to zapytania void: nie więcej niż dwa mechanizmy mogą rozwiązać się do pustej odpowiedzi DNS. Przekroczenie któregokolwiek daje w efekcie PermError. Jeśli Państwa rekord przekracza limit dziesięciu zapytań, AutoSPF spłaszcza mechanizmy include do kompaktowego rekordu, który waliduje się czysto, i skanuje ponownie co 15 minut - zobacz zbyt wiele zapytań DNS, aby poznać szczegóły.
Przestarzałe i ryzykowne mechanizmy
Walidator ostrzega przed dwiema rzeczami, które są technicznie parsowalne, ale należy ich unikać. Mechanizm ptr jest przestarzały wg RFC 7208 (§5.5), ponieważ jest wolny i zawodny - zastąp go ip4/ip6 lub include. Z kolei +all autoryzuje cały internet do wysyłania jako Państwa domena, całkowicie niwecząc cel SPF; poprawny rekord powinien kończyć się na -all lub ~all.
Jak naprawić nieprawidłowy rekord SPF
Większość niepowodzeń walidacji odpowiada jednej z czterech napraw - a nasz przewodnik o tym, jak rozwiązywać problemy z walidacją SPF, omawia każdą z nich dogłębnie:
- Dwa rekordy SPF? Połącz każdego nadawcę w pojedynczy rekord
v=spf1. - Ponad 10 zapytań? Zastąp wymagające wielu zapytań include wpisami
ip4/ip6albo spłaszcz rekord automatycznie za pomocą AutoSPF. - Przestarzały
ptr? Usuń go i zamiast tego autoryzuj te hosty przez IP lub include. - Brakujący lub błędny kwalifikator? Upewnij się, że rekord zaczyna się od
v=spf1i kończy na-all(lub~allpodczas testowania).
Odbudowanie od zera jest często łatwiejsze niż łatanie - darmowy generator rekordów SPF tworzy składniowo czysty rekord, który mogą Państwo zwalidować tutaj w jednym kroku.
Gdzie SPF mieści się obok DKIM i DMARC
Poprawny rekord SPF jest konieczny, ale niewystarczający. DKIM podpisuje treść wiadomości, a DMARC wiąże SPF i DKIM z widoczną domeną From oraz ustawia politykę egzekwowania. Po tym, jak sprawdzą Państwo swój rekord SPF i się on zwaliduje, potwierdź pozostałe dwa darmowym weryfikatorem DMARC oraz wyszukiwarką DKIM. SPF należy walidować ponownie za każdym razem, gdy dodają lub usuwają Państwo usługę wysyłkową, i audytować go co najmniej raz na kwartał - i pamiętać, że każda wysyłająca subdomena potrzebuje własnego poprawnego rekordu.