Kody błędów SMTP – 4xx, 5xx i rozszerzone kody statusu

Z czego składa się komunikat błędu SMTP

Gdy serwer pocztowy odrzuca wiadomość, odpowiada linią podobną do poniższej – i ta sama linia trafia potem do wiadomości zwrotnej, którą dostajesz:

550 5.1.1 The email account that you tried to reach does not exist.

• 550 to podstawowy kod odpowiedzi zdefiniowany w standardzie SMTP (RFC 5321). Wysyła go każdy serwer SMTP.
• 5.1.1 to rozszerzony kod statusu (RFC 3463) – dokładniejsza klasyfikacja, którą dołącza niemal każdy współczesny serwer.
• Reszta to dowolny tekst. Nie jest ustandaryzowany, ale często jest najbardziej przydatny: duzi operatorzy podają w nim dokładny powód, a czasem link do pomocy.

Podstawowy kod odpowiedzi

O tym, jak zareaguje serwer nadawcy, decyduje pierwsza cyfra:

RFC 5321 zaleca, żeby nadawca odczekał przed ponowieniem – zwykle co najmniej 30 minut – i próbował przez dłuższy czas: limit, po którym się poddaje, „na ogół musi wynosić co najmniej 4–5 dni”. W praktyce wielu nadawców na początku ponawia szybciej i rezygnuje wcześniej.

Kody odpowiedzi, które faktycznie zobaczysz w zwrotach:

Warto znać dwie osobliwości. 550 oznacza zarówno „nie ma takiego użytkownika”, jak i „nie chcemy Twojej poczty”, więc sam w sobie niewiele mówi. A RFC 5321 zauważa, że dawny standard błędnie używał 552 dla „zbyt wielu odbiorców” – poprawny kod to 452, a klienci powinni traktować 552 otrzymany z tego powodu jako błąd tymczasowy.

Rozszerzone kody statusu

RFC 3463 definiuje kod trzyczęściowy: klasa.temat.szczegół. Klasa powtarza pierwszą cyfrę: 2 – sukces, 4 – trwające przejściowe niepowodzenie, 5 – trwałe niepowodzenie. Najwięcej mówi temat, bo wskazuje, gdzie leży problem:

Kody szczegółowe są rejestrowane w IANA. Część pochodzi z RFC 3463, inne dodano później – RFC 7372 wprowadził kody dla nieudanego uwierzytelnienia poczty, a RFC 7505 kody dla null MX.

Najczęstsze zwroty i co z nimi zrobić

Operatorzy nie zawsze używają kodów tak samo. RFC 3463 mówi, że „skrzynka pełna” to błąd przejściowy, a mimo to niektóre serwery zwracają go jako 552 5.2.2; z kolei 5.7.1 obejmuje wszystko – od wpisu na czarnej liście po regułę odbiorcy „przyjmuj pocztę tylko od współpracowników”. Komunikaty konkretnych operatorów objaśniają poradniki o Gmailu i Outlooku.

Soft bounce i hard bounce

Te pojęcia pochodzą ze świata e-mail marketingu, a nie z żadnego RFC, ale da się je przyporządkować do kodów:

• Soft bounce (miękki zwrot) to błąd tymczasowy – odpowiedź 4xx albo pełna skrzynka. Adres jest poprawny; doręczenie może się później udać. Twój serwer sam ponawia próby.
• Hard bounce (twardy zwrot) to trwały błąd dotyczący adresu – 5.1.1, 5.1.2, 5.1.10, zwykle też powtarzające się 5.2.1. Ponawianie nic nie da.
• Blokada to trwały błąd dotyczący Ciebie, a nie adresu – odrzucenia 5.7.x z powodu polityki i reputacji. Nie usuwaj odbiorcy; popraw uwierzytelnienie lub reputację, a ten sam adres znów zacznie przyjmować pocztę.

Adresy z twardym zwrotem usuwaj po pierwszym błędzie. Uporczywe wysyłanie na nieistniejące adresy to jeden z najwyraźniejszych sygnałów kupionej lub nieaktualnej bazy i serwery odbiorców obniżają za to Twoją reputację. Miękki zwrot powtarzający się przy wielu wysyłkach przez kilka tygodni traktuj jak twardy.

Odrzucenie czy zwrot: kiedy błąd do Ciebie trafia

Niepowodzenie może się ujawnić na dwa sposoby:

• W trakcie rozmowy SMTP. Serwer odbiorcy odmawia kodem 4xx lub 5xx, zanim przyjmie wiadomość. Twój serwer zna wtedy powód z pierwszej ręki i albo ponawia próbę, albo wysyła Ci raport o niedoręczeniu.
• Po przyjęciu. Odbiorca odpowiedział 250, a dopiero później okazało się, że nie może doręczyć – np. zawiodło przekierowanie. Musi wtedy wysłać zwrot na adres nadawcy z koperty. Gdy ten adres był sfałszowany, zwroty trafiają do niewinnych osób: to tzw. backscatter i dlatego dobrze utrzymane serwery starają się odrzucać pocztę w trakcie rozmowy SMTP, zamiast przyjmować ją i zwracać później.

Co zawiera raport DSN (wiadomość zwrotna)

Wiadomość zwrotna to formalnie Delivery Status Notification, zdefiniowana w RFC 3464. Jest to wiadomość MIME typu multipart/report (RFC 6522) z report-type=delivery-status, złożona z maksymalnie trzech części: opisu dla człowieka, części maszynowej message/delivery-status i oryginalnej wiadomości lub jej nagłówków. Część maszynową czytają programy do obsługi zwrotów:

Reporting-MTA: dns; mail.firma.pl
Arrival-Date: Mon, 26 Oct 2026 09:12:44 +0100

Final-Recipient: rfc822; jan@example.net
Action: failed
Status: 5.1.1
Remote-MTA: dns; mx.example.net
Diagnostic-Code: smtp; 550 5.1.1 User unknown
Last-Attempt-Date: Mon, 26 Oct 2026 09:12:46 +0100

• Action przyjmuje wartość failed (rezygnacja), delayed (nadal ponawia – to ostrzeżenie, a nie zwrot), delivered, relayed lub expanded.
• Status to rozszerzony kod statusu, Diagnostic-Code – dokładna odpowiedź serwera odbiorcy, a Remote-MTA – serwer, który jej udzielił.
• Raport wygenerowany przez Twój serwer po serii błędów 4xx, gdy skończył się czas na ponawianie, zawiera zwykle 4.4.7 albo ostatni otrzymany błąd tymczasowy.

Jak to wygląda w AnyMail

AnyMail doręcza pocztę zewnętrzną bezpośrednio do serwera odbiorcy i trzyma się tych samych zasad: odpowiedź 4xx jest ponawiana w coraz dłuższych odstępach przez nieco ponad dwa dni (do 10 prób), a odpowiedź 5xx od razu kończy wysyłkę niepowodzeniem i pokazuje obok wiadomości powód podany przez serwer odbiorcy. Gdy wiadomości nie da się doręczyć, do skrzynki nadawcy trafia raport zgodny z RFC 3464, a jeśli po kilku godzinach doręczenie wciąż jest ponawiane – jednorazowe powiadomienie o opóźnieniu. Odbiorcy, którzy wypisali się linkiem jednym kliknięciem, są traktowani jak trwałe niepowodzenie i nie dostają kolejnych wiadomości. Pocztę przychodzącą AnyMail odrzuca w trakcie rozmowy SMTP, zamiast przyjmować ją i zwracać później, więc nigdy nie wytwarza backscatteru.