Проверить заявку в системе
Сохранилась ли она в БД/CRM/админке.
Практическая диагностика · формы и почта
Форма на сайте отправляется, но письмо не приходит: что проверить
Сообщение «успешно отправлено» означает только то, что frontend получил ожидаемый ответ. Оно не доказывает, что письмо сформировано, передано SMTP-серверу, принято почтовым провайдером и дошло до Inbox. Проверяем цепочку по этапам.
Быстрый маршрут
Что проверить за первые 5 минут
Сначала определяем, где заканчивается успешная часть цепочки.
Проверить журнал отправки
Был ли вызов mail/SMTP и какой ответ вернулся.
Проверить адрес получателя
Нет ли опечатки, старого ящика или условной маршрутизации.
Проверить спам
Письмо может быть доставлено, но отфильтровано.
Проверить SMTP и DNS
Авторизация, SPF, DKIM и From должны быть согласованы.
Успех формы и доставка email — два разных события.Нужно увидеть, на каком шаге пропадает сообщение: приложение, SMTP, принимающий сервер или фильтрация ящика.
Шаг 1
Проверьте, дошли ли данные формы до backend
Если заявка есть в базе, Telegram, CRM или административном журнале, frontend и обработчик формы уже отработали. Тогда проблема находится после бизнес-логики — в формировании или доставке письма.
Если записи нет нигде, начинаем раньше: Network в браузере, endpoint, CSRF/captcha, JavaScript и серверный ответ.
Шаг 2
Нужен лог фактической попытки отправки
Функция приложения может вернуть success раньше реальной доставки или скрыть ошибку библиотеки. Настройте безопасный журнал: время, получатель, From, Message-ID и ответ SMTP без паролей и содержимого чувствительных полей.
Для WordPress полезно отличать успешный вызов wp_mail от фактической передачи внешнему SMTP.
Шаг 3
Проверьте авторизацию, порт, TLS и ограничения отправителя
Почтовый сервер может отклонять неправильный логин, запрещённый From, превышение лимита или соединение с неподходящим типом TLS. Ошибка должна быть видна в SMTP-ответе.
Не стоит использовать адрес посетителя как From: домен отправителя должен быть вашим, а адрес клиента лучше ставить в Reply-To.
Шаг 4
Если сервер принял письмо, проверьте аутентификацию домена
Без корректных SPF/DKIM письма формы чаще попадают в спам или отклоняются строгими провайдерами. DMARC дополнительно проверяет согласование домена From с SPF/DKIM.
После переноса DNS или почты особенно важно сверить, не потерялись ли TXT/CNAME записи.
Шаг 5
Письмо может быть принято сервером, но не попасть во Входящие
Проверяем Spam/Junk, правила ящика, quarantine корпоративной почты и блокировки по содержимому. Если проблема только с одним доменом-получателем, сравниваем доставку на несколько независимых ящиков.
Код 250 от SMTP означает, что следующий сервер принял сообщение в обработку, но не гарантирует размещение во Inbox.
Практический пример
Форма пишет «отправлено», Telegram получает заявку, email — нет
Пользователь видит успешную отправку, а заявка сохраняется в Telegram. Значит, backend уже получил данные, но почтовое уведомление ломается дальше.
В SMTP log видно отказ: приложение подставляет email посетителя в From, а почтовый сервер запрещает отправку от чужого домена. Меняем From на адрес сайта, email клиента переносим в Reply-To и проверяем SPF/DKIM.
| Этап | Результат |
|---|---|
| Frontend → backend | успешно |
| Сохранение заявки | успешно |
| SMTP | отказ по From |
| После исправления | SMTP принимает, письмо доходит |
Типовые сценарии
Где искать по конкретному симптому
Разделите отправку формы и почтовую доставку — это сразу сокращает количество гипотез.
| Симптом | Вероятная зона | Что проверить |
|---|---|---|
| Заявка не сохранилась | форма/backend | Network, endpoint, server log |
| Заявка есть, попытки mail нет | логика приложения | условия уведомлений и queue |
| SMTP возвращает ошибку | авторизация/TLS/From | ответ сервера |
| SMTP 250, письма нет | фильтрация/репутация | spam, SPF/DKIM/DMARC |
| Не приходит одному получателю | его правила/провайдер | тест на другие ящики |
Чего не делать
Типичные действия, которые мешают диагностике
Считать зелёную галочку доказательством доставки
Frontend не знает, куда почтовый сервер положил письмо.
Ставить email посетителя в From
DMARC и антиспам могут воспринимать это как подмену.
Менять SMTP-порт случайно
Нужно соответствовать настройкам провайдера и типу TLS.
Проверять только один ящик
Проблема может быть на принимающей стороне.
Чек-лист
Проверка формы без письма
- Отправить тест: Зафиксировать время и данные.
- Проверить запись заявки: БД/CRM/Telegram.
- Проверить mail log: Была ли попытка отправки.
- Проверить адреса: To, From и Reply-To.
- Проверить SMTP: Авторизация, порт и TLS.
- Проверить ответ сервера: Код и текст SMTP.
- Проверить SPF/DKIM: Домен подтверждает отправителя.
- Проверить spam/quarantine: Принимающая сторона.
- Тестировать разные домены: Исключить локальную фильтрацию.
- Сохранить резервный канал: Заявка не должна теряться только из-за email.
Когда нужен доступ к проекту
Какие данные ускоряют диагностику
Если заявка важна для бизнеса, лучше иметь доступ к логам формы и SMTP и сохранять данные независимо от email. Тогда диагностика не требует просить клиента повторно отправлять потерянную заявку.
Передавать пароли в текст статьи или публичную переписку не нужно. Для рабочей диагностики доступы выдаются отдельно и только к тем системам, которые действительно нужны для проверки.
Вопросы
Короткие ответы
Почему форма пишет «успешно», если письмо не пришло?
Потому что интерфейс часто подтверждает только обработку запроса, а доставка email происходит дальше.
Можно ли отправлять без SMTP через PHP mail()?
Можно, но управляемый SMTP обычно даёт более прозрачные логи и предсказуемую аутентификацию.
Что ставить в From?
Адрес вашего домена, разрешённый почтовым сервером; email посетителя — в Reply-To.
Нужно ли хранить заявки в базе?
Для важных лидов это полезная страховка: email становится уведомлением, а не единственной копией данных.