WordPress nie wysyła e-maili — jak znaleźć przyczynę | TopHostings.pl

Gdy WordPress „nie wysyła e-maili”, problem może występować na kilku różnych etapach. Formularz może w ogóle nie wywołać wysyłki, wp_mail() może zakończyć się błędem, serwer może nie mieć prawidłowo skonfigurowanego transportu poczty, a wiadomość może też zostać przyjęta do wysyłki, lecz później trafić do spamu albo zostać odrzucona po drodze.

Dlatego diagnostyka powinna zacząć się od odpowiedzi na jedno pytanie: na którym etapie zatrzymała się wiadomość?

„WordPress nie wysyła maili” to objaw, a nie jedna awaria. Najpierw trzeba rozdzielić problem aplikacji od problemu transportu i dostarczalności.

Na którym etapie zatrzymała się wiadomość?

Najprostszy model diagnostyczny ma pięć etapów:

aplikacja generuje wiadomość,
wp_mail() przekazuje ją do PHPMailera,
PHPMailer przekazuje wiadomość do lokalnego MTA albo zewnętrznego relay/SMTP,
serwer odbiorcy przyjmuje lub odrzuca wiadomość,
po przyjęciu system odbiorcy klasyfikuje wiadomość, na przykład jako Inbox lub Spam.

Objaw	Bardziej prawdopodobny obszar
Formularz nie uruchamia żadnej wysyłki	Wtyczka, konfiguracja formularza, kod WordPressa
`wp_mail()` zwraca błąd	PHPMailer, konfiguracja transportu, dane nadawcy
WordPress zgłasza sukces, ale wiadomości nie ma	MTA/SMTP, serwer odbiorcy, dalsza dostarczalność
Serwer odbiorcy odrzuca wiadomość	SMTP, polityka odbiorcy, reputacja lub autoryzacja nadawcy
Wiadomość została przyjęta, ale trafia do spamu	Dostarczalność, reputacja, SPF, DKIM, DMARC, treść

Co naprawdę mówi wynik wp_mail()?

Gdy wysyłka zwraca sukces

WordPress wysyła wiadomości przez funkcję wp_mail(), która korzysta z PHPMailera. Zwrócenie wartości true oznacza, że mechanizm wysyłkowy przetworzył żądanie bez błędu na tym etapie. Nie jest to potwierdzenie, że wiadomość dotarła do skrzynki odbiorcy.

Hook wp_mail_succeeded również nie potwierdza dostarczenia wiadomości — oznacza jedynie, że metoda wysyłająca przetworzyła próbę bez błędu.

Jeżeli wp_mail() działa, a odbiorca niczego nie dostaje, dalsza diagnostyka powinna przejść z WordPressa do warstwy transportu i dostarczalności.

Gdy PHPMailer zgłasza błąd

WordPress udostępnia hook wp_mail_failed, który otrzymuje obiekt WP_Error po przechwyceniu wyjątku PHPMailera.

Do tymczasowej diagnostyki można logować sam komunikat błędu zamiast wyświetlać go publicznie:

add_action( 'wp_mail_failed', function ( $error ) {
    error_log( $error->get_error_message() );
} );

Taki kod powinien być traktowany jako narzędzie diagnostyczne. Nie należy pozostawiać rozbudowanego logowania danych wiadomości bez kontroli, ponieważ e-mail może zawierać dane użytkowników.

Transport poczty: PHP mail, MTA i SMTP

WordPress przygotowuje wiadomość, ale sam nie dostarcza jej bezpośrednio do skrzynki odbiorcy. wp_mail() korzysta z PHPMailera, który następnie przekazuje wiadomość do odpowiednio skonfigurowanego systemu pocztowego.

W domyślnej konfiguracji WordPress korzysta z mechanizmu PHP mail(), który wymaga działającego środowiska pocztowego po stronie serwera. Na hostingu współdzielonym zwykle zapewnia je operator. Na samodzielnie zarządzanym serwerze administrator musi skonfigurować MTA albo zewnętrzny relay.

Kiedy SMTP pomaga

Zewnętrzny SMTP może rozwiązać problem, jeśli lokalne środowisko pocztowe hostingu nie działa, jest źle skonfigurowane albo nie zapewnia odpowiedniej kontroli nad nadawcą.

Nie naprawi jednak funkcji, która w ogóle nie dochodzi do wp_mail(). Błędny adres odbiorcy, wyłączone powiadomienie albo warunek w kodzie pozostaną błędne niezależnie od transportu.

Sprawdź From i Reply-To

Adres From: powinien należeć do domeny autoryzowanej dla używanego transportu pocztowego — zwykle domeny strony albo odpowiednio skonfigurowanej subdomeny wysyłkowej.

W formularzach lepiej rozdzielić role:

From: — adres autoryzowany dla używanego transportu,
Reply-To: — adres osoby wysyłającej formularz.

Ustawienie w From: przypadkowego adresu użytkownika, na przykład z Gmaila, może powodować konflikt z polityką domeny nadawcy i pogorszyć dostarczalność.

Gdy nie działa tylko jeden typ wiadomości

Jeśli reset hasła działa, ale formularz kontaktowy nie wysyła powiadomień, transport WordPressa prawdopodobnie nie jest całkowicie martwy. Wtedy warto sprawdzić samą funkcję, która miała wygenerować wiadomość.

Czy formularz rzeczywiście kończy zapis bez błędu?
Czy powiadomienie jest włączone?
Czy adres odbiorcy jest poprawny?
Czy nie działa warunek wyłączający wysyłkę?
Czy plugin nie zapisuje własnego błędu?
Czy wiadomość nie jest wysyłana asynchronicznie?

To samo dotyczy WooCommerce, systemów rezerwacji i własnego kodu. Wspólny transport może działać, a pojedynczy moduł nadal nie generować wiadomości.

Jeżeli nie działają wyłącznie wiadomości opóźnione lub cykliczne, trzeba sprawdzić również mechanizm harmonogramu. Może to być WP-Cron albo kolejka konkretnej wtyczki. W WooCommerce wiele operacji w tle wykorzystuje Action Scheduler, który utrzymuje własną kolejkę zadań i współpracuje z mechanizmami uruchamiania zadań WordPressa.

Logi pokazują, na której warstwie zatrzymała się wiadomość

Najbardziej użyteczna diagnostyka łączy informacje z kilku miejsc:

log WordPressa lub pluginu generującego wiadomość,
wp_mail_failed,
log PHP,
log lokalnego MTA albo SMTP, jeśli jest dostępny,
log zewnętrznego dostawcy poczty.

Jeżeli potrzebujesz uporządkować diagnostykę po stronie PHP i WordPressa, zobacz poradnik o error_log i debug.log.

Sam brak błędu w debug.log nie dowodzi, że wiadomość dotarła. WordPress może poprawnie przekazać ją dalej, a problem może wystąpić już poza PHP.

Coraz mocniejszym tropem infrastrukturalnym jest sytuacja, w której żadna część WordPressa nie potrafi wysłać wiadomości, PHPMailer zgłasza błąd transportu, a kilka niezależnych aplikacji na tym samym koncie ma ten sam problem. W takim przypadku warto sprawdzić konfigurację usługi pocztowej hostingu albo dostępnego SMTP relay.

Wiadomość wyszła, ale nie dotarła

Jeżeli WordPress lub SMTP potwierdza poprawne przekazanie wiadomości, dalsza diagnoza dotyczy już transportu i dostarczalności.

Sprawdź:

czy serwer odbiorcy wiadomość przyjął,
czy pojawił się bounce,
czy adres nadawcy jest poprawny,
czy domena ma poprawnie skonfigurowane SPF, DKIM i DMARC,
czy wiadomość nie została zakwalifikowana jako spam.

Na tym etapie znaczenie mają m.in. SPF, DKIM, DMARC, reputacja nadawcy i treść wiadomości. Przyjęcie wiadomości przez serwer odbiorcy nadal nie oznacza umieszczenia jej w Inbox.

Jeżeli wiadomości wychodzą, ale trafiają do spamu, dalszą diagnostykę opisuje poradnik Dlaczego e-maile trafiają do spamu mimo SPF, DKIM i DMARC?.

Praktyczna procedura diagnozy

Wybierz jeden konkretny przypadek. Formularz, reset hasła, zamówienie albo powiadomienie systemowe.
Sprawdź, czy funkcja faktycznie wywołuje wysyłkę.
Zobacz, czy pojawia się błąd wp_mail_failed.
Jeżeli WordPress zgłasza sukces, sprawdź kolejną warstwę: MTA lub SMTP.
Zweryfikuj From i Reply-To.
Jeżeli używasz SMTP, sprawdź log lub wynik testu połączenia.
Porównaj z innym typem wiadomości z tej samej instalacji.
Jeśli wysyłka działa tylko natychmiastowo, sprawdź cron lub kolejkę.
Jeżeli wiadomość została przyjęta do wysyłki, przejdź do diagnostyki dostarczalności i klasyfikacji Inbox/Spam.
Zmieniaj jedną rzecz naraz.

Przy zgłoszeniu do hostingu lub dostawcy SMTP warto podać dokładny czas testu, adres nadawcy, domenę odbiorcy oraz techniczny komunikat błędu. Nie trzeba przesyłać całej treści wiadomości, jeśli nie jest potrzebna do diagnozy.

Najważniejsze wnioski

wp_mail() zwracające sukces nie potwierdza dostarczenia wiadomości do skrzynki odbiorcy;
WordPress przygotowuje wiadomość, ale potrzebuje prawidłowo skonfigurowanej warstwy transportu;
wp_mail_failed pozwala przechwycić część błędów PHPMailera;
SMTP może poprawić sposób wysyłki, ale nie naprawi funkcji, która w ogóle nie generuje wiadomości;
From: powinien być zgodny z domeną autoryzowaną dla używanego transportu, a Reply-To: może wskazywać autora formularza;
jeżeli działa reset hasła, a nie działa tylko formularz, problem nie musi dotyczyć całego systemu pocztowego;
wiadomości planowane mogą zależeć od WP-Cron, Action Scheduler lub kolejki konkretnej aplikacji;
po prawidłowym przekazaniu wiadomości do serwera dalsza diagnoza dotyczy transportu, dostarczalności i klasyfikacji Inbox/Spam;
SPF, DKIM i DMARC nie uruchamiają samej wysyłki — pomagają na późniejszym etapie uwierzytelnienia i dostarczalności.

Źródła

WordPress Developer Resources — wp_mail() — działanie funkcji i znaczenie wyniku wysyłki.
WordPress Developer Resources — wp_mail_succeeded — znaczenie sukcesu metody wysyłającej.
WordPress Developer Resources — wp_mail_failed — obsługa błędów PHPMailera.
WordPress Developer Resources — phpmailer_init — konfiguracja obiektu PHPMailer i transportu.
WordPress Developer Resources — wp_mail_from — konfiguracja adresu nadawcy.
WordPress Developer Resources — wp_mail_from_name — nazwa nadawcy.
WordPress Advanced Administration Handbook — Mail — relacja WordPressa z MTA/SMTP oraz podstawy dostarczalności.
Action Scheduler — Documentation — kolejka zadań używana m.in. przez WooCommerce i inne wtyczki WordPress.