Każdy e-mail, który wysyłasz przechodzi przez serwer SMTP, a każde połączenie SMTP zaczyna się od numeru portu. Jeśli wybierzesz niewłaściwy, Twoje wiadomości mogą zostać odrzucone, w ogóle nie dotrzeć, albo być przesyłane nieszyfrowane kiedy nie powinny.
W praktycznie każdej konfiguracji pojawiają się trzy numery portów SMTP: 25, 587 i 465. Każdy z nich pełni inną rolę, a wybór to nie kwestia preferencji, a tego z czym się łączysz i jakie miejsce w łańcuchu dostarczania zajmuje Twój system.
Poniżej omawiam zakres zadań każdego z portów, to gdzie się sprawdzą oraz który powinieneś wybrać.
Co robią porty SMTP i dlaczego musisz zwrócić uwagę na numer
SMTP (Simple Mail Transfer Protocol) to protokół, za pomocą którego serwery pocztowe wysyłają między sobą wiadomości. Port to numerowany punkt końcowy na serwerze, który wyczekuje określonego typu połączeń – coś jak drzwi przeznaczone dla konkretnego rodzaju wchodzących.
Istnieją różne porty SMTP ponieważ mechanizm wysyłania poczty bywa zróżnicowany. W ramach SMTP zachodzą dwa odrębne procesy, które są celowo rozdzielone.
E-mail submission
Jest to moment, w którym Twój klient pocztowy lub aplikacja przekazuje wiadomość serwerowi poczty wychodzącej. Krok ten mówi „chcę to wysłać”, wymaga uwierzytelnienia (potwierdzenia, że masz prawo wysyłać przez ten serwer) i zazwyczaj szyfrowania. Obsługują go porty 587 i 465.
E-mail relay
W tym procesie jeden serwer pocztowy przekazuje wiadomość drugiemu w drodze do odbiorcy. Twój serwer wychodzący łączy się z serwerem odbiorcy żeby dostarczyć wiadomość. Obsługuje go port 25.
Rozróżnienie jest tu istotne ponieważ wymagania bezpieczeństwa są inne. Submission wymaga uwierzytelnienia i szyfrowania. Bez nich każdy mógłby wysyłać pocztę przez Twój serwer. Relay między serwerami posiada własne zabezpieczenia, ale działają one na poziomie infrastruktury, nie użytkownika.
💡 Wiele błędów konfiguracyjnych bierze się z mylenia tych ról: próby użycia portu relay do submission albo skierowania klienta pocztowego na port, na którym serwer nie oczekuje połączeń od klientów. Jeżeli wiesz, który port pełni którą funkcję, wyeliminujesz znaczną część problemów z połączeniem SMTP zanim się pojawią.
Port 25: Oryginał, dziś zasadniczo niedostępny
Port 25 to najstarszy port SMTP, zdefiniowany w RFC 821 w 1982 r. Na przestrzeni dekad obsługiwał wszystko – zarówno submission od klientów, jak i relay między serwerami. Ten czas jednak minął.
Problem z portem 25 polegał na jego otwartości. W pierwotnym projekcie dowolny system mógł połączyć się z dowolnym serwerem pocztowym na porcie 25 i wysłać wiadomość bez jakiegokolwiek uwierzytelnienia. We wciąż małym, opartym na zaufaniu internecie mogło to działać. W dzisiejszych czasach port 25 stał się głównym kanałem do rozsyłania spamu. Otwarte relay – serwery, które przyjmowały i przekazywały pocztę od każdego – stały się tak masowym wektorem nadużyć, że branża musiała zareagować.
Port 25 jest ograniczony do e-mail relay między serwerami
Kiedy Twój serwer poczty wychodzącej dostarcza wiadomość serwerowi odbiorcy, połączenie wciąż odbywa się na porcie 25. Stanowi on szkielet dostarczania poczty pomiędzy punktami infrastruktury i technicznie wciąż działa, ponieważ obie strony są rozpoznawalnymi serwerami pocztowymi z rekordami DNS (rekordami MX), które potwierdzają ich rolę.
W innych celach port 25 jest de facto zablokowany
Większość dostawców internetu blokuje ruch wychodzący na porcie 25 z łączy domowych i firmowych żeby zainfekowane maszyny nie mogły rozsyłać spamu bezpośrednio. Duzi dostawcy chmury jak AWS, Google Cloud, czy Azure blokują go domyślnie na nowych instancjach, a odblokowanie wymaga wniosku z uzasadnieniem.
💡 Jeśli próbujesz skonfigurować aplikację lub klienta pocztowego do wysyłania na porcie 25, prawie na pewno się to nie uda dlatego, że sieć nie przepuści ruchu.
Jest jeden scenariusz, w którym port 25 wciąż ma znaczenie konfiguracyjne: jeśli prowadzisz własny serwer pocztowy i musisz odbierać pocztę przychodzącą od innych serwerów. Wtedy Twój serwer nasłuchuje na porcie 25, przyjmując przychodzące połączenia relay. Ale do wysyłki wychodzącej z aplikacji czy klienta port 25 nie jest już właściwym wyborem.
Port 587: Standard uwierzytelnionej wysyłki
Port 587 został wyznaczony do submission poczty w RFC 6409, a konkretnie po to, żeby oddzielić ruch klient-serwer od relay między serwerami. Jeśli konfigurujesz aplikację, klienta pocztowego lub usługę masowej wysyłki maili, to niemal na pewno jest port, którego powinieneś użyć.
Obowiązkowe uwierzytelnienie na porcie 587
W odróżnieniu od portu 25, który z założenia przyjmował połączenia od każdego, port 587 wymaga od nadawcy potwierdzenia tożsamości, zazwyczaj loginem i hasłem albo kluczem API, zanim serwer przyjmie wiadomość. Ten mechanizm uniemożliwia nieautoryzowanym nadawcom wykorzystanie Twojego serwera jako otwartego relay.
Szyfrowanie działa przez STARTTLS
Połączenie z portem 587 zaczyna się jako nieszyfrowane, a następnie przechodzi na TLS za pomocą komendy STARTTLS zanim jakiekolwiek dane uwierzytelniające zostaną przesłane. Serwer informuje, że obsługuje STARTTLS, klient inicjuje proces i od tego momentu sesja jest szyfrowana. Obsługuje to praktycznie każdy współczesny serwer pocztowy i klient, a serwery skonfigurowane na porcie 587 odrzucają połączenia, które nie przejdą na szyfrowane co oznacza, że szyfrowanie jest w praktyce wymuszane, mimo że początkowy handshake odbywa się w formie jawnej.
Najszersza kompatybilność ze wszystkich trzech portów
Port 587 nie jest blokowany przez dostawców internetu ani dostawców chmury tak jak port 25 i jest obsługiwany przez każdą znaczącą usługę pocztową (Gmail, Outlook, Yahoo) oraz każdego liczącego się dostawcę SMTP relay. Kiedy dostawca hostingu lub usługa e-mail publikuje swoje ustawienia SMTP, port 587 ze STARTTLS jest niemal zawsze główną rekomendacją.
Dla większości zastosowań obejmujących konfigurację CMS-a do wysyłki powiadomień, podłączenie usługi transakcyjnej, routing kampanii marketingowych przez SMTP relay czy ustawienie desktopowego klienta pocztowego, port 587 jest właściwym i domyślnym rozwiązaniem. Jeżeli nie masz konkretnego technicznego powodu żeby użyć czegoś innego, zacznij od niego.
Port 465: Implicit TLS i jego drugie życie
Port 465 posiada nietypową historię. W połowie lat 90. został na krótko przypisany do SMTP over SSL, a w 1998 roku IANA cofnęła tę decyzję kiedy STARTTLS na porcie 587 stał się preferowanym podejściem. Przez blisko dwie dekady ten port SMTP istniał w szarej strefie – oficjalnie nieuznany, ale wciąż obsługiwany przez wielu dostawców ponieważ działał, a użytkownicy wciąż go konfigurowali.
W 2018 r. RFC 8314 dał portowi 465 nowe życie, rekomendując go do submission poczty z implicit TLS. Różnica wobec portu 587 polega na tym, jak zaczyna się szyfrowanie.
Port 587 przechodzi na szyfrowanie
Połączenie zaczyna się nieszyfrowane i przełącza na TLS komendą STARTTLS. Działa to niezawodnie, ale istnieje krótkie okno przed przejściem, w którym źle skonfigurowany lub złośliwy pośrednik mógłby teoretycznie zaingerować.
Port 465 zaczyna zaszyfrowany
Handshake TLS następuje natychmiast po nawiązaniu połączenia, bez fazy plaintext i upgrade’u. To samo podejście, którego HTTPS używa dla ruchu webowego i które eliminuje teoretyczne ryzyko downgrade’u obecnego w przypadku STARTTLS.
Zasadniczo oba porty zapewniają silne szyfrowanie właściwej sesji. Różnica w bezpieczeństwie jest marginalna dla większości zastosowań bo dobrze skonfigurowane serwery na porcie 587 i tak odrzucą połączenia, które nie przejdą na szyfrowane. Przewaga portu 465 ujawnia się w środowiskach ze ścisłymi regułami firewall lub politykami sieciowymi, które ingerują w negocjację STARTTLS. Implicit TLS omija ten problem, ponieważ połączenie jest szyfrowane od pierwszego bajtu.
Szerokie, ale nie powszechne wsparcie
Gmail, Yahoo i większość dużych dostawców akceptuje submission na porcie 465. Część starszych lub bardziej konserwatywnie utrzymywanych serwerów pocztowych tego nie robi. Jeśli wybierasz między dwoma portami dla nowej konfiguracji i Twój dostawca obsługuje oba, port 465 jest nieco nowocześniejszym wyborem. Jeśli zależy Ci na maksymalnej kompatybilności między dostawcami, port 587 pozostaje bezpieczniejszym zakładem.
Który port wybrać i jak go skonfigurować
Decyzja jest prostsza niż sugeruje historia tych portów:
- Wysyłasz e-mail z aplikacji, klienta lub usługi → port 587 (STARTTLS) lub port 465 (implicit TLS). Oba wymagają uwierzytelnienia, oba szyfrują połączenie. Port 587 to bezpieczniejszy domyślny wybór pod kątem kompatybilności. Port 465 sprawdzi się lepiej, jeśli Twoje środowisko ma problemy z negocjacją STARTTLS albo chcesz szyfrowania od pierwszego bajtu.
- Masz serwer pocztowy, który odbiera pocztę od innych serwerów → port 25 dla przychodzącego relay. To jedyne pozostałe standardowe zastosowanie portu 25.
- Wysyłasz pocztę wychodzącą ze zwykłej aplikacji lub klienta → nigdy port 25. Zostanie zablokowany przez dostawcę internetu lub chmury, a nawet jeśli nie, brakuje mu warstwy uwierzytelniania, której wymaga faktyczna wysyłka.
Podstawowa konfiguracja SMTP
Proces wygląda tak samo niezależnie od dostawcy. Potrzebujesz czterech wartości: hosta SMTP (adres serwera dostawcy), numeru portu, metody szyfrowania (STARTTLS dla 587, SSL/TLS dla 465) i danych uwierzytelniających. Typowa konfiguracja wygląda tak:
- Host SMTP: smtp.twojdostawca.com
- Port: 587
- Szyfrowanie: STARTTLS
- Login: adres e-mail konta lub klucz API
- Hasło: hasło konta lub secret API
Po wpisaniu tych wartości wyślij wiadomość testową na zewnętrzny adres, nie do siebie w tej samej domenie, bo taka wiadomość może ominąć zewnętrzną ścieżkę dostarczania. Sprawdź nagłówki wiadomości pod kątem wskaźników TLS lub encrypted żeby potwierdzić, że połączenie było szyfrowane.
Jeśli wysyłka nie przejdzie, najczęstsze przyczyny to firewall blokujący port, błędne dane uwierzytelniające albo niezgodność między wybranym portem a metodą szyfrowania (STARTTLS na 465 lub SSL/TLS na 587 nie zadziała na większości serwerów).
💡 Jeszcze jedno: jeśli wysyłasz przez zewnętrzny SMTP relay lub usługę bulk email, upewnij się, że Twoje rekordy SPF, DKIM i DMARC uwzględniają ich infrastrukturę wysyłkową. Port doprowadza wiadomość do relay, ale to rekordy uwierzytelniające mówią serwerowi odbiorcy, żeby jej zaufał kiedy dotrze na miejsce.
Kiedy wysyłka przerasta pojedyncze połączenie SMTP
Właściwy port i uwierzytelnienie pozwalają zachować poprawną mechanikę wysyłki. Kiedy jednak skala Twoich kampanii rośnie – tysiące wiadomości transakcyjnych, kampanie marketingowe do dużych segmentów, wielokanałowe sekwencje łączące e-mail z SMS-em czy mobile pushem – pojedyncza konfiguracja SMTP przestaje wystarczać.
MessageFlow pozwala wysyłać e-mail przez API i SMTP zbudowane pod duży wolumen, z monitoringiem dostarczalności, obsługą odbić i możliwością dołożenia SMS-ów, RCS-ów i powiadomień push kiedy Twoje potrzeby komunikacyjne wykroczą poza sam e-mail. Odezwij się, pomożemy dopasować konfigurację do Twojego profilu wysyłki.
