SPF PermError i SPF TempError to dwa odrębne wyniki oceny SPF i oznaczają przeciwne rzeczy. PermError to trwały problem w opublikowanym rekordzie SPF, który będzie generował błąd tak długo, aż poprawisz DNS. TempError to chwilowa awaria DNS w trakcie oceny, która często ustępuje sama, ale mówi ci, że coś jest kruche. Żaden z nich nie jest zwykłym "fail", a traktowanie ich tak samo sprawia, że domeny pozostają zepsute tygodniami.
Odczytujemy wyłącznie publiczny DNS. Nic nie zapisujemy, dopóki nie przypiszesz domeny do konta.
Oba pochodzą z RFC 7208, czyli specyfikacji SPF. Kiedy odbierający serwer pocztowy sprawdza twój rekord SPF, zwraca jeden z kilku wyników: pass, fail, softfail, neutral, none, permerror lub temperror. Te dwa ostatnie to stany błędu, a nie werdykty uwierzytelnienia. Oznaczają, że odbiorca w ogóle nie zdołał dokończyć oceny twojego rekordu. Powód ma znaczenie, ponieważ sposób naprawy jest zupełnie inny w zależności od tego, który z nich otrzymasz.
Zasadnicza różnica w jednej tabeli
Przeczytaj to najpierw. Powie ci, czy działać teraz, czy obserwować i czekać.
| SPF PermError | SPF TempError | |
|---|---|---|
| Co oznacza | Twój rekord SPF jest nieprawidłowy lub niemożliwy do przetworzenia | Odbiorca napotkał chwilową awarię DNS podczas sprawdzania |
| Rodzaj przyczyny | Trwały błąd konfiguracji | Przejściowy problem sieci lub DNS |
| Czy ustępuje sam? | Nie, pozostaje zepsuty, dopóki nie poprawisz DNS | Często tak, przy następnej wysyłce |
| Typowa przyczyna źródłowa | Ponad 10 zapytań DNS, dwa rekordy v=spf1, błędna składnia | Przekroczony limit czasu DNS, SERVFAIL, wolny lub nieosiągalny include |
| Zachowanie odbiorcy | Może potraktować jako fail, odrzucić lub zignorować SPF | Zwykle ponawia próbę lub odracza wiadomość |
| Twoje działanie | Napraw rekord jeszcze dziś | Zbadaj, jeśli się powtarza; zignoruj, jeśli był jednorazowy |
| Ryzyko dla dostarczalności | Wysokie i stałe | Niskie, jeśli rzadkie; wysokie, jeśli chroniczne |
Model myślowy: PermError to literówka w umowie. Jest błędny za każdym razem, dopóki go nie przepiszesz. TempError to przerwane połączenie telefoniczne. Irytujące, zwykle w porządku po ponownym wybraniu numeru, ale prawdziwy problem, jeśli linia wciąż się rozłącza.
Co powoduje SPF PermError
PermError oznacza, że odbiorca sparsował twój rekord i uznał, że nie da się go użyć. Przyczyn jest kilka, a pierwsza z nich jest zdecydowanie najczęstsza.
Ponad 10 zapytań DNS
RFC 7208 ustala sztywny limit 10 mechanizmów odpytujących DNS na jedną ocenę SPF. Każdy mechanizm include, a, mx, ptr i exists obciąża ten budżet, a include działają rekurencyjnie, więc jeden include może wciągnąć za sobą kilka kolejnych zapytań. Przekrocz 10, a odbiorca musi zwrócić permerror.
To przyczyna numer jeden SPF PermError w praktyce. Dzieje się to stopniowo. Dodajesz Google Workspace, potem platformę marketingową, potem system helpdesk, potem dostawcę płatności, a każdy z nich wręcza ci kolejny include. Nic nie wygląda źle w twoim DNS, ale łączna liczba zapytań po cichu przekracza 10.
Rekord taki jak ten jest już na granicy:
v=spf1 include:_spf.google.com include:sendgrid.net include:_spf.salesforce.com include:mailgun.org include:servers.mcsv.net -all
Te pięć include może z łatwością rozwinąć się do ponad 10 zagnieżdżonych zapytań. Rozwiązaniem jest spłaszczenie lub skonsolidowanie include, usunięcie nadawców, których już nie używasz, oraz wycięcie mechanizmów, które nie odpytują DNS. Pełną metodę omawiamy w Napraw zbyt wiele zapytań DNS w SPF. Zwróć uwagę, że mechanizmy ip4 i ip6 kosztują zero zapytań, więc zastąpienie ciężkiego include konkretnymi zakresami IP to jeden z trwałych sposobów na odzyskanie budżetu.
Dwa lub więcej rekordów v=spf1
Domena musi publikować dokładnie jeden rekord SPF. Jeśli twój DNS zwraca dwa rekordy TXT, które oba zaczynają się od v=spf1, odbiorca zwraca permerror. Zwykle dzieje się to wtedy, gdy nowy dostawca każe ci "dodać ten rekord SPF", a ty wklejasz drugi zamiast scalić include do swojego istniejącego rekordu.
Nigdy nie układasz rekordów SPF w stos. Scalasz je w jedną linię z jednym v=spf1 na początku i jednym mechanizmem all na końcu.
Błędna składnia lub wadliwy mechanizm
Źle sformułowane terminy również wywołują permerror. Częste winowajcy: dwa mechanizmy all, makro, którego nie da się sparsować, nieznany modyfikator albo mechanizm z uszkodzonym kwalifikatorem. Końcowe spacje i brakujący all są zwykle tolerowane, ale błędy strukturalne już nie.
Co powoduje SPF TempError
TempError oznacza, że odbiorca zaczął oceniać twój rekord i napotkał chwilową awarię rozwiązywania DNS. Sam rekord może być całkowicie prawidłowy. Problem polega na tym, że zapytanie DNS nie zwróciło odpowiedzi na czas.
Przekroczony limit czasu DNS
Odbiorca odpytał twoją domenę lub jedną z domen w twoich include, a autorytatywny serwer nazw nie odpowiedział wystarczająco szybko. Może to być obciążenie twojego dostawcy DNS, chwilowe zakłócenie sieci między odbiorcą a twoim serwerem nazw albo ograniczenie przepustowości. Pojedyncze przekroczenie limitu czasu jest zwykle dla ciebie niewidoczne i ustępuje przy następnej próbie.
SERVFAIL
Odpowiedź SERVFAIL oznacza, że serwer DNS próbował odpowiedzieć, ale mu się nie udało - często z powodu problemu z walidacją DNSSEC, uszkodzonej delegacji albo przeciążonego resolvera. Jeśli SPF SERVFAIL pojawia się wielokrotnie, wskazuje na realny błąd konfiguracji w twojej strefie DNS lub w strefie jednej z twoich domen include, a nie na losowe zakłócenie.
Wolny lub nieosiągalny include
Twój rekord może zależeć od zewnętrznego include, takiego jak include:_spf.vendor.com. Jeśli DNS tego dostawcy jest wolny lub na chwilę niedostępny, odbiorca może zwrócić temperror, mimo że twój własny DNS działa poprawnie. Dziedziczysz niezawodność każdej domeny, którą włączasz. To dobry powód, żeby przycinać include dla nadawców, których już nie używasz.
Jak radzą sobie z tym odbiorcy
Ponieważ TempError jest przejściowy, większość odbiorców nie odrzuca na jego podstawie wiadomości. Wielu odracza i ponawia próbę, a ponowienie często kończy się sukcesem. Dlatego rzadki TempError nie wyrządza trwałej szkody. Niebezpieczeństwem jest chroniczny wzorzec, ponieważ podczas każdego temperror twój wynik SPF jest w praktyce nieznany, a DMARC może nie otrzymać zaliczenia SPF, którego potrzebuje do wyrównania.
Jak rozpoznać, który z nich masz, i poznać dokładną przyczynę
Oba błędy z zewnątrz wyglądają identycznie: poczta zachowuje się dziwnie albo raport pokazuje coś innego niż pass. Nie możesz zgadywać, który to jest. Musisz przyjrzeć się ocenie.
Najszybsza droga to sprawdzić swoją domenę i pozwolić narzędziu wskazać konkretną przyczynę. Powyższy checker na żywo ocenia twój opublikowany rekord tak, jak robi to odbiorca, liczy twoje zapytania DNS, wykrywa zduplikowane rekordy v=spf1 i raportuje, czy błąd jest trwały, czy przejściowy. Zamiast ogólnego "SPF failed" dostajesz dokładny powód, taki jak liczba zapytań wynosząca 13 albo drugi rekord SPF, więc wiesz, czy edytować DNS teraz, czy wypatrywać powtórki.
Możesz też odczytać to z odebranej wiadomości. Otwórz nagłówek Authentication-Results i spójrz na część dotyczącą SPF. Wyświetli się spf=permerror albo spf=temperror wraz z wysyłającym IP i domeną. Jeśli nie wiesz, jak odczytać ten nagłówek, zobacz Jak odczytać nagłówek Authentication-Results. A jeśli chcesz mieć pełny obraz wszystkich swoich źródeł poczty, zbiorcze raporty DMARC pokazują wyniki SPF na dużą skalę, i właśnie tak wychwytujesz sporadyczny temperror, który dotyka tylko jednej platformy wysyłkowej.
Dlaczego to ma znaczenie dla dostarczalności i DMARC
SPF nie działa samodzielnie. DMARC potrzebuje, aby SPF albo DKIM zaliczyły się i wyrównały z twoją widoczną domeną From. PermError oznacza, że SPF nie wnosi nic do DMARC, więc opierasz się całkowicie na DKIM. Jeśli DKIM też ma problem, DMARC się nie powiedzie, a twoja poczta może zostać poddana kwarantannie lub odrzucona. Zobacz SPF, DKIM i DMARC wyjaśnione, aby zrozumieć, jak te trzy elementy do siebie pasują.
Chroniczny TempError jest cichszy, ale wciąż kosztowny. Za każdym razem, gdy SPF nie może zostać oceniony, ta wiadomość traci jeden ze swoich dwóch sygnałów uwierzytelnienia, co popycha graniczną pocztę w stronę folderu ze spamem. Jeśli walczysz o umieszczenie w skrzynce odbiorczej, dlaczego e-maile trafiają do spamu omawia pozostałe dźwignie, ale stabilny wynik SPF jest warunkiem wstępnym.
Napraw PermError natychmiast, ponieważ nigdy nie leczy się sam. Potraktuj pojedynczy TempError jako szum, ale zbadaj każdy TempError, który się powtarza, ponieważ powtarzająca się przejściowa awaria to prawdziwy problem DNS w tymczasowym przebraniu.
Najczęściej zadawane pytania
Czy SPF PermError to to samo co SPF fail?
Nie. Fail oznacza, że SPF ocenił się poprawnie, a wysyłające IP nie jest autoryzowane. PermError oznacza, że SPF w ogóle nie mógł zostać oceniony, ponieważ rekord jest nieprawidłowy - najczęściej z powodu zbyt wielu zapytań DNS albo zduplikowanego rekordu v=spf1. To odrębne wyniki z odrębnymi sposobami naprawy.
Czy SPF TempError naprawi się sam?
Często tak. TempError jest spowodowany przejściową awarią DNS, taką jak przekroczenie limitu czasu lub SERVFAIL, a następna wysyłka zwykle kończy się sukcesem. Ale jeśli wciąż się powtarza, to nie jest już naprawdę tymczasowy. Sprawdź niezawodność swojego dostawcy DNS i wszelkie zewnętrzne domeny include, od których zależysz.
Ile zapytań DNS dopuszcza SPF?
Dziesięć. RFC 7208 ogranicza ocenę SPF do 10 mechanizmów odpytujących DNS, licząc każdy include, a, mx, ptr i exists, w tym te zagnieżdżone wewnątrz twoich include. Przekroczenie tej liczby wymusza PermError. Spłaszczenie include lub użycie zakresów ip4 i ip6, które nie kosztują żadnych zapytań, sprowadza cię z powrotem poniżej limitu.
Czy mogę mieć więcej niż jeden rekord SPF?
Nie. Domena musi publikować dokładnie jeden rekord zaczynający się od v=spf1. Dwa rekordy SPF powodują PermError. Kiedy nowy dostawca daje ci rekord SPF, scal jego include do swojego istniejącego pojedynczego rekordu, zamiast dodawać drugi.