---
title: "WooCommerce nie wysyła maili: 535 i wp_mail() true | ASAPDevs"
description: "Maile z WooCommerce przestały wychodzić: błąd 535 w SMTP, wp_mail() zwraca true, brak haka wp_mail_failed i pułapka opcache po zmianie hasła w wp-config.php."
url: https://asapdevs.it/blog/woocommerce-maile-nie-wychodza-535-smtp
last_updated: 2026-10-12
---

# WooCommerce nie wysyła maili: 535 Incorrect authentication data i wp\_mail() zwracające true

Dwa sklepy przez kilka dni nie wysłały żadnego maila, dwanaście zamówień bez potwierdzenia. Sześć odrzuconych hipotez, oś czasu z logów i dlaczego po zmianie hasła strona dalej używała starego.

Jeśli sklep WooCommerce przestał wysyłać maile, a w logach SMTP stoi `535 Incorrect authentication data`, serwer pocztowy odrzuca login lub hasło skrzynki zapisane w `wp-config.php`. Standardowo `wp_mail()` przy błędzie SMTP zwraca `false` i uruchamia hak `wp_mail_failed`, ale w naszych sklepach część ścieżek wysyłki zwracała `true` mimo odrzuconego logowania, więc sklep wyglądał na zdrowy, a klienci nie dostawali potwierdzeń zamówień. Poniżej opisujemy, jak wygląda taka awaria na dwóch sklepach, które hipotezy odrzuciliśmy i dlaczego po zmianie hasła strona dalej używała starego.

## Jak wygląda awaria wysyłki maili w WooCommerce?

Klient zgłosił, że maile nie docierają. Potwierdziliśmy, że dwa sklepy na jednym serwerze nie wysyłają żadnych wiadomości transakcyjnych: ani potwierdzeń zamówień, ani powiadomień o realizacji. Zamówienia wpadały do sklepu normalnie, ale nie wychodziły ani maile do klientów, ani powiadomienia dla obsługi, więc awarię zauważył dopiero klient.

Skala: dwanaście zamówień w dwóch sklepach bez żadnego maila do kupującego. Przez kilka dni strona działała bez żadnego komunikatu o błędzie.

## Jak sprawdzić, dlaczego SMTP odrzuca logowanie?

Zamiast ufać wynikowi `wp_mail()`, odpalamy własny dialog SMTP z kontenera i patrzymy na odpowiedzi serwera. U nas serwer odpowiadał tak:

```
SERVER -> CLIENT: 535 Incorrect authentication data
```

Hasła zapisane w `wp-config.php` (20 i 16 znaków) nie były akceptowane. Zanim uznaliśmy to za przyczynę, odrzuciliśmy sześć innych hipotez:

| Hipoteza | Jak sprawdzono | Wynik |
| --- | --- | --- |
| Blokada adresu IP serwera | `nc` na port 587, banner serwera | port otwarty, serwer odpowiada |
| Tymczasowy blok po nieudanych próbach | powtórny test po 4 minutach | ten sam błąd |
| Hasło uszkodzone przez znaki specjalne | oględziny surowej linii w pliku | cudzysłowy pojedyncze, długość zgodna |
| Wtyczka przechwytuje maile | `SHOW TABLES LIKE '%wpmc%'` | brak tabel |
| Zły format loginu | próby z pełnym adresem i samą nazwą | oba odrzucone |
| Brak STARTTLS | dialog SMTP | STARTTLS działa, `AUTH PLAIN LOGIN` ogłaszane |

Certyfikat serwera był wystawiony na nazwę hosta poczty, nie na domeny sklepów. Taka niezgodność nie powoduje błędu 535, który dotyczy logowania, więc nie była przyczyną. Weryfikacji certyfikatu nie warto wyłączać: wygodniej wpisać w konfiguracji nazwę hosta zgodną z certyfikatem. Zostawało jedno: serwer poczty przestał akceptować hasła do skrzynek.

## Kiedy dokładnie przestała działać wysyłka?

Z logów da się odtworzyć zarys osi czasu. Pierwszy błąd uwierzytelnienia pojawił się 25.08, ostatnie udane maile wyszły 26.08 z jednego sklepu i 30.08 z drugiego, a ostatni zarejestrowany błąd to 31.08. Między tymi datami trafiały się też błędy połączenia (28.08), więc wysyłka nie urwała się jednego dnia, tylko wygasała przy kolejnych nieudanych logowaniach.

Pełną oś czasu złożyliśmy dzięki jednemu ze sklepów: jego wtyczka SMTP miała podpięty hak `wp_mail_failed`, który zapisuje każdą nieudaną wysyłkę do logu. Drugi sklep nie miał go wcale, więc awaria przeszła tam bez śladu w logach WooCommerce przez kilka dni.

**Masz ten sam problem?** Nie masz pewności, czy sklep wysyła maile? Sprawdzimy dialog SMTP, dopniemy hak wp\_mail\_failed i ustawimy alert. [Opisz sytuację →](https://asapdevs.it/offers/opieka-wordpress)

## Jak dodać log nieudanych maili w WordPressie?

Hak `wp_mail_failed` przekazuje obiekt błędu z komunikatem serwera. Wystarczy zapisać go tam, gdzie ktoś zajrzy:

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

To jedna z pierwszych rzeczy, które dodajemy do sklepu przy przejęciu opieki. Sam log bez alertu to jednak za mało: warto powiązać go z powiadomieniem, które trafia do kogoś, kto je przeczyta w ciągu godziny.

## Dlaczego po zmianie hasła strona dalej nie wysyła?

Hasła skrzynek ustawiliśmy na nowo w panelu pocztowym (DirectAdmin) i wpisaliśmy do `wp-config.php` obu sklepów, zostawiając kopie starych plików. Dialog SMTP z kontenera zwrócił `235 Authentication succeeded` dla obu kont, a `wp_mail()` z wiersza poleceń zwrócił `true` bez `wp_mail_failed`.

Pułapka: strona dalej mogła używać starego hasła. Php-fpm miał `opcache.validate_timestamps=0`, więc zmiana `wp-config.php` nie była dla niego widoczna bez przeładowania. Test z CLI przechodzi, bo uruchamia świeży proces, a sklep w przeglądarce trzyma wartość z pamięci. Rozwiązaniem bez ponownego tworzenia kontenera, które kosztowałoby około 60 sekund błędu 502, jest łagodne przeładowanie. Zakłada ono, że php-fpm jest procesem głównym o PID 1, więc najpierw sprawdź to poleceniem `docker compose exec wordpress ps`:

```
docker compose exec wordpress kill -USR2 1
```

Sprawdziliśmy to tymczasowym plikiem PHP wywołanym przez nginx: php-fpm czytał już nowe wartości.

## Co ustawić, żeby wysyłka maili nie padła po cichu?

-   hak `wp_mail_failed` na każdym sklepie, w tym tym drugim, który go jeszcze nie miał,
-   alert po pierwszym błędzie uwierzytelnienia, a nie po tygodniu,
-   test dialogiem SMTP z `SMTPDebug = 2` po każdej zmianie haseł, zamiast wiary w wynik `wp_mail()`,
-   przeładowanie php-fpm po zmianie `wp-config.php`, gdy opcache nie sprawdza znaczników czasu,
-   osobny test pełnej ścieżki: złożenie zamówienia i sprawdzenie, czy mail doszedł.

Szerzej o kontrolach, które wykrywają takie awarie, piszemy w artykule o [monitoringu sklepu poza uptime](https://asapdevs.it/blog/monitoring-sklepu-woocommerce-prestashop).

## Kiedy zlecić to specjalistom?

Gdy sklep przyjmuje zamówienia, ale klienci twierdzą, że nic nie dostali, a w panelu nie ma żadnych błędów. W ASAPDevs ustalamy przyczynę po stronie SMTP, naprawiamy konfigurację i dodajemy monitoring w ramach [opieki nad WordPressem](https://asapdevs.it/offers/opieka-wordpress). Gdy liczy się czas, zobacz [Pogotowie IT](https://asapdevs.it/offers/it-emergency).

Źródła: WordPress Developer Resources, [hook wp\_mail\_failed](https://developer.wordpress.org/reference/hooks/wp_mail_failed/); dokumentacja PHP, [opcache.validate\_timestamps](https://www.php.net/manual/en/opcache.configuration.php).

![Kamil Perzowski](https://asapdevs.it/assets/img/kamil-asapdevs-112.webp)

Kamil Perzowski

CEO i co-founder ASAPDevs. Programuje i utrzymuje sklepy, aplikacje webowe i serwery klientów. [LinkedIn](https://www.linkedin.com/in/kamil-perzowski/) · [Opieka nad WordPressem](https://asapdevs.it/offers/opieka-wordpress)

Masz ten sam problem?

## Klienci nie dostają potwierdzeń zamówień?

![Kamil Perzowski, ASAPDevs](https://asapdevs.it/assets/img/kamil-asapdevs-112.webp)

Kamil Perzowski

CEO & Co-founder, ASAPDevs

Znajdujemy przyczynę po stronie SMTP, naprawiamy wysyłkę i ustawiamy alert, który zgłasza każdy nieudany mail.

![Google](https://asapdevs.it/assets/img/logos/google.svg)Opinie klientów w Google

> Rekomenduję. Jestem zadowolona ze współpracy. Firma jest terminowa, rzetelnie wywiązuje się ze zobowiązań. Pełen profesjonalizm i rzadka cecha u informatyków – empatia, życzliwe i cierpliwe wsparcie.

Beata M. · opinia w Google

> Pan Kamil wspaniale pomógł nam i stworzył nasz sklep internetowy! Lepiej nie mogliśmy trafić! Serdecznie polecamy :)

Kwiaciarnia M. · opinia w Google

FAQ

## Pytania i odpowiedzi

### Co oznacza błąd 535 Incorrect authentication data w WooCommerce?

Serwer pocztowy odrzucił login lub hasło skrzynki, z której sklep wysyła maile. Najczęściej hasło zostało zmienione albo wygasło po stronie hostingu poczty, a w wp-config.php został stary wpis.

### Dlaczego wp\_mail() bywa true, a mail nie dochodzi?

W standardowej konfiguracji błąd SMTP daje false i hak wp\_mail\_failed. U nas część ścieżek, na przykład wysyłka przejęta przez wtyczkę SMTP, zwracała true mimo błędu, a po przyjęciu wiadomości przez serwer mail może jeszcze nie dotrzeć do skrzynki. Dostarczenie sprawdza się dialogiem SMTP z SMTPDebug ustawionym na 2.

### Skąd się dowiedzieć, że sklep przestał wysyłać maile?

Najpewniej z haka wp\_mail\_failed, który zapisuje każdy nieudany mail do logu. Bez niego awaria potrafi trwać kilka dni, bo WooCommerce nie pokazuje żadnego komunikatu, a zamówienia dalej przychodzą.

### Po zmianie hasła w wp-config.php strona dalej wysyła ze starym. Dlaczego?

Jeśli php-fpm ma opcache.validate\_timestamps=0, zmieniony plik nie jest widoczny bez przeładowania. Test z wiersza poleceń przechodzi, bo to nowy proces, a strona dalej używa starej wartości z pamięci.

### Jak przeładować php-fpm w kontenerze bez przerwy w działaniu?

Jeśli php-fpm jest procesem o PID 1, wyślij sygnał USR2: docker compose exec wordpress kill -USR2 1. To łagodne przeładowanie, bez ponownego tworzenia kontenera i bez kilkudziesięciu sekund błędu 502.

## Przeczytaj też

### [Opieka nad WordPressem](https://asapdevs.it/offers/opieka-wordpress)

Monitoring sklepu, aktualizacje i szybka reakcja.

### [Pogotowie IT](https://asapdevs.it/offers/it-emergency)

Pilne naprawy, gdy sklep przestaje działać.

### [Monitoring sklepu poza uptime](https://asapdevs.it/blog/monitoring-sklepu-woocommerce-prestashop)

Czytaj

### [PHP-FPM, 502 i opcache JIT](https://asapdevs.it/blog/php-fpm-502-segfault-opcache-jit-wordpress)

Czytaj