WooCommerce nie wysyła maili o zamówieniach

Najczęściej mail wychodzi ze sklepu poprawnie - i ginie po drodze, bo serwer odbiorcy nie ma powodu mu ufać. To ważne rozróżnienie, bo zmienia kierunek szukania: zamiast grzebać w ustawieniach WooCommerce, trzeba sprawdzić, czym i z jakiego adresu sklep wysyła.

Objaw jest zawsze podobny. Zamówienia wpadają, w panelu wszystko widać, pieniądze przychodzą - ale klient dzwoni, że nie dostał potwierdzenia, a Ty dowiadujesz się o nowym zamówieniu dopiero po zajrzeniu do panelu. To najdroższa cicha awaria w sklepie: nie wywala strony, tylko zjada zaufanie i czas.

Poniżej rozkładam to na kolejność diagnozy, której sam używam, gdy dostaję takie zgłoszenie. Od przyczyny najczęstszej do najrzadszej, z konkretem, gdzie kliknąć.

Krok zerowy: ustal dokładnie, co nie działa

Zanim cokolwiek zmienisz, zawęź problem. Trzy pytania i trzy różne diagnozy:

Kto nie dostaje maila - klient, Ty, czy oboje? Jeśli tylko Ty, sprawa jest zwykle błaha (zły adres administratora albo filtr w Twojej skrzynce). Jeśli tylko klient - problem jest po stronie doręczalności. Jeśli oboje - sklep w ogóle nie wysyła.
Które powiadomienie - wszystkie czy jedno konkretne (np. „zamówienie w trakcie realizacji” chodzi, ale „zamówienie zrealizowane” nie)? Jedno konkretne wskazuje na ustawienia WooCommerce albo na status zamówienia, nie na wysyłkę.
Od kiedy - zawsze, czy od jakiegoś momentu? „Od zeszłej środy” prawie zawsze oznacza aktualizację wtyczki, zmianę na hostingu albo wygaśnięcie czegoś (klucz API, hasło do skrzynki).

Odpowiedzi na te trzy pytania skracają diagnozę o połowę. Zapisz je sobie, zanim ruszysz dalej.

Przyczyna numer jeden: sklep wysyła przez funkcję `mail()` w PHP

Domyślnie WordPress wysyła maile funkcją wp_mail(), która pod spodem korzysta z funkcji mail() w PHP. W praktyce oznacza to: serwer hostingowy wypuszcza wiadomość „od siebie”, bez uwierzytelnienia, z adresem nadawcy, którego nikt mu nie autoryzował.

Dziesięć lat temu to działało. Dziś Gmail, Outlook i większość poczty firmowej odrzuca albo wrzuca do spamu wiadomości, które nie mają poprawnego podpisu domeny. Efekt: WooCommerce raportuje, że wysłał, log hostingu potwierdza, że wysłał - a wiadomości nigdzie nie ma.

Rozpoznasz to po dwóch znakach: maile do adresów na tej samej domenie co sklep dochodzą, a do Gmaila nie; albo dochodzą, ale zawsze do spamu, z ostrzeżeniem o niezweryfikowanym nadawcy.

Co pomaga: wysyłka przez SMTP - czyli podpięcie sklepu pod prawdziwą skrzynkę pocztową, tak samo jak podpina się program pocztowy. Sklep wtedy loguje się do serwera poczty i wysyła jako uwierzytelniony nadawca. To rozwiązanie, które wdrażam w praktycznie każdym sklepie, który przechodzi przeze mnie - opisuję je niżej.

Przyczyna numer dwa: brak SPF, DKIM i DMARC dla domeny

To warstwa wyżej niż sam sposób wysyłki i najczęstszy powód, dla którego „mail wychodzi, ale nie dochodzi”. Trzy wpisy w DNS domeny mówią serwerom odbiorców, komu wolno wysyłać w Twoim imieniu:

SPF - lista serwerów, które mają prawo wysyłać maile z Twojej domeny
DKIM - podpis kryptograficzny, którym serwer nadawcy pieczętuje każdą wiadomość
DMARC - instrukcja, co odbiorca ma zrobić z wiadomością, która nie przeszła SPF ani DKIM

Jeśli sklep wysyła z adresu sklep@twojafirma.pl, a serwer hostingowy nie jest wpisany w SPF domeny, odbiorca widzi wiadomość podszywającą się pod Twoją firmę. I traktuje ją dokładnie tak, jak zasługuje.

Co pomaga: ustawienie SPF, DKIM i DMARC dla tego kanału, którym faktycznie wysyłasz. Jeśli używasz poczty Google Workspace, a sklep wysyła przez hosting - to dwa różne kanały i oba muszą być zadeklarowane. Sprawdzisz to, otwierając nagłówki dowolnej wiadomości ze sklepu w Gmailu („Pokaż oryginał”) i patrząc na trzy linijki: SPF, DKIM, DMARC. Mają być trzy razy PASS.

Przyczyna numer trzy: powiadomienie jest wyłączone w ustawieniach

Banalne, ale zdarza się częściej, niż powinno - zwłaszcza po zmianie motywu albo po pracach kogoś, kto „tylko coś sprawdzał”.

W panelu: WooCommerce → Ustawienia → E-maile. Zobaczysz listę wszystkich powiadomień: nowe zamówienie, zamówienie anulowane, zamówienie wstrzymane, zamówienie w trakcie realizacji, zamówienie zrealizowane, zwrot, faktura, reset hasła. Każde ma osobny przełącznik „Włącz to powiadomienie”.

Sprawdź przy okazji dwa pola na dole tej samej strony: „Nazwa nadawcy” i „Adres e-mail nadawcy”. Jeśli jest tam adres z innej domeny niż sklep - na przykład prywatny Gmail właściciela - to gotowa recepta na odrzucenie przez filtry. Adres nadawcy ma być na domenie sklepu.

Przyczyna numer cztery: zły adres odbiorcy powiadomień

Dotyczy sytuacji „klient dostaje, ja nie”. W tej samej sekcji WooCommerce → Ustawienia → E-maile, w powiadomieniu „Nowe zamówienie”, jest osobne pole „Odbiorcy”. Nie dziedziczy ono adresu administratora WordPressa automatycznie po każdej zmianie - potrafi zostać stary adres z czasów wdrożenia albo skrzynka byłego pracownika.

Wpisz tam aktualny adres. Możesz wpisać kilka, oddzielając przecinkami. Sprawdź też Ustawienia → Ogólne → Adres e-mail administracji - z niego idą powiadomienia systemowe WordPressa, w tym te o krytycznych błędach.

Przyczyna numer pięć: wtyczka przechwytuje albo blokuje wysyłkę

Kilka klas wtyczek wpina się w wysyłkę maili i potrafi ją zatrzymać:

Wtyczki SMTP źle skonfigurowane - zamiast naprawić wysyłkę, zabierają ją funkcji wp_mail() i próbują wysłać przez serwer, do którego nie mają poprawnego hasła. Efekt gorszy niż brak wtyczki.
Wtyczki „email log” w trybie testowym - część z nich ma opcję „zapisuj, ale nie wysyłaj”, włączoną kiedyś na czas testów i nigdy nie wyłączoną.
Wtyczki wydajnościowe i bezpieczeństwa blokujące połączenia wychodzące z serwera na porcie 465 lub 587.
Wtyczki do faktur i marketingu, które podmieniają szablon maila WooCommerce i przy okazji wywalają się na błędzie, przerywając wysyłkę w połowie.

Co pomaga: metoda połowienia. Wyłącz wszystkie wtyczki poza WooCommerce, złóż testowe zamówienie, sprawdź, czy mail doszedł. Jeśli tak - włączaj po kolei, sprawdzając po każdej. Robisz to na kopii albo poza godzinami sprzedaży, i zawsze po zrobieniu kopii zapasowej.

Przyczyna numer sześć: status zamówienia nie zmienia się tak, jak myślisz

WooCommerce nie wysyła maila „bo przyszło zamówienie”. Wysyła go, bo zamówienie zmieniło status. Jeśli płatność nie potwierdza się poprawnie, zamówienie utyka w statusie „oczekujące na płatność” - a dla tego statusu nie ma powiadomienia dla klienta. Zamówienie widać w panelu, maila nie ma i wszystko działa zgodnie z projektem.

To najczęstszy fałszywy trop w tej diagnozie. Sprawdzisz go w pół minuty: otwórz zamówienie, o które chodzi, i spójrz na jego status oraz na notatki po prawej stronie. Jeśli widzisz „oczekujące na płatność” albo notatkę o nieudanym powrocie z bramki - problem nie jest w mailach, tylko w komunikacji z operatorem płatności. Wtedy szukaj tam, gdzie trzeba: w konfiguracji bramki. Rozkładam to na czynniki w tekście o porzuconych koszykach z powodów technicznych i przy porównaniu bramek płatności.

Przyczyna numer siedem: cron i kolejka

WooCommerce część maili wysyła nie od razu, tylko przez wewnętrzną kolejkę zadań (Action Scheduler). Ta kolejka rusza, gdy ktoś wchodzi na stronę - a jeśli wp-cron jest wyłączony w wp-config.php i nikt nie ustawił zamiast niego prawdziwego crona na serwerze, zadania czekają w nieskończoność.

Objaw charakterystyczny: maile przychodzą, ale z wielogodzinnym opóźnieniem albo hurtem, kilka naraz.

Sprawdzisz to w WooCommerce → Status → Zaplanowane działania. Jeśli w zakładce „Oczekujące” wiszą pozycje z datą sprzed kilku godzin - kolejka stoi.

Co pomaga: wyłączenie wp-cron w pliku konfiguracyjnym i ustawienie w panelu hostingu prawdziwego crona, który odpala wp-cron.php co pięć minut. To standard w każdym sklepie z ruchem i przy okazji zdejmuje narzut z każdego wejścia na stronę.

Naprawa, która trzyma: wysyłka przez SMTP

Punkty od pierwszego do drugiego załatwia się jednym ruchem i to jest rozwiązanie, które w sklepie stawiam domyślnie.

Potrzebujesz skrzynki pocztowej na domenie sklepu - może być na hostingu, w Google Workspace, w Microsoft 365 albo u dostawcy wysyłek transakcyjnych. Do niej danych: serwer, port, login, hasło. Potem wtyczka SMTP w WordPressie i cztery pola do uzupełnienia.

Praktyczne uwagi z wdrożeń:

Nie używaj zwykłego hasła do skrzynki, jeśli dostawca daje hasło aplikacji. Google i Microsoft wymagają dziś osobnego hasła aplikacji przy włączonym dwuskładnikowym logowaniu. Zwykłe hasło po prostu nie zadziała.
Port 465 z szyfrowaniem SSL albo 587 z TLS. Jeśli hosting blokuje jeden, spróbuj drugiego - to najczęstsza przyczyna błędu „nie mogę połączyć się z serwerem SMTP”.
Adres nadawcy musi być tym samym adresem, na który się logujesz. Wysyłka jako kontakt@ przy logowaniu na sklep@ kończy się odrzuceniem przez sam serwer poczty.
Sprawdź limity dobowe. Skrzynka na współdzielonym hostingu ma zwykle limit rzędu kilkuset wiadomości na dobę. Przy sklepie z setką zamówień dziennie (a każde generuje kilka wiadomości) to za mało i wysyłka zatrzyma się w połowie dnia.
Hasło trzymaj poza bazą danych, jeśli wtyczka na to pozwala - w pliku wp-config.php. Baza wycieka częściej niż pliki.

Jak sprawdzić, że naprawa działa

Trzy testy, w tej kolejności, i dopiero po trzecim uznaję temat za zamknięty:

Test wysyłki z wtyczki SMTP - każda porządna ma przycisk „wyślij testowy mail”. Sprawdza samo połączenie z serwerem poczty. Wyślij na adres w innej domenie niż sklep, najlepiej Gmail.
Testowe zamówienie od początku do końca - z prawdziwym przejściem przez płatność (bramki mają tryb testowy) i ręczną zmianą statusu na „zrealizowane”. Sprawdzasz w ten sposób każdą wiadomość z osobna, nie tylko pierwszą.
Nagłówki wiadomości w Gmailu - otwórz mail ze sklepu, menu przy strzałce odpowiedzi, „Pokaż oryginał”. Trzy razy PASS przy SPF, DKIM i DMARC oznacza, że wiadomość jest wiarygodna dla każdego odbiorcy, nie tylko dla Twojej skrzynki.

Do tego jedna rzecz na stałe: włączony log wysyłanych maili. Wtedy przy następnym zgłoszeniu „nie dostałem potwierdzenia” w minutę widzisz, czy wiadomość w ogóle powstała, o której godzinie i pod jaki adres poszła. Bez logu każda taka rozmowa zaczyna się od zgadywania.

Kolejność diagnozy w pigułce

Ustal, kto nie dostaje, których powiadomień i od kiedy
Otwórz zamówienie i sprawdź jego status - jeśli „oczekujące na płatność”, szukaj w bramce, nie w mailach
WooCommerce → Ustawienia → E-maile: czy powiadomienie włączone, jaki adres nadawcy, jacy odbiorcy
Wyślij testowy mail i sprawdź, czy dochodzi na Gmaila oraz czy nie ląduje w spamie
Otwórz nagłówki: SPF, DKIM, DMARC - trzy razy PASS czy nie
WooCommerce → Status → Zaplanowane działania: czy kolejka nie stoi
Wyłącz wtyczki metodą połowienia i znajdź tę, która przechwytuje wysyłkę
Wdróż SMTP i uzupełnij wpisy DNS - to naprawa, po której problem nie wraca

Pierwsze pięć kroków to kwadrans. Jeśli po nich nadal nie wiadomo, gdzie ginie wiadomość, problem jest zwykle po stronie serwera albo dostawcy poczty - i tam trzeba zajrzeć w logi.

Kiedy oddać to komuś

Granica jest dość wyraźna. Włączenie powiadomienia, poprawa adresu nadawcy i podpięcie SMTP to rzeczy do zrobienia samodzielnie w godzinę, z instrukcją dostawcy poczty pod ręką.

Wpisy DNS, hasła aplikacji, limity wysyłki i konflikty wtyczek to już teren, na którym łatwo zrobić więcej szkody niż pożytku - błędny SPF potrafi zatrzymać także zwykłą pocztę firmową, nie tylko sklepową. Jeśli sklep sprzedaje codziennie, taniej wychodzi zlecić to niż testować na żywym organizmie.

To jest zresztą dokładnie ta klasa awarii, która nie powinna zdarzać się dwa razy - dlatego u klientów objętych stałą opieką log maili i monitoring wysyłki są elementem standardu, a nie dodatkiem.

Najczęstsze pytania

Dlaczego klient nie dostaje maila, a ja tak? Bo Wasze skrzynki oceniają wiadomość różnie. Twoja skrzynka jest zwykle na tej samej domenie co sklep i przepuszcza wszystko z własnego serwera. Skrzynka klienta - najczęściej Gmail - sprawdza SPF i DKIM i przy braku podpisu odrzuca albo wrzuca do spamu. To nie jest problem WooCommerce, tylko wiarygodności nadawcy.

Czy wtyczka SMTP wystarczy, czy trzeba jeszcze grzebać w DNS? Sama wtyczka rozwiązuje uwierzytelnienie i to zwykle wystarczy, żeby maile zaczęły dochodzić. Wpisy SPF i DKIM w DNS podnoszą doręczalność o kolejny poziom i chronią przed lądowaniem w spamie przy większych wysyłkach. Przy sklepie warto zrobić oba - kolejność: najpierw SMTP, potem DNS.

Sklep wysyłał maile, a przestał z dnia na dzień. Od czego zacząć? Od pytania, co się zmieniło tego dnia: aktualizacja wtyczek, zmiana hasła do skrzynki, zmiana hostingu, wygaśnięcie certyfikatu, przekroczony limit wysyłki. Najczęstszy sprawca w tym scenariuszu to zmienione hasło do skrzynki pocztowej - wtyczka SMTP nadal ma stare i cicho nie może się zalogować. Drugi w kolejności: aktualizacja, która zresetowała ustawienia. Kolejność sprawdzania i sposób bezpiecznego aktualizowania rozpisałem w checkliście bezpiecznych aktualizacji.

Czy da się wysyłać maile ze sklepu przez zwykłego Gmaila? Da się i przy małym sklepie to działa dobrze. Warunki: hasło aplikacji zamiast zwykłego hasła, adres nadawcy identyczny z adresem logowania i świadomość limitu dobowego. Przy większym ruchu limit zaczyna przeszkadzać i wtedy przechodzi się na dostawcę wysyłek transakcyjnych.

Czy klient dostanie maila, jeśli zamówienie zostało opłacone przelewem tradycyjnym? Tak, ale innego niż przy płatności online. Zamówienie z przelewem tradycyjnym trafia w status „wstrzymane” i wtedy klient dostaje wiadomość z danymi do przelewu. Potwierdzenie realizacji przychodzi dopiero, gdy ręcznie zmienisz status na „w trakcie realizacji” albo „zrealizowane”. Jeśli nikt tych statusów nie zmienia, klient nigdy nie dostanie potwierdzenia - i to nie jest awaria, tylko brak kroku w procesie.

Nie chcesz pilnować tego co miesiąc samemu? Biorę strony i sklepy pod stałą opiekę - backupy, aktualizacje, monitoring i priorytet, kiedy coś padnie. Napisz, co masz pod sobą, a odeślę zakres i cenę.

WooCommerce nie wysyła maili o zamówieniach - diagnoza i naprawa