Поддержка сайтов · 04.09.2026 · 13 мин

Не приходят заявки с сайта на почту: как найти и исправить сбой

Если форма показывает «Отправлено», а заявка не приходит на почту или в CRM, сбой может находиться в браузере, коде сайта, SMTP, DNS или внешней интеграции. Разбираем безопасную проверку всей цепочки — от нажатия кнопки до фактического получения обращения.

Неработающую страницу обычно замечают быстро. С формой опаснее: сайт открывается, реклама продолжает приводить посетителей, кнопка нажимается и даже появляется благодарность — но менеджер не получает обращение. Внешне всё выглядит исправным, поэтому проблема может оставаться незаметной несколько дней.

Не стоит сразу переустанавливать плагин или менять адрес получателя. Сначала нужно определить последний этап, на котором видна тестовая заявка. Такой подход отделяет ошибку формы от недоставленного письма, блокировки спам-фильтром и сбоя CRM, а значит сокращает количество случайных изменений на рабочем сайте.

Где может потеряться заявка с сайта

Отправка формы — это цепочка из нескольких систем. Успешная работа одного звена не подтверждает, что обращение дошло до конца. Проверять нужно последовательно:

• поля и кнопка в браузере: валидация, JavaScript, маска телефона и согласие;
• защитные механизмы: CAPTCHA, антиспам, CDN или блокировка повторных запросов;
• серверный обработчик формы: PHP, WordPress, Laravel или другой backend;
• сохранение заявки в базе данных или журнале событий;
• передача письма почтовому механизму и, если используется, постановка задания в очередь;
• SMTP-авторизация и доменные настройки отправителя;
• приём письма сервисом получателя, фильтры, папка «Спам» и правила пересылки;
• передача в CRM, Telegram или другой внешний сервис;
• назначение ответственного и внутренний процесс обработки обращения.

Надпись «Отправлено» иногда означает лишь, что сервер принял запрос без транспортной ошибки. Код HTTP 200 сам по себе не подтверждает отправку письма, создание сделки или назначение менеджера.

Что проверить, если форма отправлена, а письмо не пришло

До обращения к разработчику полезно выполнить несколько безопасных проверок. Они не исправят серверную причину, но помогут точнее описать симптом и не тратить время на догадки.

• отправить заявку с компьютера и телефона, записав точное время и введённые данные;
• проверить «Спам», «Промоакции», карантин корпоративной почты и правила сортировки;
• уточнить, приходят ли системные письма WordPress, уведомления магазина или восстановление пароля;
• проверить, возникает ли проблема во всех формах или только на одной странице;
• спросить коллег, не менялись ли недавно получатель, почтовый пароль, домен, хостинг, CAPTCHA или CRM;
• сохранить текст ошибки или снимок экрана, не публикуя пароли и секретные ключи.

Отправьте одну заявку с уникальным маркером и запишите время. Затем проверьте четыре точки: сохранилась ли заявка на сайте, появилась ли попытка отправки в журнале, принял ли сообщение почтовый сервер и не отклонил ли его сервис получателя. Первая точка, где заявка исчезает, указывает на место сбоя.

• Запрос не дошёл до сервера — проверяются JavaScript, валидация, CAPTCHA и адрес обработчика.
• Заявка сохранилась, но попытки отправки нет — настройки формы, шаблон письма и очередь, если она используется.
• SMTP вернул ошибку — авторизация, порт, шифрование, ограничения хостинга или почтового провайдера.
• Сервер принял письмо, но ящик пуст — журнал доставки, ответ об отказе, SPF, DKIM, DMARC, карантин и правила почты.
• Письмо пришло, но сделки нет — ответ API, срок действия токена, соответствие полей и правила CRM.

Не отправляйте десятки одинаковых тестов подряд: антиспам может принять их за атаку, а в CRM появятся дубли. Для проверки достаточно уникального имени или комментария и точного времени отправки.

Что должно происходить после отправки формы

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

• браузер проверяет поля и отправляет запрос правильному обработчику;
• сервер принимает данные, применяет антиспам и фиксирует событие;
• письмо передаётся SMTP-серверу либо заявка отправляется во внешнюю систему;
• принимающая сторона возвращает результат, который можно найти в журнале;
• посетитель видит честный статус, а сотрудник получает само обращение;
• при временной ошибке срабатывает повторная отправка или резервный канал.

Сообщение об успешной отправке на экране ещё не доказывает, что письмо доставлено или сделка появилась в CRM. Показывать успех корректно только после сохранения заявки на стороне сайта или подтверждённого ответа принимающей системы. Если почта или CRM временно недоступна, данные должны дождаться повторной отправки либо попасть в заранее согласованный резервный канал.

Почему WordPress или Contact Form 7 не отправляет письма

Если WordPress не отправляет письма, причина не обязательно находится в самой форме. Contact Form 7, WPForms и другие плагины передают данные стандартному почтовому механизму WordPress, а дальше результат зависит от настроек сайта, хостинга и принимающего почтового сервиса.

• в настройках формы указан старый или ошибочный адрес получателя;
• поле отправителя подставляет адрес посетителя с чужим доменом;
• после обновления возник конфликт темы, плагина формы, кэша или антиспама;
• хостинг ограничивает стандартную отправку почты или блокирует соединение;
• SMTP-плагин отключён, потерял авторизацию или использует изменённый пароль;
• письмо отправлено, но отклонено или отфильтровано почтовым сервисом;
• форма работает только на части страниц из-за ошибки JavaScript или устаревшего кэша.

В Contact Form 7 проверьте вкладку «Почта»: адрес в поле «Кому», адрес своего домена в поле «От» и адрес посетителя в Reply-To. Подстановка email посетителя в «От» часто выглядит для почтового сервиса как подмена отправителя и ухудшает доставку. Успешный результат wp_mail() подтверждает отсутствие ошибки при передаче сообщения почтовому механизму WordPress, но не получение письма адресатом.

Полезно разделить два вопроса: принял ли WordPress форму и удалось ли почтовому серверу доставить сообщение. Журнал отправки может подтвердить попытку, но окончательный тест — появление конкретного письма у получателя. Настройка «на глаз» без такого теста оставляет проблему незакрытой.

Когда проблема в SMTP, SPF, DKIM или DMARC

SMTP — это способ передавать почту через авторизованный сервер, а не полагаться на неподтверждённую отправку с хостинга. Он часто делает доставку предсказуемее, но одна установка SMTP-плагина не гарантирует результат: нужно проверить адрес отправителя, порт, шифрование, авторизацию и фактическую доставку.

SPF проверяет, разрешено ли серверу отправлять почту для домена технического отправителя. DKIM подтверждает доменную подпись сообщения. DMARC проверяет согласованность домена в поле «От» с SPF или DKIM и задаёт политику обработки писем, которые не прошли проверку. Ошибка в этих записях может привести к отклонению или попаданию письма в спам. Менять DNS без понимания текущей почтовой схемы рискованно: неверная запись способна затронуть не только сайт, но и рабочую почту компании.

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

Что сохранить, чтобы обращение можно было восстановить

Если заявка существует только в одном письме, после сбоя её трудно восстановить. В зависимости от процесса сайт может сохранять контакт и комментарий, выбранную услугу, адрес страницы, название формы, время и рекламные метки до внешней отправки. Уникальный идентификатор помогает найти событие в журнале и не создать дубль при повторной попытке.

Не стоит собирать данные «на всякий случай». Для каждого поля должна быть понятна цель, срок хранения и круг сотрудников, которым оно доступно. Текст формы, политика обработки данных и фактическая передача во внешнюю систему должны соответствовать друг другу.

Почта, готовый модуль, webhook или API: что выбрать

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

• Письмо через настроенный SMTP подходит для простого процесса, когда обращения обрабатывает один ответственный. Желательно дополнительно сохранять заявку на сайте или в другом контролируемом месте.
• Готовый плагин или модуль удобен для WordPress, WooCommerce и простой передачи в CRM или Telegram. Перед установкой важно проверить обновления, безопасность и обработку ошибок.
• Webhook или API нужны для собственных полей, распределения заявок, проверки дублей и контролируемых повторных попыток.
• Сервис-коннектор помогает собрать простую связку без отдельного кода, но добавляет ещё одну систему, тариф и точку возможного сбоя.

Для базовой передачи одной формы готовое решение часто разумнее собственной разработки. Интеграция сайта с CRM через API оправдана, когда появляются собственные правила и несколько систем. Название CRM само по себе не определяет способ: отдельно проверяются её версия, тариф и доступные методы.

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

Как снизить риск потерянных заявок и дублей

Почтовый сервер или другая внешняя система может отвечать медленно, временно не работать или отклонить данные. Надёжность появляется благодаря предусмотренным сценариям сбоя, а не просто после установки нового плагина.

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

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

Можно ли исправить отправку без переделки сайта

В большинстве случаев отправку можно исправить без редизайна и переноса всего проекта. На WordPress или WooCommerce сначала проверяются форма, плагины и текущая почтовая конфигурация. В Laravel-приложении можно исследовать обработчик, очередь и журналирование. Для Next.js, MODX и самописных проектов решение зависит от того, где принимается форма и как сервер передаёт данные дальше.

Перед изменением важно понять, кому принадлежат домен, хостинг, CRM и исходный код, есть ли резервная копия и где можно проверить интеграцию. Если сайт устарел, это не всегда означает полную переделку: иногда достаточно заменить обработчик формы и аккуратно добавить нужный сценарий.

Порядок безопасной работы с уже запущенным проектом подробнее разобран в статье «Доработка существующего сайта: с чего начать и как оценить работу».

От чего зависят сроки и стоимость исправления

Стоимость исправления зависит от того, удалось ли локализовать сбой и сколько систем участвует в доставке. Ошибочный получатель в одной форме, конфликт плагинов и нестабильная двусторонняя интеграция требуют разного объёма проверки.

• Локальная настройка: адрес получателя, поле отправителя, шаблон письма, SMTP или отдельная форма.
• Связанный сбой: конфликт плагина, темы, CAPTCHA, кэша, очереди, DNS или ограничений хостинга.
• Сквозной процесс: несколько форм, CRM, распределение заявок, дубли, уведомления и резервная доставка.

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

Что прислать для диагностики

Готовое техническое задание и пароли для первого разговора не нужны. Чем точнее описан контрольный тест, тем быстрее можно определить необходимые журналы и доступы:

• ссылка на проблемную страницу и, если известно, название CMS или формы;
• куда должно прийти обращение: почта, CRM, Telegram или несколько каналов;
• что видит посетитель после отправки и появляется ли ошибка;
• точное время теста и уникальные данные, по которым его можно найти;
• когда была последняя рабочая заявка и что недавно менялось на сайте.

Часто сбой можно устранить локально — без редизайна и переноса сайта. Доступы передаются только после согласования диагностики, в необходимом объёме и через подходящий защищённый канал. После исправления проверяется не только одна форма, но и другие функции, которые используют ту же почтовую конфигурацию: корзина, регистрация или восстановление пароля.

Вывод

Если заявки с сайта не приходят на почту или в CRM, начинать нужно с одной воспроизводимой отправки и последовательной проверки каждого звена. Исчезнувшая ошибка или сообщение «Отправлено» ещё не означают, что обращение доставлено: результат подтверждает только письмо, сохранённая запись или сделка, которую действительно видит ответственный сотрудник.

После восстановления стоит убрать единственную точку отказа: сохранять заявку до внешней отправки, настроить журнал ошибок или добавить подходящий резервный канал. Масштаб решения должен соответствовать цене сбоя для бизнеса — без лишней автоматизации и без ситуации, когда о проблеме первым сообщает потерянный клиент.