Ситуация знакомая: на сайте пользователь заполняет форму, после отправки видит статус «Отправлено», но в почтовом ящике (или CRM) заявка так и не появляется. При этом ошибка может не отображаться на фронтенде — а значит, теряется письмо где-то «по пути» между формой, сервером и почтовыми сервисами.

1) Обработчик формы не отправляет письмо (или отправляет в неправильное место)

Самая частая причина — серверная часть формы настроена так, что пользователь видит успешный ответ от бэкенда, но фактическая отправка письма не происходит. Это бывает, когда обработчик:
— возвращает «успех» до завершения отправки;
— падает по ошибке, но ошибка не логируется и пользователю не показывается;
— отправляет письмо на другой email/адрес или в другую среду (staging вместо production).

Проверка: откройте логи сервера (PHP/Node/Python/NGINX) и посмотрите, вызывает ли запрос ожидаемый endpoint, и что происходит после POST-запроса. Хороший индикатор — есть ли в логах строки об отправке письма или записи об исключениях.

2) Email не доходит до почты: спам-фильтры, SPF/DKIM/DMARC и репутация

Даже если письмо действительно отправилось с сервера, оно может не попасть во входящие. Современные почтовые провайдеры часто пропускают или блокируют сообщения в зависимости от корректности доменной аутентификации.

Проверьте DNS-записи для домена отправителя:

• SPF — кто имеет право отправлять почту от вашего домена;
• DKIM — подпись сообщений;
• DMARC — политика обработки некорректной почты (какой процент помечать/отклонять).

Если эти параметры не настроены или настроены неправильно, письма могут уходить в спам или отбрасываться. Дополнительно проверьте, не блокирует ли письма конкретный отправляющий IP (репутация) или не включены ли ограничения у хостинга/почтового сервиса.

3) Письмо уходит, но пользователю показывается «успешно» без подтверждения доставки

Некоторые формы устроены так: фронтенд показывает «Отправлено», как только получил ответ от обработчика (например, HTTP 200). Но это не означает, что почта успешно принята почтовым сервером получателя. Если код отправки использует асинхронность, таймаут или «тихий» catch-обработчик ошибок, пользователь всё равно увидит успех.

Проверка: включите трассировку/логирование в месте отправки. Ищите различие между событиями «запрос на отправку создан» и «письмо принято/вернуло acceptance». Если используется SMTP/провайдер, полезно логировать ответ сервера (message-id, status).

4) Заявки теряются в CRM/скрипте записи или фильтрах получателя

Если заявка должна попадать не в почту, а в CRM (или в таблицу/склад заявок), причина может быть в интеграции. Часто встречаются проблемы с вебхуками, токенами доступа, правами, лимитами и валидацией полей (например, обязательное поле пустое — и запись не создаётся).

Проверка: попробуйте отправить тест с минимальным набором данных и проверьте, фиксируется ли запись в CRM/логах интеграции. Также проверьте сортировку/правила почты: возможно, письма приходят, но автоматически перемещаются в папки «Промоакции/Спам/Архив».

Что сделать прямо сейчас (быстрый чек-лист)

• Отправьте тестовую заявку и одновременно проверьте: логи бэкенда, логи почтовой подсистемы/SMTP и статус ответа обработчика.
• Убедитесь, что в настройках формы указан правильный получатель (и правильная среда — production, а не staging).
• Проверьте SPF/DKIM/DMARC и по возможности посмотрите, что показывает почтовый провайдер отправителя/получателя для тестового сообщения.
• Если используется CRM/вебхук — проверьте журнал событий интеграции и корректность токенов/эндпоинта.

Если после этих шагов письма по-прежнему не приходят, самое эффективное — собрать доказательства: HTTP-ответ обработчика, логи попытки отправки, message-id (если есть) и пример тестового payload. С ними разработчику или поддержке будет проще локализовать место, где происходит «потеря».