Sklep nie wysyła maili z potwierdzeniem zamówienia – ścieżka diagnostyczna

Zamówienie jest w panelu. Pieniądze są na koncie. A klient pisze, że nie dostał żadnego potwierdzenia i pyta, czy jego przelew w ogóle doszedł.

To jedna z tych awarii, które nie wyglądają na awarię. Sklep działa, strona się ładuje, płatności przechodzą, nic nie krzyczy „błąd krytyczny”. Dlatego problem z pocztą wychodzi zwykle najgorszą możliwą drogą: z reklamacji, z pytania na czacie, albo z opinii wystawionej przez klienta, który przez trzy dni nie wiedział, czy jego zamówienie istnieje.

Zła wiadomość jest taka, że przyczyn może być kilkanaście. Dobra, że da się je odsiać w kilkanaście minut, jeśli zacznie się od właściwego pytania. Poniżej ścieżka, którą przechodzę przy takich zgłoszeniach.

Zanim cokolwiek klikniesz: trzy pytania

Odpowiedzi na te trzy pytania odcinają zwykle trzy czwarte możliwych przyczyn.

1. Kto nie dostaje maili?

• Tylko klient. Problem najprawdopodobniej po stronie dostarczalności lub adresu nadawcy.
• Tylko Ty (powiadomienia administratora). Sprawdź w pierwszej kolejności adres odbiorcy w ustawieniach i sposób, w jaki hosting obsługuje pocztę do własnej domeny.
• Nikt. Problem jest po stronie wysyłki, nie odbioru. To najczęstszy wariant i zwykle najprostszy do naprawy.

2. Nie działa jeden rodzaj maila czy wszystkie?

Jeśli nie dochodzi wyłącznie „Zamówienie w trakcie realizacji”, a maile o zresetowaniu hasła docierają bez problemu, to poczta działa, a problem siedzi w WooCommerce. Jeśli nie działa nic, łącznie z resetem hasła, problem jest na poziomie serwera.

3. Od kiedy?

I co się wtedy wydarzyło. Prawie zawsze coś się wydarzyło:

• migracja na inny hosting,
• zmiana serwera poczty, na przykład przejście na Google Workspace,
• aktualizacja WordPressa, WooCommerce albo motywu,
• nowa wtyczka, zwłaszcza do bezpieczeństwa, cache lub mailingu,
• zmiana rekordów DNS domeny,
• skopiowanie sklepu ze środowiska testowego.

Ostatni punkt bywa zaskakująco częsty i wrócę do niego niżej.

Krok kluczowy: czy WordPress w ogóle próbował wysłać ten mail?

To jest zawias całej diagnostyki. Wszystko, co robisz dalej, zależy od odpowiedzi, a bez niej można spędzić dwa dni na poprawianiu rekordów DNS, podczas gdy problem polega na tym, że powiadomienie jest po prostu wyłączone.

Zainstaluj wtyczkę logującą pocztę. Wystarczy dowolna z darmowych: FluentSMTP ma log wbudowany, WP Mail Logging robi to samo w oderwaniu od konfiguracji SMTP. Potem złóż testowe zamówienie i sprawdź log.

Gałąź A: w logu nie ma nic. WordPress nawet nie spróbował wysłać wiadomości. Problem jest wewnątrz sklepu. Przejdź do sekcji „Gałąź A”.

Gałąź B: w logu jest wpis ze statusem „wysłano”. WordPress przekazał wiadomość serwerowi i uznał sprawę za załatwioną. To, że wiadomość nie dotarła, dzieje się dalej, już poza WordPressem. Przejdź do sekcji „Gałąź B”.

Ten jeden test oszczędza więcej czasu niż cała reszta artykułu.

Gałąź A: WordPress nie wysyła

A1. Sprawdź status zamówienia (najczęstszy fałszywy alarm)

Zanim uznasz, że masz problem z pocztą, sprawdź, czy zamówienie w ogóle osiągnęło status, który wywołuje wysyłkę maila.

WooCommerce nie wysyła potwierdzenia „bo pojawiło się zamówienie”. Wysyła je przy przejściu na konkretny status:

Status zamówienia	Co dostaje klient
Oczekiwanie na płatność (pending)	nic
Wstrzymane (on-hold)	mail o oczekiwaniu na płatność, jeśli włączony
W trakcie realizacji (processing)	właściwe potwierdzenie zamówienia
Zrealizowane (completed)	mail o zrealizowaniu
Anulowane / Nieudane	powiadomienie do administratora

Teraz najważniejsze: jeśli bramka płatnicza nie odsyła do sklepu informacji o zaksięgowaniu, zamówienie zostaje w statusie „Oczekiwanie na płatność” na zawsze, mimo że pieniądze są na koncie. Mail nie wychodzi, bo z punktu widzenia sklepu nic się nie stało.

To nie jest awaria poczty. To źle skonfigurowany adres powiadomień (webhooka) w panelu operatora płatności, jeden z najczęstszych błędów wdrożeniowych w ogóle. Objaw jest charakterystyczny: klient zapłacił, Ty widzisz przelew, a zamówienie wisi jako nieopłacone.

Jeśli tak to u Ciebie wygląda, zajrzyj do wpisu Jak skonfigurować płatności w WooCommerce. Sekcja o adresie powiadomień rozwiązuje ten problem.

Podobnie przy przelewie tradycyjnym: zamówienie ląduje we „Wstrzymane” i klient dostaje mail z danymi do przelewu, a nie potwierdzenie realizacji. To działa prawidłowo, tylko rzadko kto o tym pamięta.

A2. Ustawienia e-maili w WooCommerce

WooCommerce → Ustawienia → E-maile.

Sprawdź po kolei:

• czy dane powiadomienie ma status włączone, bo wystarczy, że ktoś kiedyś odznaczył jeden checkbox,
• adres odbiorcy przy powiadomieniach administratora, bo po migracji potrafi tam zostać adres poprzedniego właściciela albo agencji,
• adres „od” i nazwę nadawcy (wrócę do tego w gałęzi B, bo to częsta przyczyna problemów z dostarczalnością),
• czy szablon nie został nadpisany pustym plikiem.

A3. Nadpisane szablony w motywie

Motywy i wtyczki mogą podmieniać szablony maili, umieszczając własne pliki w katalogu twoj-motyw/woocommerce/emails/. Jeśli po aktualizacji WooCommerce taki szablon przestał być zgodny z nową wersją, mail może wychodzić pusty albo nie wychodzić wcale.

Szybki test: przełącz tymczasowo na domyślny motyw (Storefront albo Twenty Twenty-Something) i złóż testowe zamówienie. Jeśli mail przyszedł, masz winowajcę. Rób to na kopii testowej, nie na żywym sklepie.

A4. Konflikt wtyczek

Klasyczny test: wyłącz wszystkie wtyczki poza WooCommerce, sprawdź, włączaj po jednej. Uciążliwe, ale rozstrzygające.

Najczęściej winne są:

• wtyczki bezpieczeństwa blokujące wysyłkę „na wszelki wypadek”,
• wtyczki do mailingu przejmujące funkcję wp_mail(),
• wtyczki optymalizacyjne wyłączające zdarzenia cron,
• wtyczki „do wyłączania powiadomień”, zainstalowane kiedyś na potrzeby testów i zapomniane.

Znowu: na środowisku testowym. Wyłączanie wtyczek na działającym sklepie w środku dnia to prosta droga do sytuacji opisanej we wpisie Jak naprawić błąd krytyczny WordPress.

A5. WP-Cron

Część zdarzeń w WooCommerce (opóźnione zmiany statusu, powiadomienia od wtyczek, przypomnienia o porzuconym koszyku) wykonuje się przez harmonogram WordPressa. WP-Cron uruchamia się przy wejściu użytkownika na stronę, więc w sklepie z małym ruchem potrafi po prostu nie zadziałać. Bywa też wyłączony wpisem DISABLE_WP_CRON w wp-config.php, zwykle w ramach optymalizacji, po której nikt nie skonfigurował crona systemowego.

Objaw diagnostyczny: maile przychodzą, ale z ogromnym opóźnieniem albo paczkami, na przykład wtedy, gdy ktoś odwiedzi sklep. To niemal na pewno cron.

Sprawdzisz to wtyczką WP Crontrol, która pokazuje zaległe zadania. Rozwiązaniem jest wyłączenie WP-Crona i ustawienie zadania systemowego w panelu hostingu, uruchamianego co 5 do 15 minut.

A6. Sklep skopiowany ze środowiska testowego

Środowiska testowe mają zwykle zablokowaną wysyłkę poczty po to, żeby testowe zamówienia nie zasypały prawdziwych klientów. Blokada bywa zapisana w bazie danych albo w pliku konfiguracyjnym.

Jeśli sklep produkcyjny powstał przez skopiowanie środowiska testowego, blokada mogła pojechać razem z nim. To wygląda dokładnie jak awaria, a jest niedokończoną migracją. Warto sprawdzić w pierwszej kolejności, jeśli poczta „nigdy nie działała”. Skoro nigdy nie działała, to nie jest awaria, tylko brakujący etap wdrożenia.;

Gałąź B: WordPress wysyła, ale wiadomości nie dochodzą

Tu wchodzimy w temat, który sprowadza się do jednego zdania: WordPress ze standardową konfiguracją nie jest serwerem pocztowym i nie zachowuje się jak nadawca, któremu ktokolwiek ufa.

B1. Funkcja mail(), czyli źródło większości problemów

Domyślnie WordPress wysyła pocztę przez funkcję mail() z PHP. Wiadomość wychodzi bezpośrednio z serwera WWW, zwykle bez uwierzytelnienia i często z adresu nadawcy, który nie ma nic wspólnego z Twoją domeną. Coś w rodzaju wordpress@serwer123.hostingodawca.pl.

Dla filtrów antyspamowych taka wiadomość wygląda jak próba podszycia się pod cudzą domenę. Efekt jest jeden z trzech:

1. wiadomość ląduje w spamie,
2. wiadomość zostaje odrzucona z komunikatem błędu,
3. wiadomość zostaje cicho porzucona, i to jest najgorszy wariant, bo w logu sklepu widnieje „wysłano”, a odbiorca nie dostaje nic i nie ma żadnego śladu.

Wariant trzeci jest przyczyną większości zgłoszeń typu „u nas wszystko wygląda dobrze, a klienci nie dostają maili”.

Rozwiązanie jest jedno i opisuję je niżej: przejście na SMTP.

B2. Adres nadawcy na cudzej domenie

Sprawdź, co masz ustawione jako adres „od”. Jeśli jest tam adres w domenie, której nie kontrolujesz, na przykład @gmail.com, @wp.pl albo @o2.pl, masz gwarantowany problem. Gmail od dawna traktuje wiadomości podszywające się pod swoje adresy bardzo restrykcyjnie i taka konfiguracja po prostu nie ma prawa działać.

Osobny, wyjątkowo częsty wariant tego błędu dotyczy formularzy kontaktowych: adresem nadawcy ustawionym jest adres osoby wypełniającej formularz. Wiadomość wygląda wtedy dla filtrów jak podszywanie się pod klienta.

Zasada: adres nadawcy zawsze w Twojej domenie. Adres klienta trafia do pola „odpowiedz do” (Reply-To), nigdy do „od”.

B3. SPF, DKIM i DMARC

Trzy rekordy w DNS domeny, które razem odpowiadają na pytanie „czy ten serwer ma prawo wysyłać pocztę w imieniu tej domeny”.

• SPF: lista serwerów uprawnionych do wysyłki z Twojej domeny.
• DKIM: podpis kryptograficzny potwierdzający, że wiadomość rzeczywiście pochodzi od Ciebie i nie została zmieniona po drodze.
• DMARC: instrukcja, co zrobić z wiadomością, która nie przejdzie powyższych testów, plus raporty o tym, kto wysyła pocztę w Twoim imieniu.

To już nie jest opcjonalne. Google wymaga skonfigurowania SPF i DKIM oraz poprawnych rekordów DNS (w tym PTR) i połączenia TLS. DMARC jest formalnie obowiązkowy dla nadawców masowych, czyli powyżej 5 000 wiadomości dziennie, i mocno zalecany dla wszystkich pozostałych. Microsoft poszedł tą samą drogą: wiadomości niespełniające wymagań uwierzytelnienia są odrzucane błędem SMTP 550 5.7.515.

Jedna rzecz, która myli najczęściej: poprawny SPF i DKIM to nie to samo co zgodność z DMARC. Zgodność wymaga, żeby domena widoczna w polu „od” odpowiadała domenie zweryfikowanej przez SPF lub DKIM. Można mieć wszystkie trzy rekordy i wciąż nie przechodzić weryfikacji, jeśli wysyłasz z subdomeny albo przez zewnętrznego dostawcę skonfigurowanego po łebkach.

Dobra wiadomość dla sklepów: potwierdzenia zamówień to poczta transakcyjna, więc wymóg jednokliknięciowego wypisu (List-Unsubscribe) ich nie dotyczy. Obejmuje wyłącznie wiadomości marketingowe.

Konfiguracja tych rekordów zajmuje kilkanaście minut, o ile masz dostęp do DNS domeny. Weryfikację zrobisz darmowym narzędziem typu mail-tester.com: wysyłasz na wskazany adres i dostajesz raport z punktacją oraz listą braków.

B4. Poczta na tej samej domenie, ale na innym serwerze

Bardzo charakterystyczny objaw: klienci dostają maile normalnie, a Ty nie dostajesz powiadomień administratora, mimo że adres jest poprawny.

Przyczyna: skrzynka firmowa jest w Google Workspace albo Microsoft 365, ale hosting sklepu uznaje, że skoro domena jest „jego”, to pocztę do niej dostarcza lokalnie. Wiadomość trafia do skrzynki na hostingu, do której nikt nigdy nie zagląda, i nigdy nie opuszcza serwera.

Rozwiązanie: w panelu hostingu przełącz obsługę poczty dla domeny na zewnętrzną (szuka się tego zwykle pod hasłem „zdalny serwer poczty” albo „obsługa MX poza serwerem”). Alternatywnie wysyłaj powiadomienia przez SMTP zewnętrznego dostawcy, co ten problem obchodzi całkowicie.

B5. Limity hostingu

Hostingi współdzielone limitują wysyłkę, typowo od kilkudziesięciu do kilkuset wiadomości na godzinę. Przy normalnym ruchu to bez znaczenia, ale w dniu kampanii, wyprzedaży albo przy jednorazowym mailingu limit potrafi zostać wyczerpany w kwadrans. Wiadomości transakcyjne, które akurat wtedy powinny wyjść, przepadają razem z resztą.

Warto sprawdzić limit u swojego dostawcy i pamiętać, że masowa wysyłka nigdy nie powinna iść tym samym kanałem co potwierdzenia zamówień.

B6. Spam, ale u Ciebie

Zanim ogłosisz awarię, sprawdź folder Spam, zakładkę „Oferty” w Gmailu i własne reguły filtrowania. Zdarza się, że wszystko działa, a reguła utworzona pół roku temu przenosi powiadomienia do archiwum.

Rozwiązanie docelowe: SMTP zamiast mail()

Niezależnie od tego, którą przyczynę u siebie znajdziesz, konfiguracja poczty w sklepie powinna docelowo wyglądać tak samo. Sklep nie wysyła poczty sam, tylko przekazuje ją uwierzytelnionemu serwerowi, który robi to zawodowo.

Krok 1. Wybierz kanał wysyłki.

• Skrzynka na hostingu przez SMTP. Najprościej, wystarczy przy kilkudziesięciu wiadomościach dziennie. Wymaga tylko danych dostępowych do skrzynki.
• Dostawca poczty transakcyjnej (Brevo, Mailgun, Postmark, Amazon SES, Resend). Lepszy przy większym wolumenie. Daje logi, statystyki dostarczenia, powiadomienia o odbiciach i dużo lepszą reputację nadawcy. Darmowe progi zwykle w zupełności wystarczają małemu sklepowi.
• Google Workspace lub Microsoft 365 przez SMTP. Działa, ale ma niskie limity dzienne i nie jest projektowane pod pocztę transakcyjną.

Krok 2. Zainstaluj wtyczkę SMTP. FluentSMTP jest darmowa i w pełni wystarczająca. Alternatywy: WP Mail SMTP, Post SMTP.

Krok 3. Wpisz dane serwera: host, port (zwykle 587 z TLS), login, hasło. Hasło trzymaj w wp-config.php, nie w bazie danych.

Krok 4. Ustaw adres nadawcy w swojej domenie i zaznacz wymuszanie go dla wszystkich wiadomości, inaczej wtyczki będą podstawiać własne.

Krok 5. Dodaj SPF i DKIM według instrukcji wybranego dostawcy. Potem DMARC, choćby w trybie samego raportowania.

Krok 6. Wyślij test i sprawdź wynik w mail-tester.com. Cel: SPF, DKIM i DMARC ze statusem „pass”.

Krok 7. Włącz logowanie i alert. To najważniejszy krok, który wszyscy pomijają. Log poczty z powiadomieniem o nieudanej wysyłce sprawia, że o problemie dowiadujesz się Ty, a nie klient.

Krok 8. Rozdziel pocztę transakcyjną od marketingowej. Newsletter wysyłany tym samym kanałem co potwierdzenia zamówień oznacza, że jedna nieudana kampania psuje reputację nadawcy i zabiera ze sobą wiadomości, które muszą dochodzić zawsze. Jeśli prowadzisz sekwencje odzyskujące koszyki, opisane we wpisie Jak zmniejszyć porzucone koszyki w WooCommerce, tym bardziej warto je rozdzielić.

Test po naprawie

Nie kończ na jednym mailu do siebie. Minimalny zestaw:

• testowe zamówienie każdą metodą płatności osobno: przelew tradycyjny, BLIK, karta, pobranie,
• sprawdzenie, czy zamówienie osiąga status „W trakcie realizacji” automatycznie,
• wysyłka na cztery różne domeny: Gmail, Outlook, WP.pl lub O2, plus dowolna firmowa,
• podgląd nagłówków odebranej wiadomości, gdzie szukasz spf=pass, dkim=pass, dmarc=pass,
• reset hasła klienta,
• powiadomienie administratora o nowym zamówieniu.

Test na własnej skrzynce firmowej niczego nie dowodzi, bo poczta do własnej domeny często dostarczana jest inną ścieżką niż do świata zewnętrznego.

Jak nie wrócić do tego problemu

Poczta w sklepie psuje się cicho i zwykle przy okazji czegoś innego. Trzy nawyki wystarczą.

Log poczty włączony na stałe. Retencja 30 dni wystarcza. Kosztuje tyle co nic, a przy następnym zgłoszeniu masz odpowiedź w minutę zamiast w dwie godziny.

Alert przy nieudanej wysyłce. Wtyczki SMTP potrafią wysłać powiadomienie na zapasowy adres, gdy wysyłka się nie powiedzie.

Test kontrolny co kwartał i po każdej większej zmianie. Migracja hostingu, zmiana DNS, aktualizacja WooCommerce, nowa wtyczka bezpieczeństwa: po każdej z tych rzeczy jedno testowe zamówienie. To dwie minuty.

To dokładnie ten typ rzeczy, który wchodzi w zakres stałej opieki nad sklepem. Nie dlatego, że jest trudny, tylko dlatego, że nikt o nim nie pamięta, dopóki nie przestanie działać.

Najczęstsze pytania

Klient zapłacił, ale zamówienie ma status „Oczekiwanie na płatność”. To problem z mailami? Nie. To problem z komunikacją między bramką płatniczą a sklepem, zwykle błędny adres powiadomień w panelu operatora. Mail nie wychodzi, bo sklep nie wie, że płatność została zaksięgowana. Naprawa konfiguracji płatności rozwiązuje przy okazji problem z pocztą.

Czy wtyczka SMTP jest bezpieczna? Tak, pod warunkiem że hasło do skrzynki trzymasz w wp-config.php, a nie w bazie danych. Przy dostawcy poczty transakcyjnej używasz klucza API, który da się w każdej chwili unieważnić bez zmiany hasła do skrzynki, więc to rozwiązanie bezpieczniejsze.

Maile dochodzą, ale zawsze do spamu. Co dalej? To już nie problem wysyłki, tylko reputacji nadawcy. Kolejność działań: SPF i DKIM ze statusem „pass”, DMARC, adres nadawcy w Twojej domenie, rozdzielenie poczty transakcyjnej od marketingowej. Jeśli po tym nadal ląduje w spamie, sprawdź, czy Twoja domena albo adres IP hostingu nie trafiły na listę blokowanych.

Czy potrzebuję płatnego dostawcy poczty? Przy kilkudziesięciu zamówieniach dziennie zwykle nie, bo skrzynka na hostingu przez SMTP wystarczy. Płatny dostawca zaczyna mieć sens, gdy potrzebujesz statystyk dostarczenia, obsługi odbić i pewności, że mailing nie zabierze ze sobą potwierdzeń zamówień.

Czy maile transakcyjne wymagają linku „wypisz się”? Nie. Wymóg jednokliknięciowego wypisu dotyczy wiadomości marketingowych i promocyjnych. Potwierdzenia zamówień, powiadomienia o wysyłce i resety hasła są z niego wyłączone. Uwierzytelnienie SPF i DKIM obowiązuje natomiast jedne i drugie.

Naprawiłem, a po miesiącu przestało działać ponownie. Najczęstsze przyczyny nawrotu: zmiana hasła do skrzynki bez aktualizacji w konfiguracji SMTP, wygaśnięcie klucza API, zmiana DNS przy okazji innych prac, albo aktualizacja wtyczki, która nadpisała ustawienia. Log poczty i alert przy błędzie pokażą to następnym razem od razu.

Podsumowanie

Jeśli miałbyś zapamiętać z tego tekstu trzy rzeczy:

1. Najpierw sprawdź log poczty. Rozstrzygnięcie, czy WordPress w ogóle próbował wysłać wiadomość, dzieli problem na pół i oszczędza godziny.
2. Sprawdź status zamówienia, zanim uznasz, że to awaria poczty. Zamówienie wiszące jako nieopłacone mimo zaksięgowanej płatności to problem konfiguracji bramki, nie maili.
3. Docelowo zawsze SMTP z uwierzytelnieniem i poprawnym SPF oraz DKIM. Wysyłka przez mail() działa dopóty, dopóki filtry antyspamowe mają dobry humor, a mają go coraz rzadziej.