Чому не надходять листи з сайту: як знайти проблему з WordPress, OpenCart і хостингом

Форма на сайті показує повідомлення «Надіслано», але листа немає. Замовлення в інтернет-магазині створилося, а клієнт і адміністратор нічого не отримали. Або частина повідомлень доходить на Gmail, але зникає на корпоративній пошті.

У таких ситуаціях проблема далеко не завжди знаходиться у формі зворотного зв’язку. Лист проходить цілий ланцюжок: сайт → PHP або SMTP → поштовий сервер → перевірка SPF/DKIM/DMARC → антиспам → скринька одержувача.

Збій на будь-якому з цих етапів дає однаковий результат для власника: «листи з сайту не приходять».

Коротка відповідь

Якщо сайт перестав надсилати листи, перевіряйте проблему у такому порядку:

1. чи створюється сама заявка або замовлення;
2. чи виконується функція відправлення;
3. яку адресу From використовує сайт;
4. чи налаштований SMTP;
5. чи проходять SPF, DKIM і DMARC;
6. чи не потрапляє повідомлення у спам;
7. чи немає поштових лімітів на хостингу;
8. що показують mail log та PHP error log.

Найнадійніша модель для бізнес-сайту — надсилати системні повідомлення через авторизований SMTP, а не покладатися лише на стандартну PHP-функцію mail().

Спочатку визначте: сайт не створює повідомлення чи пошта його не доставляє

Це два принципово різні випадки.

Варіант 1. Форма взагалі не спрацьовує

Наприклад, після натискання кнопки виникає помилка або нічого не відбувається.

Тут варто перевіряти:

• JavaScript;
• валідацію форми;
• PHP-помилки;
• плагін форми;
• AJAX-запит;
• reCAPTCHA;
• конфлікти після оновлення.

Варіант 2. Форма повідомляє про успіх, але листа немає

У цьому випадку сайт, ймовірно, сформував повідомлення, а проблема вже знаходиться на етапі відправлення або доставки.

Саме цей сценарій зустрічається найчастіше.

1. Перевірте папку «Спам»

Звучить банально, але це потрібно зробити першим.

Особливо якщо:

• домен новий;
• пошта недавно налаштована;
• відправляється багато схожих листів;
• у повідомленні багато посилань;
• не налаштовані SPF і DKIM.

Перевіряйте не тільки Spam, але й категорії «Промоакції», «Оновлення» та карантин корпоративного поштового сервера.

2. Перевірте адресу From

Одна з найтиповіших помилок у формах — використовувати email відвідувача як адресу відправника.

Наприклад, користувач вводить:

client@gmail.com

і сайт намагається надіслати лист від імені:

From: client@gmail.com

Але повідомлення фізично відправляється із сервера вашого домену. Для Gmail та інших поштових систем це виглядає підозріло.

Правильніша схема:

From: website@example.com
Reply-To: client@gmail.com

Тоді повідомлення надсилається від вашого домену, а кнопка «Відповісти» все одно веде на адресу клієнта.

3. PHP mail() може працювати нестабільно

Багато CMS за замовчуванням використовують PHP-функцію mail().

Вона може передати повідомлення локальному поштовому серверу, але не гарантує його успішну доставку одержувачу.

Проблеми виникають через:

• погану репутацію IP;
• відсутність правильної авторизації;
• поштові обмеження хостингу;
• некоректний envelope sender;
• відсутність SPF/DKIM;
• блокування вихідної пошти.

Тому фраза «PHP mail повернув success» ще не означає, що лист реально доставлено.

4. Для бізнес-сайту краще використовувати SMTP

SMTP дозволяє сайту авторизуватися у поштовому сервісі так само, як це робить звичайна поштова програма.

Зазвичай потрібно вказати:

• SMTP hostname;
• порт;
• тип шифрування;
• логін;
• пароль або спеціальний app password;
• адресу відправника.

Після цього повідомлення від сайту проходять через контрольований поштовий сервер із правильною репутацією та автентифікацією.

Типова конфігурація

Параметр	Приклад
Сервер	mail.example.com
Порт	587
Шифрування	TLS
Авторизація	Так
From	website@example.com

Конкретні параметри потрібно брати у вашого поштового провайдера, а не копіювати універсальний приклад.

5. Перевірте SPF

SPF повідомляє поштовим системам, які сервери мають право відправляти листи від імені домену.

Проблема часто з’являється після підключення нового SMTP, CRM або сервісу розсилок.

Наприклад, у SPF дозволений тільки корпоративний поштовий сервіс, а сайт надсилає повідомлення через інший сервер.

Результат:

• SPF fail;
• лист потрапляє у спам;
• або одержувач повністю його відхиляє.

6. Перевірте DKIM

DKIM додає цифровий підпис до повідомлення.

Якщо він налаштований неправильно, можливі ситуації, коли:

• ключ видалили з DNS;
• змінився поштовий сервіс;
• використовується старий selector;
• підпис не відповідає домену From.

У технічних заголовках тестового листа бажано бачити:

DKIM: PASS

7. DMARC може почати блокувати ваші ж листи

Особливо це трапляється після переходу на політику:

p=quarantine

або:

p=reject

Якщо сайт надсилає пошту через неврахований сервер, DMARC може справедливо визнати її підозрілою.

Тому перед посиленням політики потрібно переконатися, що всі легальні джерела правильно проходять SPF або DKIM.

Детальну схему ми розбирали в інструкції як налаштувати SPF, DKIM і DMARC.

8. Лист приходить на одну пошту, але не приходить на іншу

Це важлива діагностична ознака.

Наприклад:

• Gmail отримує повідомлення;
• Outlook — ні;
• корпоративна пошта — ні.

У такому випадку форма та SMTP, швидше за все, працюють. Проблему потрібно шукати вже у політиці конкретного одержувача.

Перевіряйте:

• SPF;
• DKIM;
• DMARC;
• репутацію IP;
• blacklists;
• вміст листа;
• налаштування антиспаму одержувача.

9. Перевірте поштові ліміти хостингу

Shared-хостинг часто обмежує кількість листів.

Наприклад, можуть існувати ліміти:

• на годину;
• на добу;
• на одну скриньку;
• на один PHP-процес;
• на кількість одержувачів.

Це захищає сервер від спаму.

Проблема може з’явитися раптово після:

• масової розсилки;
• великої кількості замовлень;
• атаки на форму;
• зараження сайту;
• помилки cron.

10. Перевірте, чи сайт не розсилає спам

Якщо пошта раніше працювала нормально, а потім провайдер її заблокував, потрібно виключити зараження.

Шкідливий PHP-файл може надсилати тисячі повідомлень у фоновому режимі.

Ознаки:

• різко зросла вихідна пошта;
• перевищено денний ліміт;
• IP потрапив у blacklist;
• хостинг заблокував mail();
• CPU почав працювати під високим навантаженням.

У такому випадку варто провести перевірку сайту на шкідливий код.

11. Перевірте mail log

Лог поштового сервера часто дає найточнішу відповідь.

У ньому можна побачити:

• чи був лист прийнятий сервером;
• кому він відправлявся;
• код відповіді сервера одержувача;
• причину відмови;
• тимчасову чи постійну помилку.

Типові результати

Результат	Що означає
Accepted	Сервер одержувача прийняв лист
Deferred	Доставка відкладена
Rejected	Лист відхилено
Authentication failed	Помилка SMTP-авторизації
Relay denied	Сервер не дозволяє пересилання
Mailbox unavailable	Проблема з адресою одержувача

Якщо mail log показує Accepted, але користувач не бачить листа, потрібно вже досліджувати сторону одержувача.

12. Перевірте PHP error log

Іноді форма показує успішне повідомлення, хоча сам поштовий код завершився помилкою.

У PHP log можуть бути:

• SMTP connection timeout;
• помилка TLS;
• невірний пароль;
• відсутня PHP-бібліотека;
• фатальна помилка плагіна;
• помилка DNS.

Окрема діагностика для WordPress

У WordPress листи часто надсилають:

• форми зворотного зв’язку;
• WooCommerce;
• система відновлення пароля;
• плагіни безпеки;
• CRM-інтеграції.

Перше, що потрібно зробити — перевірити, чи не працюють одночасно декілька SMTP-плагінів.

Після цього:

1. надішліть тестовий SMTP-лист;
2. перевірте From;
3. перевірте Reply-To;
4. подивіться лог відправлення;
5. перевірте WooCommerce окремо;
6. перевірте форму окремо.

Якщо тестовий SMTP-лист доходить, але форма — ні, проблема знаходиться вже у конфігурації форми.

Окрема діагностика для WooCommerce

WooCommerce може створити замовлення нормально, але не відправити повідомлення.

Перевірте:

• чи активоване конкретне email-повідомлення;
• правильну адресу одержувача;
• статус замовлення;
• SMTP log;
• чергу фонових завдань;
• cron;
• шаблони листів.

Особливо важливо протестувати різні сценарії:

• нове замовлення;
• оплачене замовлення;
• скасування;
• відновлення пароля.

Окрема діагностика для OpenCart

В OpenCart перевіряються:

• налаштування Mail;
• Mail Engine;
• SMTP hostname;
• SMTP username;
• SMTP password;
• порт;
• timeout.

Після зміни конфігурації протестуйте не лише форму контактів, а й реальне тестове замовлення.

У магазині різні повідомлення можуть формуватися різними частинами системи.

13. Після зміни пароля SMTP сайт може «мовчки» перестати надсилати пошту

Це дуже поширений сценарій.

Адміністратор змінює пароль корпоративної пошти, але забуває, що той самий пароль збережений:

• у WordPress;
• OpenCart;
• CRM;
• іншому сервісі.

З цього моменту SMTP-авторизація більше не проходить.

14. Перевірте порт і шифрування

SMTP-сервер може використовувати різні варіанти з’єднання.

Типово зустрічаються порти:

• 465;
• 587;
• іноді 25.

Але конкретна конфігурація залежить від провайдера.

Не підбирайте комбінацію порту та SSL/TLS навмання — використовуйте параметри поштового сервісу.

15. Хостинг може блокувати зовнішній SMTP

Деякі серверні конфігурації обмежують вихідні з’єднання для боротьби зі спамом.

Якщо сайт не може підключитися до зовнішнього SMTP:

• перевірте firewall;
• запитайте хостинг про обмеження;
• перевірте доступність потрібного порту;
• перевірте DNS hostname.

16. DNS після міграції сайту

Після перенесення на інший хостинг власники іноді змінюють DNS і випадково видаляють поштові записи.

Особливо важливо зберегти:

• MX;
• SPF;
• DKIM;
• DMARC;
• службові записи поштового провайдера.

Сам сайт після міграції може працювати чудово, але корпоративна пошта перестане нормально доставляти повідомлення.

Швидка схема діагностики

Симптом	Що перевіряти першим
Не працює жоден лист	SMTP / PHP mail / hosting limits
Тест SMTP працює, форма ні	Налаштування форми
Gmail отримує, інша пошта ні	SPF/DKIM/DMARC та репутація
Все зламалося після зміни пароля	SMTP credentials
Все зламалося після міграції	DNS та SMTP-конфігурація
Пошта перестала працювати після масової активності	Ліміти та можливе зараження

Коли проблема не в хостингу

Не варто одразу змінювати провайдера, якщо:

• неправильно вказана адреса From;
• зламаний SMTP-пароль;
• помилка у формі;
• не налаштований DKIM;
• лист просто потрапляє у спам.

У такій ситуації переїзд на інший сервер може взагалі нічого не змінити.

Коли варто звернутися до хостингу

Підтримка провайдера потрібна, якщо:

• mail() заблокований;
• не працює локальний поштовий сервер;
• перевищено server-side limits;
• недоступний SMTP-порт;
• потрібен mail log;
• є проблеми із DNS-серверами.

Де проходить межа між хостингом і розробником, ми окремо розібрали у статті що входить у технічну підтримку сайту.

Практичний чек-лист

• Перевірено Spam.
• Перевірено адресу From.
• Reply-To налаштований окремо.
• Надіслано тестовий SMTP-лист.
• SPF проходить перевірку.
• DKIM проходить перевірку.
• DMARC не блокує легальне джерело.
• Перевірено поштові ліміти.
• Переглянуто mail log.
• Переглянуто PHP error log.
• Перевірено DNS після міграцій.
• Для магазину виконано тестове замовлення.

FAQ

Чому форма пише «успішно», але лист не приходить?

Форма могла успішно передати повідомлення поштовому механізму, але це не гарантує його подальшу доставку. Потрібно перевірити SMTP або mail log.

Що краще: PHP mail чи SMTP?

Для бізнес-сайту зазвичай краще SMTP із нормальною авторизацією та налаштованим доменом.

Чи може Cloudflare блокувати пошту?

Cloudflare не є поштовим сервісом для звичайних MX-з’єднань. Проблеми частіше виникають через неправильні DNS-записи після зміни конфігурації.

Чому листи потрапляють у спам?

Причиною можуть бути SPF/DKIM/DMARC, репутація IP або домену, вміст повідомлення, великий обсяг розсилок та поведінка одержувачів.

Чи потрібно налаштовувати SMTP для WooCommerce?

Для магазину це доцільно, оскільки листи про замовлення є бізнес-критичною функцією і їхню відправку потрібно контролювати.

Висновок

Проблема «не надходять листи з сайту» майже ніколи не вирішується одним універсальним налаштуванням.

Потрібно визначити, на якому етапі зникає повідомлення: у самій CMS, під час SMTP-авторизації, на поштовому сервері або вже на стороні одержувача.

Для комерційного сайту найстабільніша модель — авторизований SMTP, правильні SPF/DKIM/DMARC, контроль mail log і окреме тестування критичних повідомлень після кожної міграції або зміни поштової конфігурації.