Porty SMTP w 2026: 587 vs 465 vs 25 – co wybrać, żeby maile z WordPressa naprawdę dochodziły

Jeśli utrzymujesz stronę (zwłaszcza na WordPressie), to znasz ten scenariusz: formularz kontaktowy niby wysyła, WooCommerce generuje potwierdzenia, użytkownik klika „reset hasła”… a w skrzynce odbiorczej cisza. To nie jest drobna niedogodność – to realna strata leadów i zaufania.

W praktyce „cichym winowajcą” jest prawie zawsze domyślna konfiguracja wysyłki po stronie serwera WWW. Taka wysyłka wygląda dla Gmaila czy Outlooka podejrzanie, jak typowy spam. Najskuteczniejsza droga to przełączenie się na profesjonalny kanał SMTP (Simple Mail Transfer Protocol) i… wybranie właściwego portu.

Najważniejsze wnioski (TL;DR dla zabieganych)

• Szybka odpowiedź: używaj portu 587 z szyfrowaniem STARTTLS. To współczesny, rekomendowany standard do wysyłki (submission) z aplikacji/strony.
• Dobra alternatywa: port 465 z SMTPS (implicit SSL/TLS) – popularny i bezpieczny, część dostawców go preferuje. Jeśli 587 nie działa, 465 to najczęściej najlepszy drugi wybór.
• Port, którego należy unikać: nigdy nie używaj portu 25 do wysyłki z witryny (email submission). Jest niezaszyfrowany, przeznaczony do komunikacji serwer–serwer i masowo blokowany przez ISP oraz hostingi.
• Prawdziwy problem: domyślna wysyłka WordPressa (np. wp_mail()) jest nieautoryzowana i wychodzi z serwera WWW bez reputacji pocztowej, więc filtry antyspamowe traktują ją jak ryzyko.
• Prawdziwe rozwiązanie: wysyłaj e-maile przez dedykowaną usługę SMTP/transactional (np. SendGrid, Brevo, Mailgun), która ma reputację i wspiera uwierzytelnianie.
• Najprostsza opcja w WordPressie: wtyczka „zero konfiguracji”, taka jak Site Mailer by Elementor, potrafi ominąć domyślny mechanizm i routować e-maile transakcyjne bez grzebania w portach, API key czy DNS.
• Transakcyjne vs marketingowe: SMTP/transactional jest do e-maili transakcyjnych (hasła, zamówienia, formularze). Newslettery i masówkę wysyłaj przez osobną platformę do e-mail marketingu (ESP), żeby nie zniszczyć reputacji domeny.

Czym jest SMTP i dlaczego ma znaczenie dla Twojej strony?

SMTP (Simple Mail Transfer Protocol) to zestaw reguł, według których klienci pocztowi (Outlook, Apple Mail) i serwery pocztowe wysyłają oraz przekazują e-maile. Najprościej: to „poczta wychodząca” internetu.

Gdy wysyłasz wiadomość, nie trafia ona bezpośrednio do odbiorcy. Typowy przepływ wygląda tak:

1. Twoja aplikacja/klient pocztowy wysyła wiadomość do serwera poczty wychodzącej (to etap submission).
2. Ten serwer znajduje serwer odbiorcy i przekazuje mu wiadomość (to etap relay).
3. Serwer odbiorcy przechowuje wiadomość, aż użytkownik otworzy skrzynkę.

„Port SMTP” to po prostu numerowane wejście (port) na serwerze, przez które odbywa się ten proces. Wybór portu determinuje m.in. sposób szyfrowania i zgodność z praktykami antyspamowymi.

Problem WordPressa: wp_mail() i domyślna wysyłka z serwera WWW

Domyślnie WordPress nie wysyła maili przez SMTP. Używa funkcji wp_mail(), która próbuje nadać wiadomość bezpośrednio z serwera WWW. Dla dostarczalności (deliverability) to proszenie się o kłopoty:

1. To nie jest serwer pocztowy: serwer WWW jest zoptymalizowany do serwowania stron, a nie do wysyłania poczty i utrzymywania reputacji nadawczej.
2. Brak uwierzytelnienia: serwer „twierdzi”, że wysyła z Twojej domeny, ale bez silnych mechanizmów potwierdzenia uprawnień nadawcy.
3. Brak reputacji: duzi dostawcy (Gmail, Microsoft) oceniają reputację znanych serwerów pocztowych. Serwer WWW zwykle takiej reputacji nie ma, więc jest podejrzany.
4. Współdzielone IP i zła „dzielnica”: na shared hostingu jeden spamer może spowodować blacklistę IP, a wtedy cierpią też legalne strony.

Efekt jest przewidywalny: e-mail ląduje w spamie albo jest odrzucany po cichu. Dlatego sensowna naprawa polega na ominięciu wp_mail() i wysyłce przez profesjonalnego dostawcę SMTP/transactional.

Krótka historia portów SMTP (i dlaczego część z nich to dziś relikt)

Żeby zrozumieć, czemu w 2026 r. realnie wybierasz między 587 i 465, warto znać kontekst. Ewolucja portów SMTP to w dużej mierze odpowiedź internetu na spam i brak szyfrowania.

Port 25 – oryginał z 1982 i „autostrada spamu”

Na początku był tylko port 25. Został zaprojektowany do przekazywania poczty pomiędzy serwerami (MTA, czyli Mail Transfer Agents). Bez uwierzytelnienia, bez szyfrowania, „każdy z każdym”.

Problem pojawił się szybko: spamerzy zaczęli łączyć się z serwerami przez port 25 i przekazywać masowo niechcianą pocztę. To był idealny kanał nadużyć.

Współcześnie, właśnie przez tę historię, większość ISP, dostawców chmury i hostingów blokuje ruch wychodzący na porcie 25 (outbound). Chodzi o odcięcie botów i przejętych maszyn od łatwej wysyłki spamu.

Port 465 – SMTPS i szyfrowanie „od pierwszego bajtu” (implicit TLS)

Pod koniec lat 90. zaczęto rozwiązywać problem szyfrowania. Tak powstał port 465 z podejściem SMTPS (SMTP over SSL, dziś mówimy raczej o TLS). Połączenie od razu zestawia tunel szyfrujący – zanim polecą komendy SMTP. To tzw. Implicit SSL/TLS.

Choć port 465 przez pewien czas był traktowany jako rozwiązanie nie do końca standardowe (i bywał „deprecated” na rzecz STARTTLS), finalnie wrócił do łask. Dziś jest powszechnie używany i uznawany za bezpieczny – duzi gracze (w tym Gmail) nadal go rekomendują.

Port 587 – oficjalny standard wysyłki (submission) i STARTTLS (explicit TLS)

Żeby uporządkować standardy, IETF (organizacja tworząca standardy internetowe) wskazał port 587 jako port do email submission (czyli dokładnie tego, co robi Twoja strona lub klient pocztowy).

Na porcie 587 najczęściej używa się STARTTLS (czyli Explicit TLS). Mechanika wygląda tak:

1. Aplikacja łączy się z serwerem na porcie 587 początkowo w trybie plain text.
2. Wysyła komendę „EHLO”.
3. Serwer odpowiada listą możliwości, m.in. informacją, że obsługuje „STARTTLS”.
4. Aplikacja wysyła komendę „STARTTLS” i „podnosi” połączenie do tunelu TLS.
5. Dopiero w zaszyfrowanym kanale idą dane uwierzytelniające i treść wiadomości.

W 2026 r. serwer, który na porcie 587 nie wymusza szyfrowania, jest po prostu traktowany jako niebezpieczny. Natomiast sam port 587 pozostaje najbardziej uniwersalnym i rekomendowanym wyborem.

Port 2525 – nieoficjalny, ale bywa ratunkiem (fallback)

Czasem spotkasz też port 2525. To nie jest oficjalny port SMTP z punktu widzenia standardów, tylko popularna alternatywa oferowana przez część hostingów i dostawców SMTP jako „awaryjne wejście”.

Kiedy ma sens? Gdy hosting blokuje zarówno 587, jak i 465 (rzadkie, ale możliwe – szczególnie na niektórych platformach chmurowych, które próbują ograniczać spam z własnej infrastruktury). Zwykle 2525 działa podobnie jak 587 i też opiera się o STARTTLS.

Werdykt na 2026: który port SMTP wybrać?

Domyślnie: port 587 + STARTTLS

To pierwszy wybór. Jest oficjalnym standardem do wysyłki (submission), jest powszechnie wspierany przez dostawców usług SMTP i jest „najbardziej oczekiwany” przez narzędzia oraz wtyczki.

Alternatywnie: port 465 + SMTPS (implicit SSL/TLS)

Jeśli 587 nie działa (np. blokada po stronie hostingu) albo dostawca wyraźnie zaleca 465, to ten port jest równie sensowny i bardzo popularny. Różni się głównie sposobem zestawienia szyfrowania (od razu, bez „upgrade” STARTTLS).

Prawie nigdy: port 25

Nie do wysyłki z witryny. Jest blokowany i nie zapewnia szyfrowania. Jego współczesna rola to przede wszystkim przekazywanie maili między serwerami (relay), nie przez aplikacje webowe.

Porównanie portów SMTP (ściąga)

• 25 – SMTP, brak bezpieczeństwa, zastosowanie: relay serwer–serwer, rekomendacja dla strony: NIE (blokowany przez hostingi/ISP).
• 465 – SMTPS, Implicit SSL/TLS, zastosowanie: submission klient/strona → serwer, rekomendacja: TAK (bezpieczny i powszechny).
• 587 – SMTP z STARTTLS (Explicit TLS), zastosowanie: submission klient/strona → serwer, rekomendacja: TAK (najbardziej zalecany standard).
• 2525 – SMTP zwykle z STARTTLS, zastosowanie: submission (fallback), rekomendacja: tylko gdy 587/465 są zablokowane.

Jak naprawić wysyłkę e-maili w WordPressie – instrukcja krok po kroku

Skoro porty są jasne, przechodzimy do wdrożenia. Poniżej masz proces, który w praktyce rozwiązuje większość problemów z deliverability w WordPressie.

Krok 1: wybierz dedykowanego dostawcę SMTP (transactional)

Najpierw przestajesz wysyłać z serwera WWW i zakładasz konto u dostawcy, który żyje z dostarczalności wiadomości transakcyjnych.

• Co robią tacy dostawcy: udostępniają serwery o wysokiej reputacji do wysyłki przez SMTP albo API (często oba warianty).
• Popularne usługi: SendGrid, Brevo (dawniej Sendinblue), Mailgun, Postmark (znany z bardzo wysokiej dostarczalności), Amazon SES (mocny, ale bardziej złożony), Google Workspace / Gmail (da się użyć dla małego wolumenu, ale w biznesie łatwo wpaść w limity wysyłki).

Wiele planów darmowych wystarcza w zupełności dla małej i średniej strony firmowej, o ile mówimy o e-mailach transakcyjnych.

Krok 2: skonfiguruj DNS domeny – SPF i DKIM

To najważniejszy techniczny etap. Sam dostawca SMTP nie „magicznie” nie uratuje reputacji, jeśli domena nie autoryzuje wysyłki. Musisz dodać rekordy DNS, które mówią światu: „ta usługa ma prawo wysyłać maile w moim imieniu”.

Dostawca poda Ci dokładne rekordy do wklejenia w DNS (u rejestratora domeny lub operatora DNS).

• SPF (Sender Policy Framework): rekord TXT działający jak lista dozwolonych nadawców. Informuje serwery odbiorcze, że maile z Twojej domeny są poprawne tylko, jeśli pochodzą z określonych IP/serwerów (np. Twojego i SendGrid). Chroni przed spoofingiem (podszywaniem się).
• DKIM (DomainKeys Identified Mail): rekord TXT z kluczem publicznym, który pozwala zweryfikować podpis cyfrowy wiadomości. Dostawca podpisuje e-mail kluczem prywatnym, a serwer odbiorcy sprawdza podpis kluczem z DNS. To dowód, że wiadomość nie została zmieniona po drodze.

Krok 3: zainstaluj i skonfiguruj wtyczkę SMTP w WordPressie

Teraz trzeba przełączyć WordPressa na nowy kanał wysyłki. Najprościej robi się to wtyczką, która przechwytuje wp_mail() i przekierowuje wysyłkę do wybranego dostawcy.

• Popularne wtyczki: WP Mail SMTP, FluentSMTP, Post SMTP.

Ogólny schemat konfiguracji (w większości wtyczek wygląda podobnie):

1. Zainstaluj i aktywuj wtyczkę SMTP.
2. Wejdź w ustawienia w kokpicie WordPressa.
3. Wybierz „Mailer” (czyli dostawcę), np. SendGrid.
4. Wprowadź dane dostępowe:
5. – Najlepiej przez API: wtyczki często wspierają API key, które jest wygodniejsze i bezpieczniejsze.
6. – Alternatywnie przez SMTP credentials (tryb „Other SMTP”), jeśli API nie jest dostępne.
7. Jeśli konfigurujesz SMTP ręcznie, ustaw parametry:
8. – SMTP Host (np. smtp.sendgrid.net, Google: smtp.gmail.com) – dostawca zawsze to podaje.
9. – Encryption: wybierz TLS (czyli STARTTLS). Jeśli widzisz opcję „SMTPS/SSL”, to będzie wariant dla portu 465.
10. – SMTP Port: wpisz 587 dla TLS/STARTTLS albo 465 dla SMTPS/SSL.
11. – Authentication: włączone (ON).
12. – SMTP Username i SMTP Password: zgodnie z panelem dostawcy.
13. Ustaw „From Email” oraz „From Name”: adres nadawcy powinien być w Twojej uwierzytelnionej domenie (tej, dla której ustawiłeś SPF/DKIM).

Krok 4: test i logi

Dobre wtyczki mają zakładkę „Test Email”. Wyślij test na prywatny adres w Gmailu lub Outlooku.

• Jeśli trafia do inboxa: konfiguracja jest poprawna, a kanał wysyłki jest wiarygodny.
• Jeśli wpada do spamu: najpierw wróć do SPF/DKIM i pamiętaj, że propagacja DNS może potrwać kilka godzin.
• Jeśli wysyłka się nie udaje: to zwykle błąd portu lub danych dostępowych. Sprawdź host/port/login/hasło. Jeśli używałeś 587, przetestuj 465 (i odwrotnie).

„Proste” rozwiązanie: gdy platforma/wtyczka robi to za Ciebie

Powyższe kroki są normalne dla osoby technicznej, ale dla wielu właścicieli biznesów to zbyt dużo: domena tu, DNS tam, dostawca SMTP, wtyczka, porty, klucze API… Nic dziwnego, że powstają rozwiązania zintegrowane, które zdejmują ten ciężar z użytkownika WordPressa.

Opcja 1: zintegrowana wysyłka transakcyjna (bez konfiguracji)

Jeśli kluczowym problemem jest brak autoryzacji i kiepska dostarczalność domyślnej wysyłki WordPressa, to najprościej jest ją ominąć bez całej ręcznej orkiestracji.

Tak działa Site Mailer by Elementor: wtyczka typu „zero konfiguracji”.

• Jak to działa: instalujesz i aktywujesz – i na tym kończy się setup.
• Co robi: automatycznie przekierowuje e-maile transakcyjne z witryny (formularze, WooCommerce, reset hasła itp.) przez usługę o wysokiej dostarczalności i uwierzytelnianiu.
• Dlaczego bywa wygodniejsze: nie musisz zakładać konta w SendGrid/Brevo, zarządzać API key, ustawiać SPF/DKIM ani wybierać portu. W praktyce ma to po prostu zacząć działać od razu.

Opcja 2: managed hosting, który nie przeszkadza (porty otwarte, sensowne środowisko)

Drugi częsty problem to hosting, który zbyt agresywnie blokuje ruch wychodzący lub utrudnia wdrożenie dobrych praktyk. Zarządzane środowiska pod WordPressa zwykle rozumieją, że wp_mail() jest niewystarczający i powinny umożliwiać użycie portów takich jak 587.

W tym kontekście w źródle pada przykład Elementor Hosting – hostingu opartego o infrastrukturę chmurową, gdzie jednym z założeń jest zapewnienie warunków do poprawnej integracji z usługami mailowymi (np. dostępność portu 587 pod wtyczkę SMTP).

Poza SMTP: absolutnie kluczowe rozróżnienie (transakcyjne vs marketingowe)

Gdy już naprawisz wysyłkę, łatwo popełnić błąd, który potrafi zrujnować reputację domeny.

E-mail transakcyjny (wysyłaj przez SMTP/transactional)

• Reset hasła
• Potwierdzenia zamówienia
• Potwierdzenia wysłania formularza
• Rejestracje użytkowników
• E-maile powitalne

To wiadomości 1:1, wywołane akcją użytkownika. Są oczekiwane i zwykle krytyczne – muszą trafić do inboxa.

E-mail marketingowy (wysyłaj przez ESP)

• Newslettery cykliczne
• Promocje sezonowe
• Ogłoszenia o nowym produkcie
• Wysyłki do dużych list odbiorców

To wysyłka 1:wielu. Nawet jeśli lista jest opt-in, pojawią się wypisy i skargi na spam. Jeśli zrobisz to przez kanał transakcyjny, reputacja domeny spadnie i finalnie ucierpią też maile transakcyjne (np. resety haseł zaczną lądować w spamie). Dlatego marketing ma swoje wyspecjalizowane platformy (Mailchimp, ConvertKit itd.), które separują reputację, wypisy i analitykę od krytycznej komunikacji systemowej.

Rekomendowana strategia e-mail dla strony w 2026

E-mail ze strony to jej głos. Domyślna wysyłka WordPressa jest jak szept w huraganie – ginie bez śladu. SMTP z pełnym uwierzytelnieniem SPF i DKIM daje stronie wyraźny, wiarygodny głos, którego dostawcy skrzynek chcą słuchać.

Itamar Haim (cyt. za źródłem)

W praktyce sensowna strategia składa się z trzech elementów:

1. Stabilna baza: hosting, który nie blokuje wdrożenia dobrych praktyk (w szczególności sensownej integracji z usługami mailowymi).
2. Wiarygodny kanał transakcyjny: albo rozwiązanie „zero konfiguracji” (np. Site Mailer by Elementor), albo klasycznie: wtyczka typu WP Mail SMTP + dostawca (np. SendGrid) i port 587.
3. Osobny kanał marketingowy: dedykowana platforma ESP do newsletterów i masówek, żeby nie ryzykować reputacją domeny używaną przez transakcje.

Podsumowanie: przestań gubić e-maile i zacznij budować zaufanie

Pytanie „jaki port SMTP wybrać?” jest ważne, ale jest tylko pierwszym krokiem. W 2026 r. domyślna odpowiedź brzmi: 587 + STARTTLS (a gdy trzeba: 465 + SMTPS).

Największa zmiana polega jednak na tym, żeby przestać polegać na wp_mail() i przejść na uwierzytelnioną wysyłkę przez profesjonalnego dostawcę. Gdy dołożysz poprawne rekordy DNS (SPF i DKIM) oraz dobrze skonfigurujesz wtyczkę, e-maile systemowe przestają być loterią – stają się przewidywalnym kanałem komunikacji z użytkownikami.

FAQ: najczęstsze pytania o porty SMTP i WordPressa

1) Jaka jest najprostsza odpowiedź – którego portu SMTP używać?

Używaj portu 587 z STARTTLS. Jeśli to nie działa, najlepsza alternatywa to port 465 z SMTPS (SSL/TLS).

2) Dlaczego nie powinienem używać portu 25?

Port 25 to historyczny, nieszyfrowany port SMTP (z 1982 r.), który był masowo nadużywany do spamu. W efekcie jest dziś blokowany przez większość ISP i dostawców hostingu/chmury, więc wysyłka z aplikacji zwykle nie zadziała.

3) Czym różni się 587 (STARTTLS) od 465 (SMTPS)?

Oba warianty są bezpieczne. 465 używa Implicit TLS – szyfrowanie startuje natychmiast po połączeniu. 587 używa Explicit TLS – połączenie zaczyna się jawnie i dopiero komenda STARTTLS „podnosi” je do TLS. Port 587 jest współczesnym standardem rekomendowanym do submission, ale oba działają.

4) Co to jest „e-mail transakcyjny”?

To wiadomość 1:1 wywołana akcją użytkownika na stronie: wysyłka formularza, reset hasła, rejestracja konta, potwierdzenie zamówienia w eCommerce. Takie maile powinny iść przez dedykowaną usługę SMTP/transactional.

5) Czym różni się e-mail transakcyjny od marketingowego?

Marketingowy to wysyłka 1:wielu (newsletter, promocje, ogłoszenia). Do tego używa się osobnej platformy ESP, żeby nie niszczyć reputacji domeny i nie wpływać na dostarczalność maili transakcyjnych.

6) SPF i DKIM – co to jest i czy naprawdę muszę to ustawić?

Tak, to konieczne. To rekordy DNS potwierdzające legalność nadawcy. SPF określa, które serwery mogą wysyłać w imieniu domeny. DKIM to podpis cyfrowy, który pozwala odbiorcy sprawdzić, czy wiadomość nie została zmieniona. Bez nich Twoja poczta będzie wyglądała jak spam.

7) Wtyczka SMTP pyta o „Host” – co to znaczy?

„Host” to adres serwera SMTP Twojego dostawcy, np. smtp.sendgrid.net dla SendGrid albo smtp.gmail.com dla Google. Konkretne wartości dostajesz w panelu usługi.

8) Czy mogę użyć zwykłego konta Gmail do wysyłki maili ze strony?

Technicznie tak, ale nie jest to zalecane. To zwykle oznacza trzymanie danych logowania w WordPressie (ryzyko bezpieczeństwa) oraz wpadanie w limity wysyłki. Przy skokach ruchu Google może tymczasowo zablokować wysyłkę. Lepiej użyć dedykowanego dostawcy.

9) Jaki jest najłatwiejszy sposób na naprawę wszystkich problemów z pocztą w WordPressie?

Najprostszą metodą jest użycie wtyczki „zero konfiguracji”, takiej jak Site Mailer by Elementor, która instaluje się jednym kliknięciem i przejmuje routowanie oraz deliverability bez konfiguracji portów, API i usług zewnętrznych.

10) Jak sprawdzić, czy konfiguracja SMTP działa poprawnie?

Wtyczki takie jak WP Mail SMTP mają sekcję „Test Email”. Wyślij wiadomość testową z kokpitu WordPressa na swój adres. Jeśli trafia do inboxa, konfiguracja jest poprawna.