Wysyłka poczty przez SMTP potrafi działać świetnie albo sypać błędami tylko dlatego, że wybrano niewłaściwy port. W praktyce najwięcej znaczą trzy wartości: 25, 587 i 465, a każda z nich ma trochę inną rolę, poziom szyfrowania i typ zastosowania. Poniżej porządkuję te różnice, pokazuję, co ustawić w kliencie pocztowym, WordPressie lub na serwerze, oraz wyjaśniam, dlaczego sam port nie rozwiązuje jeszcze problemu z dostarczaniem wiadomości.
Najważniejsze wybory przy wysyłce poczty sprowadzają się do trzech portów i jednego scenariusza
- 25 służy głównie do przekazywania poczty między serwerami, a nie jako domyślny port do logowania użytkownika.
- 587 to najczęstszy wybór do wysyłki z konta użytkownika, aplikacji i WordPressa, zwykle z STARTTLS.
- 465 działa z implicit TLS, czyli szyfrowanie zaczyna się od razu po połączeniu.
- Jeśli konfigurujesz zwykłą wysyłkę z programu lub formularza, w pierwszej kolejności sprawdzaj 587, a potem 465.
- Jeśli konfigurujesz relację serwer-serwer, port 25 nadal ma sens.
- Poprawny port nie gwarantuje doręczenia wiadomości, bo liczą się też DNS, uwierzytelnianie i reputacja nadawcy.
Dlaczego SMTP ma kilka portów zamiast jednego
Najprościej rozdzielam to na dwa światy: przesyłanie wiadomości między serwerami i wysyłkę z konta użytkownika. W pierwszym przypadku mówimy o relacji serwer-serwer, gdzie liczy się routing, kolejki i polityka antyspamowa. W drugim chodzi o sytuację, w której klient pocztowy, wtyczka WordPressa albo aplikacja wysyła wiadomość w imieniu konkretnego nadawcy i musi się uwierzytelnić.
Dlatego w praktyce pojawiają się trzy role: MUA, czyli program używany przez człowieka; MSA, czyli serwer przyjmujący wiadomości do wysyłki; oraz MTA, czyli serwer przekazujący pocztę dalej. To rozróżnienie nie jest akademickie. Ono naprawdę upraszcza konfigurację, bo od razu wiadomo, czy potrzebujesz portu do autoryzowanej wysyłki, czy do relayu między domenami.
Jeśli patrzysz na SMTP wyłącznie jak na „jeden port do maili”, łatwo wpaść w błąd konfiguracji. Lepsze podejście jest prostsze: najpierw ustalam, kto wysyła, do kogo wysyła i czy połączenie ma być szyfrowane od początku, czy dopiero po negocjacji TLS. Dzięki temu następny krok, czyli wybór konkretnego portu, staje się dużo bardziej oczywisty.
Jakie porty SMTP mają znaczenie w praktyce
| Port | Rola | Szyfrowanie | Logowanie | Najczęstsze zastosowanie |
|---|---|---|---|---|
| 25 | Przekazywanie poczty między serwerami | Często STARTTLS, ale nie zakłada się go automatycznie | Zwykle nie w typowym relayu; zależy od polityki serwera | Ruch MTA do MTA, serwery pocztowe, infrastruktura firmowa |
| 587 | Wysyłka wiadomości od użytkownika do serwera | Najczęściej STARTTLS | Tak, zwykle wymagane SMTP AUTH | Klient pocztowy, WordPress, aplikacje, formularze kontaktowe |
| 465 | Wysyłka wiadomości z TLS od razu po zestawieniu połączenia | Implicit TLS | Tak, po zestawieniu szyfrowanego kanału | Klient pocztowy i aplikacje, gdy dostawca zaleca ten wariant |
Różnica między 587 a 465 jest ważniejsza, niż wielu osobom się wydaje. Na 587 najpierw łączysz się w trybie jawnym, a dopiero potem uruchamiasz STARTTLS. Na 465 szyfrowanie startuje od pierwszego pakietu, więc nie ma etapu „przejścia” z połączenia nieszyfrowanego. To właśnie dlatego część paneli pokazuje przy 465 opcję SSL, choć technicznie lepiej myśleć o niej jako o połączeniu TLS od początku.
Jeśli mam wskazać domyślny wybór do zwykłej wysyłki, zaczynam od 587. Jeśli dostawca poczty wyraźnie zaleca 465, nie upieram się przy 587, tylko dostosowuję konfigurację do jego modelu. Port 25 zostawiam do komunikacji między serwerami albo do środowisk, które mają własny, świadomie zaprojektowany scenariusz relayu.
Ta tabela prowadzi do kolejnego pytania: który z tych portów wybrać dla konkretnego narzędzia, a nie tylko dla teorii.
Czym różni się STARTTLS od implicit TLS
To jeden z najczęstszych punktów nieporozumień przy konfiguracji poczty. STARTTLS oznacza, że połączenie startuje jako zwykły TCP, a dopiero później klient i serwer uzgadniają przejście na szyfrowanie. Implicit TLS działa odwrotnie: szyfrowanie jest aktywne od razu i nie ma etapu jawnej rozmowy przed TLS.
W praktyce STARTTLS daje elastyczność i dobrze współgra z portem 587. Z kolei implicit TLS jest prostsze koncepcyjnie po stronie klienta, bo od razu wiesz, że połączenie ma być zaszyfrowane, co pasuje do portu 465. Oba rozwiązania są dziś normalne i poprawne, o ile serwer i klient są skonfigurowane spójnie.
Ja zwykle patrzę na to tak: jeśli aplikacja lub hosting mówi „użyj 587”, wybieram STARTTLS. Jeśli mówi „użyj 465”, ustawiam TLS od razu. Nie mieszam tych modeli, bo to właśnie mieszanie najczęściej kończy się komunikatem o błędnym handshake albo zerwanym połączeniu.
Który port wybrać do klienta pocztowego, WordPressa i serwera
Tu nie ma jednej odpowiedzi dla wszystkich, ale da się przyjąć sensowną kolejność wyboru.
- Klient pocztowy na komputerze lub telefonie - najczęściej zaczynam od 587 z STARTTLS. Jeśli dostawca konta wyraźnie wymaga implicit TLS, przechodzę na 465.
- WordPress i formularze kontaktowe - w praktyce najbezpieczniej działa 587, bo większość wtyczek i usług SMTP dobrze go obsługuje. 465 jest sensowną alternatywą, gdy tak zaleca dostawca poczty.
- Serwer wysyłający pocztę do innych serwerów - tutaj ma sens 25, bo to właśnie jego rola w klasycznym modelu SMTP.
Jeżeli prowadzisz stronę na WordPressie, myśl praktycznie: wtyczka ma wysłać maila z formularza, resetu hasła albo powiadomienia administracyjnego. To nie jest relacja MTA do MTA, tylko autoryzowana wysyłka w imieniu konkretnej skrzynki. W takim scenariuszu port 25 zwykle nie jest pierwszym wyborem, a czasem w ogóle nie powinien być używany.
Gdy ktoś pyta mnie, od czego zacząć, odpowiadam krótko: 587, a jeśli to nie działa zgodnie z dokumentacją dostawcy, 465. Dopiero kiedy konfigurujesz własny serwer pocztowy albo firmowy relay, wracasz do portu 25.
Jak skonfigurować wysyłkę krok po kroku
W konfiguracji nie szukam „magicznego ustawienia”, tylko pilnuję kolejności. To oszczędza czas i zmniejsza liczbę błędów.
- Sprawdzam host SMTP - używam dokładnie tej nazwy serwera, którą podaje dostawca poczty lub hostingu.
- Dobieram port do trybu szyfrowania - 587 oznacza zwykle STARTTLS, a 465 oznacza TLS od razu.
- Włączam uwierzytelnianie - SMTP AUTH powinno być aktywne, bo wysyłka z konta użytkownika bez logowania to dziś rzadko dobry pomysł.
- Używam pełnego adresu e-mail jako loginu - w wielu konfiguracjach to prosty szczegół, który decyduje o powodzeniu połączenia.
- Ustawiam zgodny adres nadawcy - najlepiej taki, który pasuje do domeny i skrzynki użytej do logowania.
- Testuję jedną wiadomość i sprawdzam logi - zanim uruchomię formularze, automaty i powiadomienia, chcę zobaczyć, czy pojedynczy mail przechodzi bez błędów.
W WordPressie zwracam jeszcze uwagę na jedną rzecz: wtyczka powinna wymuszać wysyłkę przez zewnętrzny serwer, a nie próbować korzystać z lokalnej funkcji pocztowej hostingu, jeśli ta ma słabą reputację lub ograniczenia. W praktyce właśnie wtedy rośnie szansa, że wiadomości trafią do skrzynki odbiorczej, a nie do spamu.
Jeżeli połączenie z pozoru działa, ale wiadomości nie dochodzą, nie zakładam od razu, że winny jest port. Najpierw sprawdzam, czy szyfrowanie odpowiada wybranemu portowi, a dopiero potem zaglądam w DNS i politykę nadawcy.
Najczęstsze błędy przy wysyłce poczty
W praktyce ciągle widzę te same pomyłki, tylko w różnych konfiguracjach. Najbardziej kosztuje nie brak wiedzy, ale niekonsekwencja między portem, szyfrowaniem i uwierzytelnianiem.
- Pomylenie 465 z 587 - ktoś ustawia 465, ale wybiera STARTTLS zamiast TLS od początku, albo odwrotnie.
- Brak SMTP AUTH - serwer odrzuca wiadomość, bo traktuje klienta jak nieautoryzowany podmiot.
- Zły login - wpisanie samej nazwy użytkownika zamiast pełnego adresu e-mail.
- Blokada portu 25 - szczególnie częsta w sieciach, gdzie operator ogranicza ruch wychodzący, żeby utrudnić spam.
- Niepasujący certyfikat - host i certyfikat nie zgadzają się, więc klient przerywa negocjację TLS.
- Założenie, że port naprawi dostarczalność - nawet idealny port nie pomoże, jeśli domena nie ma poprawnej autoryzacji nadawcy.
To ostatnie jest szczególnie zdradliwe. Wiele osób zmienia port, widzi chwilową poprawę i myśli, że problem zniknął. A on zwykle tylko przesunął się o jeden krok dalej, na poziom reputacji domeny, filtrów antyspamowych albo błędów w konfiguracji serwera.
Po tej liście naturalnie pojawia się kolejne pytanie: co jeszcze trzeba sprawdzić, gdy sam port jest poprawny, a poczta nadal nie przechodzi.
Co sprawdzam, gdy port działa, a wiadomości nadal nie dochodzą
Jeśli połączenie SMTP przechodzi, a wiadomości nie trafiają tam, gdzie powinny, odłączam się na chwilę od samego portu i patrzę na cały łańcuch dostarczania. Najczęściej problem siedzi w DNS, autoryzacji albo reputacji nadawcy, nie w samym numerze portu.
- SPF - sprawdzam, czy domena pozwala na wysyłkę z danego serwera.
- DKIM - upewniam się, że wiadomości są podpisywane poprawnie.
- DMARC - patrzę, czy polityka domeny nie blokuje źle zbudowanych wiadomości.
- Reputacja IP - nawet poprawna technicznie wysyłka może wpadać do spamu, jeśli adres serwera ma słabą historię.
- Logi serwera - one zwykle pokazują dokładniej niż panel, czy problemem jest TLS, autoryzacja, kolejka czy odrzucenie po stronie odbiorcy.
Warto też sprawdzić, czy zegar serwera jest poprawnie zsynchronizowany, a certyfikat SSL/TLS nie jest przeterminowany. Brzmi banalnie, ale w praktyce właśnie takie detale potrafią wywołać trudne do zdiagnozowania błędy przy wysyłce.
Gdybym miał zostawić jedną praktyczną zasadę, powiedziałbym tak: do zwykłej wysyłki zaczynaj od 587, traktuj 465 jako równorzędną opcję z implicit TLS, a 25 zostaw do komunikacji między serwerami. Resztę ustawień dobierz do konkretnego dostawcy, bo w mailach poprawna technika i poprawna konfiguracja muszą iść dokładnie w parze.
