Odbicie 550 5.7.23 oznacza, że serwer odbierający odrzucił Twoją wiadomość, ponieważ weryfikacja SPF nie powiodła się, a polityka nakazała odrzucenie zamiast doręczenia. Microsoft 365 jest najczęstszym źródłem dokładnie tego kodu, który niemal zawsze odpowiada jednemu z trzech odrębnych problemów błędnie traktowanych jako to samo. Albo wysyłający IP naprawdę nie jest autoryzowany przez Twój rekord SPF, a Ty stosujesz twardy błąd (-all), albo Twój rekord SPF sam jest wadliwy i zwraca PermError, albo wiadomość została przekierowana i serwer przekierowujący zerwał ścieżkę SPF.
Najszybszym sposobem, aby dowiedzieć się, z którym przypadkiem masz do czynienia, jest sprawdzenie, czy Twój rekord w ogóle się parsuje i ile kosztuje zapytań DNS, ponieważ rekord przekraczający limit zawodzi u każdego odbiorcy niezależnie od wysyłającego IP.
Odczytujemy wyłącznie publiczny DNS. Nic nie zapisujemy, dopóki nie przypiszesz domeny do konta.
Co tak naprawdę mówi 550 5.7.23
Rozszerzony kod statusu 5.7.23 jest zdefiniowany w rejestrze statusów doręczania poczty jako „wiadomość nie została zaakceptowana, ponieważ kontrola SPF nie powiodła się”. Wiodące 550 to trwałe odrzucenie, więc serwer wysyłający nie ponowi próby. Wiadomość odbija się z powrotem do nadawcy z koperty.
Typowe odrzucenie przez Microsoft 365 wygląda tak:
550 5.7.23 The message was rejected because SPF was configured incorrectly, or because SPF validation failed. Please contact the administrator of the domain.
Ta treść jest celowo szeroka, ponieważ Microsoft łączy dwa różne wyniki pod jednym kodem. „SPF was configured incorrectly” to PermError. „SPF validation failed” to twardy błąd. To nie jest ten sam problem i nie ma tego samego rozwiązania. Właśnie dlatego tak wiele osób goni za niewłaściwym rozwiązaniem: widzą kod, zakładają, że ich rekord jest zepsuty, przepisują go, a odbicia trwają nadal, ponieważ prawdziwą przyczyną był nieuwzględniony na liście wysyłający IP.
Przyczyna 1: twardy błąd z -all
SPF publikuje serwery, którym wolno wysyłać w imieniu Twojej domeny, w pojedynczym rekordzie TXT. Mechanizm na końcu mówi odbiorcom, co robić, gdy wysyłającego IP nie ma na tej liście.
v=spf1 include:_spf.google.com -all
-all to twardy błąd. Oznacza „jeśli łączące się IP nie jest autoryzowane przez nic po lewej stronie, potraktuj to jako definitywną porażkę”. Gdy odbiorca oceni twardy błąd, a jego lokalna polityka jest ustawiona na odrzucanie przy niepowodzeniu SPF, otrzymujesz 550 5.7.23.
To jest poprawne, zdrowe zachowanie, gdy nadawca rzeczywiście jest podrobiony. Problem pojawia się, gdy nadawca jest legalny, ale zapomniałeś go autoryzować. Częste przyczyny:
- Dodałeś nową platformę mailingową (CRM, helpdesk, narzędzie do fakturowania), która wysyła z własnych serwerów, a nigdy nie dodałeś jej
includedo swojego rekordu. - Przeniosłeś skrzynki do nowego dostawcy, ale rekord SPF nadal wymienia tylko poprzedniego.
- Serwer aplikacji lub kopiarka wysyła bezpośrednio do odbiorcy bez przekazywania przez autoryzowany host.
Rozwiązaniem jest dodanie brakującego źródła. Jeśli narzędzie marketingowe wysyła w Twoim imieniu, dodaj jego include dokładnie tak, jak dokumentuje to dostawca, a następnie przetestuj ponownie. Nasze przewodniki dostawców, takie jak konfiguracja uwierzytelniania domeny SendGrid oraz konfiguracja SPF, DKIM i DMARC w Amazon SES, pokazują konkretne include, których potrzebuje każda platforma. Jeśli nie masz pewności, czy miękki błąd byłby bezpieczniejszy podczas audytu nadawców, pamiętaj, że ~all (miękki błąd) rzadko sam z siebie powoduje 550, ale daje też więcej miejsca podszywającym się, więc jest to środek tymczasowy, a nie docelowy stan.
Najpierw potwierdź wysyłające IP
Zanim dotkniesz rekordu, przeczytaj odbicie oraz dowolny nagłówek Authentication-Results, jaki uda Ci się uzyskać z wiadomości testowej. Jeśli SPF mówi fail i wskazuje IP należące do usługi, którą rozpoznajesz, to jest przyczyna 1, a rozwiązaniem jest autoryzacja. Jeśli SPF mówi permerror, przejdź dalej, ponieważ żadna autoryzacja IP nie pomoże.
Przyczyna 2: PermError SPF z powodu zbyt wielu zapytań lub błędnej składni
RFC 7208 ogranicza liczbę mechanizmów odpytujących DNS w pojedynczej ocenie SPF do 10. Każdy include, a, mx, ptr, exists i redirect się liczy, a include są rekurencyjne, więc jeden include dostawcy może w tle pociągnąć kilka kolejnych zapytań. Gdy suma przekroczy 10, ocena zwraca PermError, a nie fail.
Tu tkwi pułapka: wielu odbiorców, w tym Microsoft 365, traktuje PermError tak samo jak fail i odrzuca z 550 5.7.23. Zatem rekord, który przepuszcza każdego legalnego nadawcę, i tak odbija pocztę, ponieważ nigdy nie kończy oceny. Dodanie kolejnego include, aby „naprawić” doręczanie, pogarsza sprawę.
Rekord, który wygląda niewinnie, może przekroczyć budżet:
v=spf1 include:_spf.google.com include:servers.mcsv.net include:sendgrid.net include:spf.protection.outlook.com include:_spf.salesforce.com include:mail.zendesk.com -all
Każdy z tych include rozwija się wewnętrznie do kilku zapytań. Sześć include może z łatwością kosztować 12 lub więcej. Nasz checker liczy za Ciebie dokładną liczbę i pokazuje, który include jest kosztowny, więc nie musisz zgadywać. Jeśli przekraczasz limit, naprawa zbyt wielu zapytań DNS w SPF prowadzi przez spłaszczanie, usuwanie martwych nadawców i konsolidację.
PermError pojawia się też przy zwykłych błędach składni:
- Dwa rekordy SPF w tej samej domenie. Wolno Ci mieć dokładnie jeden rekord TXT zaczynający się od
v=spf1. Drugi to PermError. - Literówka w makrze lub mechanizmie, brakująca spacja albo błędny znak.
includewskazujący na nazwę hosta, który nie ma własnego rekordu SPF.
Różnica między PermError a tymczasowym TempError ma znaczenie dla tego, jak zareagujesz, i omawiamy ją w SPF PermError kontra TempError. TempError to przejściowa awaria DNS i zwykle ponawia się poprawnie. PermError to wada rekordu, która będzie odbijać pocztę, dopóki jej nie naprawisz.
Przyczyna 3: przekierowanie, które udaje błąd
SPF uwierzytelnia nadawcę z koperty względem łączącego się IP. Gdy wiadomość jest przekierowywana, na przykład ze starego adresu, który automatycznie przekazuje ją do nowej skrzynki, serwer przekierowujący łączy się przy użyciu własnego IP, ale zachowuje Twoją domenę w kopercie. Twój rekord SPF nie wymienia przekierowującego, więc SPF zawodzi w miejscu docelowym, mimo że z Twoją konfiguracją ani pierwotną wysyłką nie jest nic nie tak.
Tego nie da się naprawić przez edycję rekordu SPF, ponieważ nie możesz wymienić każdego przypadkowego serwera, który może przekazać Twoją pocztę. Jest to dokładnie ten przypadek, który ma przetrwać dopasowanie DMARC przez DKIM, ponieważ prawidłowy podpis DKIM podróżuje wraz z wiadomością i przechodzi nawet wtedy, gdy SPF psuje się w drodze. Wyjaśniamy ten mechanizm w dlaczego przekierowanie poczty psuje SPF oraz kiedy DKIM przechodzi, a SPF zawodzi. Jeśli Twoje odbicia zdarzają się tylko dla przekierowanej poczty, trwałą odpowiedzią jest upewnienie się, że DKIM podpisuje i jest dopasowany, a nie ściganie SPF.
Jak w dwie minuty zdiagnozować swój konkretny przypadek
Przepuść swoją domenę przez powyższy checker i przeczytaj trzy rzeczy po kolei. Po pierwsze, czy rekord w ogóle się parsuje, czy zgłasza błąd składni lub zduplikowany rekord. Po drugie, ile z 10 zapytań zużywa, ponieważ wszystko na poziomie limitu lub powyżej to czekający na wystąpienie PermError. Po trzecie, które źródła wysyłkowe są rzeczywiście autoryzowane, abyś mógł zobaczyć, czy IP z Twojego odbicia znajduje się na liście.
- Błąd parsowania lub zduplikowany rekord: to przyczyna 2, napraw składnię.
- Liczba zapytań 10 lub więcej: to przyczyna 2, zmniejsz liczbę.
- Rekord jest czysty i poniżej limitu, ale brakuje znanego nadawcy: to przyczyna 1, dodaj include.
- Rekord jest czysty, a nadawca autoryzowany, ale odbija się tylko przekierowana poczta: to przyczyna 3, polegaj na dopasowaniu DKIM i DMARC.
Gdy SPF jest już zdrowy, zaostrz warstwę polityki nad nim, aby odbiorcy wiedzieli, co robić z pocztą, która zawiedzie. Zarówno jak skonfigurować SPF, jak i jak skonfigurować DMARC domykają pętlę, a to DMARC zamienia surowy wynik SPF w decyzję polityki, którą kontrolujesz.
Najczęściej zadawane pytania
Czy 550 5.7.23 to zawsze moja wina?
Nie. Jeśli wiadomość została przekierowana, błąd zdarza się na serwerze, którego nie kontrolujesz, a Twoja własna konfiguracja może być całkowicie poprawna. W takim przypadku rozwiązaniem jest potwierdzenie, że DKIM podpisuje i jest dopasowany, ponieważ DKIM przetrwa przekierowanie, a SPF nie. Jeśli odbicie dotyczy poczty bezpośredniej od nadawcy, którego posiadasz, to problem tkwi w Twoim rekordzie lub liście autoryzacji.
Czy zmiana -all na ~all zatrzyma odbicia?
Czasami, ale leczy to objaw, a nie przyczynę. Miękki błąd (~all) zwykle sam z siebie nie wywoła 550, więc poczta może zacząć się doręczać. Ale jeśli prawdziwym problemem jest PermError z powodu zbyt wielu zapytań, złagodzenie kwalifikatora nic nie da, ponieważ PermError całkowicie ignoruje kwalifikator. Najpierw napraw rekord, a potem zdecyduj o kwalifikatorze.
Jak rozpoznać PermError od twardego błędu?
Przeczytaj nagłówek Authentication-Results wiadomości testowej lub użyj powyższego checkera. Twardy błąd wskazuje konkretne nieautoryzowane IP i raportuje spf=fail. PermError raportuje spf=permerror i oznacza, że rekordu nie dało się ocenić, zwykle z powodu przekroczenia 10 zapytań lub wady składni. Oba mają zupełnie różne rozwiązania.
Czy Microsoft 365 domyślnie odrzuca przy PermError?
Microsoft 365 często odrzuca z 550 5.7.23 zarówno przy twardym błędzie, jak i przy PermError, dlatego kod ten jest tak często błędnie diagnozowany. Właśnie dlatego powinieneś potwierdzić, czy Twój rekord się parsuje i ile kosztuje zapytań, zanim założysz, że problemem jest nieautoryzowany nadawca.