WooCommerce nie wysyła maili - 7 przyczyn i jak to naprawić w 2026

Brak maila nie wskazuje jednej przyczyny. Sklep może nie uruchomić powiadomienia, nie przekazać go do transportu albo wysłać wiadomość, której odbiorca nie zobaczy. Rozdziel te etapy, zanim zainstalujesz kolejną wtyczkę SMTP. Inaczej możesz zmienić działający element, a właściwy błąd pozostanie.

Zapisz typ wiadomości, przybliżony czas zdarzenia i informację, czy problem dotyczy klienta, administratora czy obu odbiorców. Sprawdź notatki zamówienia, status i ostatnie zmiany w sklepie. Jeżeli dochodzi reset hasła WordPress, a nie dochodzi konkretny email WooCommerce, transport może działać, lecz nie jest to jeszcze pełny dowód poprawności jego konfiguracji.

Nie zmieniaj statusów prawdziwych zamówień tylko po to, aby wymusić maila. Taka operacja może uruchomić inne automatyzacje, wpłynąć na stany albo wysłać dodatkowe powiadomienia. Do odtworzenia problemu przygotuj kontrolowaną kopię, testowy odbiornik i wyłączone integracje produkcyjne. Nie używaj danych klientów jako materiału testowego.

WooCommerce uruchamia wiadomości przy określonych zdarzeniach. Samo istnienie zamówienia w panelu nie oznacza, że każda wiadomość powinna już zostać wysłana. Dokumentacja diagnostyki emaili zaleca najpierw sprawdzić status i warunki wysyłki. Zamówienie oczekujące na płatność różni się od opłaconego, przetwarzanego zamówienia.

Jeśli pieniądze dotarły, ale status nadal wskazuje oczekiwanie, sprawdź notatki i komunikację bramki płatniczej. Przyczyną może być niepotwierdzona zmiana statusu, a nie konfiguracja SMTP. Nie oznaczaj płatności ręcznie bez ustalenia, co wydarzyło się u operatora i w sklepie.

Porównaj oczekiwany email z jego wyzwalaczem oraz działaniem użytej metody płatności. Rozszerzenia mogą zmieniać standardowy przebieg. Zapisz również, czy błąd zaczął się po aktualizacji bramki, zmianie adresu strony lub ochrony serwera. W szerszej diagnozie przyda się poradnik problemów WooCommerce.

Otwórz WooCommerce > Ustawienia > E-maile i przejdź do konkretnego typu powiadomienia. Sprawdź, czy jest włączony i kto ma go otrzymać. Wiadomość administracyjna o nowym zamówieniu oraz wiadomość klienta mają odrębne konfiguracje. Poprawna wysyłka jednej nie potwierdza ustawień drugiej.

Zweryfikuj literówki, aktualność adresu odbiorcy i ograniczenia dodane przez rozszerzenia. Nie podmieniaj adresu klienta w prawdziwym zamówieniu na potrzeby próby. Jeżeli wiadomość jest warunkowa, sprawdź warunek przed uznaniem braku wysyłki za awarię.

Aktualna dokumentacja WooCommerce opisuje źródło transactional-emails w WooCommerce > Status > Logi. Wyróżnia cztery wyniki: sent, failed, disabled i skipped. Disabled wskazuje wyłączony typ, a skipped brak warunku potrzebnego do wysyłki, np. odbiorcy. Dostępność oraz szczegółowość tych logów sprawdź w swojej wersji. Przy braku wpisów zobacz też ustawienia retencji i próg poziomu logowania, zamiast od razu zakładać brak zdarzenia.

Jeżeli warunki wysyłki są spełnione, sprawdź błędy z czasu zdarzenia. Własny szablon emaila, fragment kodu lub rozszerzenie może przerwać przygotowanie treści. W takim przypadku dostawca poczty nie otrzyma poprawnej wiadomości, więc jego konfiguracja nie naprawi źródła problemu.

Zwróć uwagę na nadpisane szablony w motywie i ich zgodność z używaną wersją WooCommerce. Nie usuwaj ich bez kopii. Najpierw porównaj zachowanie z domyślnym szablonem na środowisku testowym. Zmieniaj jeden element naraz, aby móc wskazać, po której zmianie błąd znika.

Nie wyłączaj wszystkich wtyczek na czynnym sklepie. Mogą odpowiadać za płatności, dostawy i zgodność zamówień z systemem magazynowym. Przy błędzie serwera zobacz także diagnostykę błędu 500. Do zgłoszenia wystarczy komunikat i czas; przed przekazaniem logu usuń adresy klientów, identyfikatory sesji oraz dane uwierzytelniające.

Gdy wiadomość powstaje, przejdź do mechanizmu wysyłania. Sprawdź, która wtyczka lub konfiguracja faktycznie obsługuje wp_mail(), czy konto jest aktywne i jaki błąd zwraca dostawca. Nie uruchamiaj równocześnie kilku wtyczek zmieniających ten sam transport.

Host, port, szyfrowanie i sposób uwierzytelnienia dobierz według operatora. Port 587 z STARTTLS i 465 z TLS nie są wymiennymi ustawieniami, które warto losowo przełączać. Nie używaj zwykłego hasła konta, jeśli dostawca wymaga OAuth, klucza API lub innego mechanizmu. Sekrety przechowuj w przeznaczonej konfiguracji, nie w artykule, zgłoszeniu czy publicznym repozytorium.

WordPress wyjaśnia: "A true return value does not automatically mean that the user received the email successfully." (wp_mail()). Sukces funkcji oznacza więc inny etap niż odbiór przez klienta. Dokładniejszy opis transportu znajdziesz w poradniku SMTP WordPress. Timeout wymaga sprawdzenia połączenia i logów; sam nie dowodzi blokady hostingu.

Sprawdź adres From oraz domenę, w imieniu której dostawca wysyła wiadomości. Nie wpisuj adresu klienta jako nadawcy sklepu. Do odpowiedzi można użyć osobnego Reply-To, ale nie zastępuje to poprawnego uwierzytelnienia domeny wysyłającej.

Rekordy SPF i DKIM pobierz od rzeczywistego dostawcy. Uwzględnij innych uprawnionych nadawców domeny, zamiast dopisywać drugi przypadkowy rekord SPF. DMARC ocenia między innymi zgodność domeny widocznego From z uwierzytelnioną domeną SPF lub DKIM. Samo użycie funkcji wp_mail() nie przesądza, czy ta konfiguracja jest poprawna.

Wymagania Gmail rozróżniają wszystkich i masowych nadawców. Dla pierwszych wymagane jest SPF lub DKIM, a przy ponad 5000 wiadomości dziennie do Gmail również zestaw SPF, DKIM i DMARC. Nie przenoś tego progu na każdego operatora. Ustawienia domeny nie dają gwarancji inbox; trzeba sprawdzić nagłówki odebranej wiadomości i wynik po stronie dostawcy, bez publikowania danych odbiorcy.

W panelu dostawcy sprawdź statusy odpowiadające danemu zdarzeniu: przyjęcie, odroczenie, odrzucenie lub blokadę adresu. Zwróć uwagę na limit planu, stan konta i listę adresów, do których operator nie ponawia wysyłki. Nie obchodź takiej blokady przez masowe powtarzanie wiadomości.

Jeżeli operator przyjął email, sprawdź folder spam, reguły skrzynki i ewentualne przekazywanie poczty. Przyjęcie przez serwer odbiorcy także nie gwarantuje widoczności w głównym folderze. Nie oceniaj naprawy wyłącznie na podstawie zielonego komunikatu w WordPressie.

Limity mają znaczenie także w małym sklepie. Według cennika odczytanego 12 września 2026 Mailgun Free obejmuje 100 wiadomości dziennie i jeden dzień logów. Brevo Free ma 300 wysyłek dziennie bez przenoszenia niewykorzystanej puli. Licz wszystkie wiadomości konta, nie tylko potwierdzenia zamówień. Bezpłatny plan nie jest gwarancją wystarczającego limitu ani dostarczalności.

Nie każdy email w każdej wersji WooCommerce przechodzi przez Action Scheduler. Zależy to od używanej wersji, aktywnych funkcji i rozszerzeń. Jeżeli wiadomości są odroczone, sprawdź konkretną kolejkę, hook, termin wykonania i zapisany błąd. Sama liczba nieudanych zadań nie wskazuje przyczyny problemu pocztowego.

Bieżący kod WC_Emails w repozytorium WooCommerce zawiera warunek dla odroczonych wiadomości. To ruchoma gałąź rozwojowa, nie opis każdej zainstalowanej wersji. Nie wdrażaj zmian kolejki na podstawie fragmentu kodu dla innego wydania.

Nie kasuj zbiorczo zadań Failed i nie uruchamiaj wszystkiego ponownie. Możesz usunąć ślad błędu albo zdublować powiadomienia. Najpierw ustal, czy wskazane zadanie rzeczywiście odpowiada za brakujący email i czy jego ponowienie jest bezpieczne. Podobnie nie wyłączaj WP-Cron, dopóki nie potwierdzisz działającego mechanizmu zastępczego.

Potwierdzenie naprawy powinno obejmować cały właściwy przebieg: zdarzenie, przygotowanie wiadomości, przekazanie transportowi i wynik u kontrolowanego odbiorcy. Sprawdź oddzielnie typy emaili, których dotyczyła awaria. Test resetu hasła nie zastępuje sprawdzenia powiadomienia o zamówieniu.

Wyniki zapisz bez danych klientów: typ wiadomości, czas, etap i rezultat. Jeżeli brakuje logów historycznych, zaznacz to w diagnozie. Nie zamieniaj przypuszczenia w pewne wyjaśnienie tylko dlatego, że po kilku zmianach problem chwilowo zniknął.

Możesz zlecić naprawę WordPressa i sklepu lub sprawdzić zakres wsparcia WordPress. Napisz do nas, podając adres sklepu i rodzaj niedochodzącej wiadomości. To wystarczy na pierwszy kontakt. Wersje, godzina zdarzenia i oczyszczone logi pomogą później. Zakres pracy zależy od miejsca awarii, dlatego termin określamy po ustaleniu przyczyny i potrzebnych dostępów.