Błąd związany z odmową relayu poczty zwykle nie oznacza awarii samej skrzynki, tylko problem z uprawnieniami, konfiguracją SMTP albo polityką serwera. W praktyce chodzi o sytuację, w której serwer nie chce przekazać wiadomości dalej, bo nie uznaje nadawcy za autoryzowanego. Poniżej rozkładam to na proste kroki: co oznacza ten komunikat, skąd się bierze i jak go naprawić bez zgadywania.
Najkrótsza droga do naprawy tego błędu
- To nie jest zwykły problem z treścią maila, tylko odmowa przekazania wiadomości przez serwer SMTP.
- Najczęstsza przyczyna to brak logowania do serwera wychodzącego, zły port, zły host albo użycie niewłaściwego konta nadawcy.
- Wersja 5.7.1 zwykle oznacza blokadę wynikającą z zasad bezpieczeństwa, a nie chwilowy błąd techniczny.
- Jeśli wysyłasz z programu pocztowego, sprawdź uwierzytelnianie SMTP, port 587 lub 465 i poprawny adres serwera.
- Jeśli wysyłasz z drukarki, formularza lub aplikacji, potrzebujesz osobnej konfiguracji relayu, a nie przypadkowego konta pocztowego.
- SPF, DKIM i DMARC pomagają w dostarczalności, ale nie zastępują prawa do korzystania z relayu.
Co oznacza błąd 553 5.7.1
W skrócie: serwer pocztowy odrzuca próbę przekazania wiadomości do innej domeny. Komunikat 553 5.7.1 we don't relay mails można czytać jako „nie przekażemy dalej tej poczty, bo nie masz do tego uprawnień”. To ważne rozróżnienie, bo problem nie leży w samym adresie e-mail ani w treści wiadomości, tylko w relacji między klientem pocztowym, serwerem SMTP i zasadami, które ten serwer egzekwuje.
Relaying to po prostu przekazywanie maila z jednego serwera na drugi aż do skrzynki odbiorcy. Gdy wysyłasz wiadomość do własnej domeny, serwer może ją przyjąć lokalnie. Gdy próbujesz wysłać pocztę „przez” obcy serwer do zewnętrznej domeny, ten serwer musi mieć pewność, że wolno Ci z niego korzystać. Jeśli tej pewności nie ma, dostajesz odrzucenie 5.7.1.
Warto też pamiętać, że prefiks bywa różny: czasem zobaczysz 550, 553 albo 554, ale sens jest podobny. W praktyce to nadal odmowa z powodów polityki bezpieczeństwa, a nie awaria skrzynki. To prowadzi do pytania, dlaczego serwer w ogóle blokuje taki ruch.
Dlaczego serwer odmawia przekazania poczty
Najczęstszy powód jest prosty: serwer chroni się przed byciem otwartym przekaźnikiem, czyli maszyną, przez którą każdy mógłby wysyłać spam. Dla operatora poczty to podstawowa zasada higieny. Dla użytkownika oznacza to jednak, że nawet poprawnie wpisany adres odbiorcy nie wystarczy, jeśli konfiguracja nie potwierdza tożsamości nadawcy.
| Sytuacja | Co zwykle oznacza | Co sprawdzić w pierwszej kolejności |
|---|---|---|
| Program pocztowy łączy się z serwerem, ale bez logowania | Serwer nie widzi Cię jako autoryzowanego nadawcy | Uwierzytelnianie SMTP, login, hasło, port, szyfrowanie |
| Wysyłasz z innej sieci niż ta, dla której skonfigurowano serwer | Serwer nie ufa bieżącemu adresowi IP lub sieci | Whitelista IP, VPN, polityka dostawcy, konfiguracja relayu |
| Drukarka, skaner albo aplikacja używa „zwykłej” skrzynki | Urządzenie nie ma prawa do relayu, choć potrafi wysyłać SMTP | Dedykowany relay, connector, konto techniczne, port 25 lub 587 |
| Adres nadawcy nie zgadza się z kontem | Serwer uznaje, że próbujesz podszyć się pod inną skrzynkę | Adres `From`, aliasy, domena, polityka „send as” |
W tej klasie błędów liczy się jeszcze jeden szczegół: czasem komunikat 5.7.1 wygląda podobnie, ale w tle chodzi nie o relay, tylko o politykę bezpieczeństwa po stronie odbiorcy. Taki niuans zmienia sposób naprawy, więc zanim cokolwiek przestawisz, warto ustalić, który serwer właściwie odrzucił wiadomość. To prowadzi do diagnostyki, która oszczędza najwięcej czasu.
Jak szybko ustalić, gdzie leży problem
Ja zaczynam od dwóch pytań: z jakiego programu lub urządzenia wychodzi mail i który serwer wystawia błąd. Bez tego łatwo kręcić się w kółko. Jeśli wysyłasz z Outlooka, Thunderbirda, Apple Mail, formularza na stronie albo z urządzenia biurowego, każdy z tych przypadków ma trochę inną ścieżkę diagnostyczną.
- Sprawdź pełny komunikat zwrotny, nie tylko numer 553 lub 5.7.1.
- Ustal nazwę serwera SMTP, port i typ szyfrowania.
- Zweryfikuj, czy konto ma włączone uwierzytelnianie SMTP.
- Sprawdź, czy nadawca i konto logowania są zgodne z polityką dostawcy.
- Jeśli wysyłasz z urządzenia, sprawdź, czy wymaga ono białej listy IP albo connectora.
- Porównaj godzinę błędu z logami serwera, jeśli masz do nich dostęp.
W praktyce najwięcej mówi nie sam kod, tylko całe brzmienie odpowiedzi serwera. Jeśli pojawiają się słowa typu „relay denied”, „not authorized”, „unable to relay” albo „we don't relay”, masz do czynienia z blokadą przekazywania, a nie z problemem skrzynki odbiorcy. Jeśli zamiast tego w komunikacie widać odmowę ze strony domeny docelowej, wtedy przyczyna leży gdzie indziej. Taka różnica wydaje się drobna, ale zmienia wszystko.
Jak naprawić problem jako zwykły użytkownik
Jeśli wysyłasz pocztę z programu pocztowego, najczęściej da się to naprawić bez pomocy administratora. Zaczynam od ustawień konta, bo tam zwykle siedzi błąd, który robi największy bałagan.
- Wpisz poprawny serwer SMTP swojego dostawcy, a nie tylko serwer poczty przychodzącej.
- Włącz uwierzytelnianie SMTP, jeśli klient pocztowy ma taką opcję.
- Użyj właściwego portu najczęściej 587 z STARTTLS albo 465 z SSL/TLS, zależnie od zaleceń dostawcy.
- Sprawdź login i hasło, także wtedy, gdy do skrzynki logujesz się poprawnie w przeglądarce.
- Jeśli masz 2FA, wygeneruj hasło aplikacji, bo zwykłe hasło może nie działać.
- Nie wysyłaj z obcego serwera, np. z SMTP operatora internetowego, jeśli jesteś poza jego siecią i nie masz relayu.
- Zweryfikuj adres nadawcy, bo wysyłka z aliasu lub cudzej domeny często kończy się blokadą.
Jest jeszcze jedna pułapka, którą widzę często: użytkownik zmienia SPF albo DKIM, licząc na szybkie rozwiązanie błędu relay. To nie działa, bo te rekordy pomagają w reputacji i weryfikacji domeny, ale nie dają prawa do korzystania z serwera SMTP. Najpierw trzeba uzyskać autoryzację po stronie samego serwera wychodzącego.
Co zmienić, jeśli zarządzasz serwerem, stroną albo drukarką
Jeśli problem dotyczy firmowej infrastruktury, skryptu na stronie, monitów z systemu ERP albo drukarki wielofunkcyjnej, naprawa zwykle wymaga innej ścieżki niż w zwykłym kliencie pocztowym. Tu chodzi o to, żeby urządzenie lub aplikacja wysyłały wiadomości w sposób zgodny z polityką serwera, a nie „na skróty”.
| Opcja | Kiedy ma sens | Zaleta | Ograniczenie |
|---|---|---|---|
| SMTP AUTH | Jedna skrzynka, aplikacja lub użytkownik | Najprostsza autoryzacja i czytelne logi | Wymaga logowania i poprawnej konfiguracji klienta |
| SMTP relay z connectora lub białej listy IP | Drukarki, skanery, systemy firmowe, wiele urządzeń | Działa dla większej liczby źródeł niż zwykły login | Wymaga stałego IP, reguł i kontroli bezpieczeństwa |
| Direct send | Tylko do wewnętrznych odbiorców w organizacji | Prosta architektura i mniej zależności | Nie nadaje się do wysyłki na zewnątrz |
W środowisku firmowym najważniejsze są trzy rzeczy: poprawny host, zgodność z polityką relayu i spójność adresu nadawcy. Jeśli adres IP urządzenia się zmienia, jeśli certyfikat wygasł albo jeśli connector nie rozpoznaje już źródła, blokada wróci nawet wtedy, gdy wcześniej wszystko działało. Dlatego przy większych wdrożeniach nie ufam „działało do wczoraj”, tylko sprawdzam logi i reguły po każdej zmianie sieci.
Kiedy to nie jest problem po twojej stronie
Nie każdy błąd 5.7.1 oznacza, że coś źle ustawiłeś. Czasem odbiorca ma politykę, która blokuje wiadomości z konkretnej domeny, grupy, adresu IP albo z serwera, który nie spełnia wymagań bezpieczeństwa. Wtedy nawet idealnie skonfigurowany klient nie pomoże, bo odmowa następuje po stronie drugiej organizacji.
Tak samo bywa, gdy wiadomość trafia do grupy lub aliasu, do którego nie masz uprawnień. Serwer może wtedy użyć podobnego kodu, ale przyczyna nie ma nic wspólnego z relayem. W praktyce pomaga pełny bounce message, czas wysyłki, adres nadawcy, adres odbiorcy i informacja, czy problem dotyczy wszystkich wiadomości, czy tylko wybranych domen. Jeśli to ma charakter blokady bezpieczeństwa, zwykle potrzebny jest administrator po stronie odbiorcy albo dostawcy poczty.
Warto odróżnić tę sytuację od klasycznego „mail box unavailable” czy „user unknown”. Tam problem dotyczy samej skrzynki odbiorcy, tutaj zaś najczęściej polityki lub autoryzacji. Ten detal brzmi technicznie, ale w praktyce oszczędza godzinę albo dwie niepotrzebnego grzebania w ustawieniach.
Co zapamiętać, żeby błąd nie wracał
Najlepiej działa prosta zasada: nie zakładaj, że każdy serwer SMTP ma prawo przekazać twoją pocztę dalej. Musisz albo używać konta i ustawień, które serwer uznaje za autoryzowane, albo skonfigurować osobny relay dla urządzeń i aplikacji. To właśnie rozróżnienie najczęściej decyduje o tym, czy mail przejdzie za pierwszym razem, czy odbije się od polityki bezpieczeństwa.
- Trzymaj w jednym miejscu aktualny host SMTP, port i typ szyfrowania.
- Po zmianie hasła, 2FA lub dostawcy usług przetestuj wysyłkę od razu, nie „przy okazji”.
- Jeśli korzystasz z drukarki, formularza lub systemu automatycznego, używaj dedykowanego konta technicznego.
- Nie mieszaj adresu nadawcy z domeną, której nie kontrolujesz.
- Przy zmianie IP, serwera lub certyfikatu sprawdź, czy relay nadal ufa źródłu.
Jeśli potraktujesz ten błąd jako sygnał o autoryzacji, a nie o samej wiadomości, diagnoza staje się dużo prostsza. I zwykle właśnie wtedy problem rozwiązuje się szybko, bez zgadywania i bez psucia kolejnych ustawień.
