{"id":26592,"date":"2026-07-23T05:27:40","date_gmt":"2026-07-23T05:27:40","guid":{"rendered":"https:\/\/messageflow.com\/?p=26592"},"modified":"2026-07-23T05:28:37","modified_gmt":"2026-07-23T05:28:37","slug":"port-smtp","status":"publish","type":"post","link":"https:\/\/messageflow.com\/pl\/blog\/port-smtp\/","title":{"rendered":"Port SMTP 25, 587 i 465: Czym si\u0119 r\u00f3\u017cni\u0105 i kt\u00f3ry wybra\u0107"},"content":{"rendered":"

Ka\u017cdy e-mail, kt\u00f3ry wysy\u0142asz przechodzi przez serwer SMTP, a ka\u017cde po\u0142\u0105czenie SMTP zaczyna si\u0119 od numeru portu. Je\u015bli wybierzesz niew\u0142a\u015bciwy, Twoje wiadomo\u015bci mog\u0105 zosta\u0107 odrzucone, w og\u00f3le nie dotrze\u0107, albo by\u0107 przesy\u0142ane nieszyfrowane kiedy nie powinny.<\/p>

W praktycznie ka\u017cdej konfiguracji pojawiaj\u0105 si\u0119 trzy numery port\u00f3w SMTP: 25, 587 i 465. Ka\u017cdy z nich pe\u0142ni inn\u0105 rol\u0119, a wyb\u00f3r to nie kwestia preferencji, a tego z czym si\u0119 \u0142\u0105czysz i jakie miejsce w \u0142a\u0144cuchu dostarczania zajmuje Tw\u00f3j system.<\/p>

Poni\u017cej omawiam zakres zada\u0144 ka\u017cdego z port\u00f3w, to gdzie si\u0119 sprawdz\u0105 oraz kt\u00f3ry powiniene\u015b wybra\u0107.<\/p>

Co robi\u0105 porty SMTP i dlaczego musisz zwr\u00f3ci\u0107 uwag\u0119 na numer<\/h2>

SMTP (Simple Mail Transfer Protocol) to protok\u00f3\u0142, za pomoc\u0105 kt\u00f3rego serwery pocztowe wysy\u0142aj\u0105 mi\u0119dzy sob\u0105 wiadomo\u015bci. Port to numerowany punkt ko\u0144cowy na serwerze, kt\u00f3ry wyczekuje okre\u015blonego typu po\u0142\u0105cze\u0144 \u2013 co\u015b jak drzwi przeznaczone dla konkretnego rodzaju wchodz\u0105cych.<\/p>

Istniej\u0105 r\u00f3\u017cne porty SMTP poniewa\u017c mechanizm wysy\u0142ania poczty bywa zr\u00f3\u017cnicowany. W ramach SMTP zachodz\u0105 dwa odr\u0119bne procesy, kt\u00f3re s\u0105 celowo rozdzielone.<\/p>

E-mail submission <\/h3>

Jest to moment, w kt\u00f3rym Tw\u00f3j klient pocztowy lub aplikacja przekazuje wiadomo\u015b\u0107 serwerowi poczty wychodz\u0105cej. Krok ten m\u00f3wi \u201echc\u0119 to wys\u0142a\u0107”<\/em>, wymaga uwierzytelnienia (potwierdzenia, \u017ce masz prawo wysy\u0142a\u0107 przez ten serwer) i zazwyczaj szyfrowania. Obs\u0142uguj\u0105 go porty 587 i 465.<\/p>

E-mail relay <\/h3>

W tym procesie jeden serwer pocztowy przekazuje wiadomo\u015b\u0107 drugiemu w drodze do odbiorcy. Tw\u00f3j serwer wychodz\u0105cy \u0142\u0105czy si\u0119 z serwerem odbiorcy \u017ceby dostarczy\u0107 wiadomo\u015b\u0107. Obs\u0142uguje go port 25.<\/p>

\"porty<\/figure>

Rozr\u00f3\u017cnienie jest tu istotne poniewa\u017c wymagania bezpiecze\u0144stwa s\u0105 inne. Submission wymaga uwierzytelnienia i szyfrowania. Bez nich ka\u017cdy m\u00f3g\u0142by wysy\u0142a\u0107 poczt\u0119 przez Tw\u00f3j serwer. Relay mi\u0119dzy serwerami posiada w\u0142asne zabezpieczenia, ale dzia\u0142aj\u0105 one na poziomie infrastruktury, nie u\u017cytkownika.<\/p><\/div>

\ud83d\udca1 Wiele b\u0142\u0119d\u00f3w konfiguracyjnych bierze si\u0119 z mylenia tych r\u00f3l: pr\u00f3by u\u017cycia portu relay do submission albo skierowania klienta pocztowego na port, na kt\u00f3rym serwer nie oczekuje po\u0142\u0105cze\u0144 od klient\u00f3w. Je\u017celi wiesz, kt\u00f3ry port pe\u0142ni kt\u00f3r\u0105 funkcj\u0119, wyeliminujesz znaczn\u0105 cz\u0119\u015b\u0107 problem\u00f3w z po\u0142\u0105czeniem SMTP zanim si\u0119 pojawi\u0105.<\/p><\/div>

Port 25: Orygina\u0142, dzi\u015b zasadniczo niedost\u0119pny<\/h2>

Port 25 to najstarszy port SMTP, zdefiniowany w RFC 821<\/a> w 1982 r. Na przestrzeni dekad obs\u0142ugiwa\u0142 wszystko \u2013 zar\u00f3wno submission od klient\u00f3w, jak i relay mi\u0119dzy serwerami. Ten czas jednak min\u0105\u0142.<\/p>

Problem z portem 25 polega\u0142 na jego otwarto\u015bci. W pierwotnym projekcie dowolny system m\u00f3g\u0142 po\u0142\u0105czy\u0107 si\u0119 z dowolnym serwerem pocztowym na porcie 25 i wys\u0142a\u0107 wiadomo\u015b\u0107 bez jakiegokolwiek uwierzytelnienia. We wci\u0105\u017c ma\u0142ym, opartym na zaufaniu internecie mog\u0142o to dzia\u0142a\u0107. W dzisiejszych czasach port 25 sta\u0142 si\u0119 g\u0142\u00f3wnym kana\u0142em do rozsy\u0142ania spamu. Otwarte relay \u2013 serwery, kt\u00f3re przyjmowa\u0142y i przekazywa\u0142y poczt\u0119 od ka\u017cdego \u2013 sta\u0142y si\u0119 tak masowym wektorem nadu\u017cy\u0107, \u017ce bran\u017ca musia\u0142a zareagowa\u0107.<\/p>

Port 25 jest ograniczony do e-mail relay mi\u0119dzy serwerami <\/h3>

Kiedy Tw\u00f3j serwer poczty wychodz\u0105cej dostarcza wiadomo\u015b\u0107 serwerowi odbiorcy, po\u0142\u0105czenie wci\u0105\u017c odbywa si\u0119 na porcie 25. Stanowi on szkielet dostarczania poczty pomi\u0119dzy punktami infrastruktury i technicznie wci\u0105\u017c dzia\u0142a, poniewa\u017c obie strony s\u0105 rozpoznawalnymi serwerami pocztowymi z rekordami DNS (rekordami MX), kt\u00f3re potwierdzaj\u0105 ich rol\u0119.<\/p>

W innych celach port 25 jest de facto zablokowany <\/h3>

Wi\u0119kszo\u015b\u0107 dostawc\u00f3w internetu blokuje ruch wychodz\u0105cy na porcie 25 z \u0142\u0105czy domowych i firmowych \u017ceby zainfekowane maszyny nie mog\u0142y rozsy\u0142a\u0107 spamu bezpo\u015brednio. Duzi dostawcy chmury jak AWS, Google Cloud, czy Azure blokuj\u0105 go domy\u015blnie na nowych instancjach, a odblokowanie wymaga wniosku z uzasadnieniem. <\/p><\/div>

\ud83d\udca1 Je\u015bli pr\u00f3bujesz skonfigurowa\u0107 aplikacj\u0119 lub klienta pocztowego do wysy\u0142ania na porcie 25, prawie na pewno si\u0119 to nie uda dlatego, \u017ce sie\u0107 nie przepu\u015bci ruchu.<\/p><\/div>

Jest jeden scenariusz, w kt\u00f3rym port 25 wci\u0105\u017c ma znaczenie konfiguracyjne: je\u015bli prowadzisz w\u0142asny serwer pocztowy i musisz odbiera\u0107 poczt\u0119 przychodz\u0105c\u0105 od innych serwer\u00f3w. Wtedy Tw\u00f3j serwer nas\u0142uchuje na porcie 25, przyjmuj\u0105c przychodz\u0105ce po\u0142\u0105czenia relay. Ale do wysy\u0142ki wychodz\u0105cej z aplikacji czy klienta port 25 nie jest ju\u017c w\u0142a\u015bciwym wyborem.<\/p>

Port 587: Standard uwierzytelnionej wysy\u0142ki<\/h2>

Port 587 zosta\u0142 wyznaczony do submission poczty w RFC 6409<\/a>, a konkretnie po to, \u017ceby oddzieli\u0107 ruch klient-serwer od relay mi\u0119dzy serwerami. Je\u015bli konfigurujesz aplikacj\u0119, klienta pocztowego lub us\u0142ug\u0119 masowej wysy\u0142ki maili<\/a>, to niemal na pewno jest port, kt\u00f3rego powiniene\u015b u\u017cy\u0107.<\/p>

Obowi\u0105zkowe uwierzytelnienie na porcie 587<\/h3>

W odr\u00f3\u017cnieniu od portu 25, kt\u00f3ry z za\u0142o\u017cenia przyjmowa\u0142 po\u0142\u0105czenia od ka\u017cdego, port 587 wymaga od nadawcy potwierdzenia to\u017csamo\u015bci, zazwyczaj loginem i has\u0142em albo kluczem API, zanim serwer przyjmie wiadomo\u015b\u0107. Ten mechanizm uniemo\u017cliwia nieautoryzowanym nadawcom wykorzystanie Twojego serwera jako otwartego relay.<\/p>

Szyfrowanie dzia\u0142a przez STARTTLS <\/h3>

Po\u0142\u0105czenie z portem 587 zaczyna si\u0119 jako nieszyfrowane, a nast\u0119pnie przechodzi na TLS za pomoc\u0105 komendy STARTTLS zanim jakiekolwiek dane uwierzytelniaj\u0105ce zostan\u0105 przes\u0142ane. Serwer informuje, \u017ce obs\u0142uguje STARTTLS, klient inicjuje proces i od tego momentu sesja jest szyfrowana. Obs\u0142uguje to praktycznie ka\u017cdy wsp\u00f3\u0142czesny serwer pocztowy i klient, a serwery skonfigurowane na porcie 587 odrzucaj\u0105 po\u0142\u0105czenia, kt\u00f3re nie przejd\u0105 na szyfrowane co oznacza, \u017ce szyfrowanie jest w praktyce wymuszane, mimo \u017ce pocz\u0105tkowy handshake odbywa si\u0119 w formie jawnej.<\/p>

Najszersza kompatybilno\u015b\u0107 ze wszystkich trzech port\u00f3w<\/h3>

Port 587 nie jest blokowany przez dostawc\u00f3w internetu ani dostawc\u00f3w chmury tak jak port 25 i jest obs\u0142ugiwany przez ka\u017cd\u0105 znacz\u0105c\u0105 us\u0142ug\u0119 pocztow\u0105 (Gmail, Outlook, Yahoo) oraz ka\u017cdego licz\u0105cego si\u0119 dostawc\u0119 SMTP relay<\/a>. Kiedy dostawca hostingu<\/a> lub us\u0142uga e-mail publikuje swoje ustawienia SMTP, port 587 ze STARTTLS jest niemal zawsze g\u0142\u00f3wn\u0105 rekomendacj\u0105.<\/p>

Dla wi\u0119kszo\u015bci zastosowa\u0144 obejmuj\u0105cych konfiguracj\u0119 CMS-a do wysy\u0142ki powiadomie\u0144, pod\u0142\u0105czenie us\u0142ugi transakcyjnej, routing kampanii marketingowych przez SMTP relay czy ustawienie desktopowego klienta pocztowego, port 587 jest w\u0142a\u015bciwym i domy\u015blnym rozwi\u0105zaniem. Je\u017celi nie masz konkretnego technicznego powodu \u017ceby u\u017cy\u0107 czego\u015b innego, zacznij od niego.<\/p>

Port 465: Implicit TLS i jego drugie \u017cycie<\/h2>

Port 465 posiada nietypow\u0105 histori\u0119. W po\u0142owie lat 90. zosta\u0142 na kr\u00f3tko przypisany do SMTP over SSL, a w 1998 roku IANA cofn\u0119\u0142a t\u0119 decyzj\u0119 kiedy STARTTLS na porcie 587 sta\u0142 si\u0119 preferowanym podej\u015bciem. Przez blisko dwie dekady ten port SMTP istnia\u0142 w szarej strefie \u2013 oficjalnie nieuznany, ale wci\u0105\u017c obs\u0142ugiwany przez wielu dostawc\u00f3w poniewa\u017c dzia\u0142a\u0142, a u\u017cytkownicy wci\u0105\u017c go konfigurowali.<\/p>

W 2018 r. RFC 8314<\/a> da\u0142 portowi 465 nowe \u017cycie, rekomenduj\u0105c go do submission poczty z implicit TLS. R\u00f3\u017cnica wobec portu 587 polega na tym, jak zaczyna si\u0119 szyfrowanie.<\/p>

Port 587 przechodzi na szyfrowanie <\/h3>

Po\u0142\u0105czenie zaczyna si\u0119 nieszyfrowane i prze\u0142\u0105cza na TLS komend\u0105 STARTTLS. Dzia\u0142a to niezawodnie, ale istnieje kr\u00f3tkie okno przed przej\u015bciem, w kt\u00f3rym \u017ale skonfigurowany lub z\u0142o\u015bliwy po\u015brednik m\u00f3g\u0142by teoretycznie zaingerowa\u0107.<\/p>

Port 465 zaczyna zaszyfrowany <\/h3>

Handshake TLS nast\u0119puje natychmiast po nawi\u0105zaniu po\u0142\u0105czenia, bez fazy plaintext i upgrade’u. To samo podej\u015bcie, kt\u00f3rego HTTPS u\u017cywa dla ruchu webowego i kt\u00f3re eliminuje teoretyczne ryzyko downgrade’u obecnego w przypadku STARTTLS.<\/p>

Zasadniczo oba porty zapewniaj\u0105 silne szyfrowanie w\u0142a\u015bciwej sesji. R\u00f3\u017cnica w bezpiecze\u0144stwie jest marginalna dla wi\u0119kszo\u015bci zastosowa\u0144 bo dobrze skonfigurowane serwery na porcie 587 i tak odrzuc\u0105 po\u0142\u0105czenia, kt\u00f3re nie przejd\u0105 na szyfrowane. Przewaga portu 465 ujawnia si\u0119 w \u015brodowiskach ze \u015bcis\u0142ymi regu\u0142ami firewall lub politykami sieciowymi, kt\u00f3re ingeruj\u0105 w negocjacj\u0119 STARTTLS. Implicit TLS omija ten problem, poniewa\u017c po\u0142\u0105czenie jest szyfrowane od pierwszego bajtu.<\/p>

Szerokie, ale nie powszechne wsparcie <\/h3>

Gmail, Yahoo i wi\u0119kszo\u015b\u0107 du\u017cych dostawc\u00f3w akceptuje submission na porcie 465. Cz\u0119\u015b\u0107 starszych lub bardziej konserwatywnie utrzymywanych serwer\u00f3w pocztowych tego nie robi. Je\u015bli wybierasz mi\u0119dzy dwoma portami dla nowej konfiguracji i Tw\u00f3j dostawca obs\u0142uguje oba, port 465 jest nieco nowocze\u015bniejszym wyborem<\/strong>. Je\u015bli zale\u017cy Ci na maksymalnej kompatybilno\u015bci mi\u0119dzy dostawcami, port 587 pozostaje bezpieczniejszym zak\u0142adem.<\/p>

\"port<\/figure>

Kt\u00f3ry port wybra\u0107 i jak go skonfigurowa\u0107<\/h2>

Decyzja jest prostsza ni\u017c sugeruje historia tych port\u00f3w:<\/p>