Blazalek.com

5.7.20Nie znaleziono podpisu DKIM, który przeszedł weryfikację

System odbiorczy trwale odrzucił wiadomość, ponieważ nie zawierała ona żadnego podpisu DKIM, który przeszedł weryfikację. Nie ponawiaj tej samej, niezmienionej próby.

Kategoria
Bezpieczeństwo, uwierzytelnianie i polityka
Klasa
Niepowodzenie trwałe
Ponowienie
Nie ponawiaj bez zmian
Supresja
Sprawdź pełny kontekst

Co oznacza ten kod

System odbiorczy trwale odrzucił wiadomość, ponieważ nie zawierała ona żadnego podpisu DKIM, który przeszedł weryfikację. Nie ponawiaj tej samej, niezmienionej próby.

Znaczenie techniczne

Standardowy wzorzec X.7.20 jest zwracany, gdy wiadomość nie zawiera żadnego podpisu DKIM, który przeszedł weryfikację; według definicji narusza to zalecenie z sekcji 6.1 RFC 6376. Kod 5.7.20 stosuje ten szczegół w klasie trwałego niepowodzenia.

Status dostarczenia

Pierwsza cyfra 5 oznacza trwałe niepowodzenie bieżącej próby. Sam kod nie rozstrzyga, czy podpisu DKIM nie było, czy wszystkie obecne podpisy nie przeszły weryfikacji, ani która warstwa spowodowała taki wynik.

Klasa
Niepowodzenie trwałe
Ponowienie
Nie ponawiaj bez zmian
Supresja
Sprawdź pełny kontekst

Decyzja o ponowieniu

Zalecenie operacyjne: zatrzymaj automatyczne i ręczne ponowienia tej samej, niezmienionej próby, ponieważ nie zmienią wyniku DKIM. Nową, kontrolowaną próbę rozważ dopiero po potwierdzonej korekcie i sprawdzeniu, że co najmniej jeden podpis DKIM przechodzi weryfikację; wcześniej ponownie sprawdź suppression.

Decyzja o supresji

Zalecenie operacyjne: nie wykluczaj automatycznie adresu odbiorcy ani domeny na podstawie samego 5.7.20. Sprawdź pełną odpowiedź, wynik DKIM, konfigurację uczestniczących systemów i historię zdarzeń, a decyzję o suppression podejmij zgodnie z potwierdzoną przyczyną i właściwą polityką.

Najczęstsze przyczyny

  • Wiadomość nie zawierała podpisu DKIM w punkcie, w którym została oceniona.
  • Wiadomość zawierała co najmniej jeden podpis DKIM, lecz żaden z nich nie przeszedł weryfikacji.

Kroki diagnostyczne

  1. Sprawdź surową odpowiedź SMTP lub raport niedostarczenia i potwierdź dokładny kod 5.7.20 oraz podstawową odpowiedź klasy 5xx; zachowaj pełne brzmienie odpowiedzi.
  2. Powiąż odpowiedź z właściwą wiadomością, czasem i etapem próby oraz systemem zwracającym kod. W kopii wiadomości z ocenianego punktu sprawdź nagłówki DKIM-Signature i dostępne wyniki lub logi weryfikacji, aby odróżnić brak podpisu od niepowodzenia wszystkich podpisów.
  3. Sprawdź logi i konfigurację toru podpisywania, transportu oraz weryfikacji i ustal potwierdzoną przyczynę; nie przypisuj jej nadawcy, odbiorcy ani dostawcy wyłącznie na podstawie kodu.
  4. Zatrzymaj niezmienione ponowienia. Po potwierdzonej korekcie wykaż, że co najmniej jeden podpis DKIM przechodzi weryfikację, ponownie sprawdź suppression i wykonaj jedną kontrolowaną próbę.

Działania z podziałem na role

Nadawca

  • Nie wysyłaj wielokrotnie tej samej, niezmienionej wiadomości; przekaż administratorowi pełną odpowiedź i czas próby bez ujawniania treści wiadomości ani sekretów.

Administrator nadawcy

  • Sprawdź kopię wysłanej wiadomości oraz logi i konfigurację podpisywania i transportu; ustal, czy podpisu brakowało, czy żaden obecny podpis nie przeszedł weryfikacji, i popraw tylko potwierdzoną przyczynę.
  • Po korekcie potwierdź przejście co najmniej jednego podpisu DKIM, ponownie sprawdź suppression i wykonaj jedną kontrolowaną próbę zamiast ponawiać niezmienioną wiadomość.

Administrator odbiorcy

  • Jeżeli zarządzasz systemem zwracającym kod, sprawdź logi i konfigurację weryfikacji DKIM dla wskazanej próby; usuń potwierdzony problem po stronie odbiorczej albo bezpiecznie przekaż nadawcy wynik potrzebny do korekty.

Dostawca

  • Jeżeli obsługujesz zarządzaną warstwę podpisywania, transportu lub weryfikacji, sprawdź jej logi i konfigurację dla tej próby, usuń potwierdzony problem w zarządzanej warstwie i nie uruchamiaj suppression na podstawie samego kodu.

Źródła i weryfikacja

Kanoniczne znaczenie Tier 0 wzorca X.7.20, odniesienie do zalecenia z sekcji 6.1 RFC 6376 i zastosowanie klasy 5 zweryfikowano w rejestrze IANA oraz dokumentach RFC 2034, RFC 5248, RFC 6376 i RFC 7372 według stanu na 17 lipca 2026 r. Wskazówki dotyczące diagnozy, naprawy, ponawiania i suppression są oddzielnymi zaleceniami operacyjnymi; rekord nie zawiera praktyki konkretnego dostawcy.

  • Enumerated Status Codes / X.7.20

  • rfc5248Źródło T0

    Section 2.1: registry fields and non-exclusive Associated Basic Status Code

  • rfc2034Źródło T0

    Section 4: enhanced status class agrees with SMTP reply class

  • rfc7372Źródło T0

    IANA registry reference for X.7.20

  • rfc6376Źródło T0

    IANA registry reference for X.7.20

Ostatnia weryfikacja:

Wojtek Blazalek

Ekspert ds. dostarczalności e-mail

Utknąłeś na tym kodzie błędu? Pomagam zespołom usuwać przyczyny odrzuceń, naprawiać uwierzytelnianie i reputację — tak, żeby maile trafiały do skrzynki.

Praktyczna praca nad dostarczalnością dla firm wysyłających na dużą skalę.