Форма на сайте может выглядеть полностью рабочей: поля заполняются, кнопка нажимается, появляется сообщение «отправлено». Но письмо владельцу не приходит. Для бизнеса это опаснее, чем видимая ошибка. Когда форма показывает красное предупреждение, проблему хотя бы замечают. Когда всё выглядит успешно, заявки могут теряться неделями.
Проблема не всегда в самой форме. Чаще ломается цепочка доставки: сайт принял данные, но письмо не прошло через сервер, SMTP, DNS, спам-фильтр или почтовый ящик получателя. Поэтому правильный вопрос не «почему форма не работает», а «на каком этапе пропадает заявка».
Почему это касается любого сайта
Это не только проблема конкретной CMS, одного плагина или одной платформы. Такая ситуация может быть на сайте с самописной формой, на старой CMS, на конструкторе, в интернет-магазине, на лендинге или в форме бронирования.
Разница только в том, где именно находится контроль. На одном сайте можно посмотреть лог отправки, сохранённые заявки и настройки SMTP. На другом владелец видит только визуальный редактор и письмо в почте. Поэтому диагностика всегда начинается с понимания платформы: что сайт реально сохраняет, как он отправляет письма и можно ли посмотреть технический след заявки.
Google в своих материалах по Workspace отдельно пишет, что сама форма обычно не главная причина. Чаще проблема в том, как сообщение отправляется и подтверждается почтовой системой: SPF, SMTP relay, DKIM и настройки отправителя. Это важный момент. Кнопка «Отправить» может быть исправной, но почта всё равно отвергнет письмо как подозрительное.
Где чаще всего ломается цепочка
У заявки есть несколько этапов.
- Клиент заполняет форму.
- Сайт проверяет поля и защиту от спама.
- Сайт формирует письмо.
- Сервер или SMTP-сервис пытается его отправить.
- DNS-записи домена подтверждают, что отправитель имеет право отправлять письмо.
- Gmail, Outlook или другой почтовый сервис проверяет сообщение.
- Письмо попадает во входящие, в spam или отклоняется.
- Если на сайте включено хранение заявок, запись остаётся в админке, базе или CRM.
На каждом этапе может быть своя ошибка.
Самые частые причины:
- форма отправляет письмо через обычный PHP mail без нормальной авторизации
- SMTP не настроен или пароль SMTP изменился
- From указан как e-mail клиента, а не адрес домена сайта
- Reply-To не настроен, поэтому ответ уходит не клиенту
- SPF не включает сервер или сервис, который реально отправляет письмо
- DKIM не включен или сломан после переноса почты
- DMARC слишком строгий для текущей схемы отправки
- письмо похоже на spoofing, то есть подмену отправителя
- почтовый ящик переполнен или фильтр складывает письма в spam
- captcha или антиспам блокирует нормальных клиентов
- кеш или оптимизация мешают отправке формы
- после обновления изменились поля, шаблон письма или endpoint формы
- на сайте нет сохранения заявок, поэтому потерянное письмо нельзя восстановить
Почему From и Reply-To так важны
Одна из самых частых ошибок - отправлять письмо так, будто оно пришло напрямую от клиента.
Например, клиент указал client@gmail.com, а сайт пытается отправить письмо с сервера сайта с заголовком From: client@gmail.com. Для почтового сервиса это выглядит подозрительно: письмо идёт не с серверов Gmail, но заявляет, что оно от Gmail. Так появляется риск spoofing, попадания в spam или отклонения.
Правильнее делать иначе:
- From: технический адрес домена сайта, например
no-reply@domain.frилиcontact@domain.fr - Reply-To: e-mail клиента из формы
- To: рабочий адрес владельца или отдела продаж
Тогда почтовая система видит понятную картину: сайт отправляет служебное письмо от своего домена, а владелец может нажать Reply и ответить клиенту. Это не решает все проблемы автоматически, но убирает одну из самых частых причин блокировок.
Почему SMTP обычно лучше, чем отправка с хостинга
Обычный сайт не должен быть полноценной почтовой системой. Хостинг хорошо отдаёт страницы, но не всегда хорошо отправляет письма. На общем сервере могут быть ограничения, плохая репутация IP, блокировка портов или лимиты отправки.
SMTP решает часть этой проблемы. Сайт подключается к почтовому сервису с логином и паролем или через API, а письмо уходит через систему, которая предназначена для доставки e-mail. Это может быть почта домена, Google Workspace, Microsoft 365, SendGrid, Mailgun, Brevo, Postmark или другой сервис.
Но SMTP тоже нужно настроить правильно:
- выбрать правильный порт и тип шифрования
- проверить логин и пароль
- настроить адрес отправителя
- добавить SPF, DKIM и при необходимости DMARC
- отправить тестовое письмо
- проверить доставку на Gmail, Outlook и доменную почту
- посмотреть, не попадает ли письмо в spam
Если просто поставить SMTP-плагин или модуль и не проверить результат, проблема может остаться. Владелец увидит «успешно отправлено», а почта продолжит фильтровать сообщения.
Хорошо, когда заявки фиксируются на сайте
Идеальная ситуация: заявка не только отправляется письмом, но и сохраняется на сайте, в базе, CRM или отдельном журнале. Тогда, если письмо попало в spam или было отклонено, можно открыть админку и увидеть, что клиент всё-таки писал.
Это особенно важно для бизнеса, который запускает рекламу, принимает бронирования или получает дорогие заявки. Если за клик уже заплачено, потерянная форма - это не техническая мелочь, а прямые деньги.
Но важно сказать честно: далеко не на всех сайтах это реализовано и не везде это легко включить.
Ограничения бывают разные:
- закрытый конструктор не даёт нормального доступа к базе
- форма встроена внешним сервисом и хранит данные только у себя
- старый сайт отправляет письма напрямую и ничего не сохраняет
- тариф платформы не включает историю заявок
- на сайте нет CRM, webhook или модуля логирования
- есть юридические требования по персональным данным и срокам хранения
- после взлома или сбоя база могла быть очищена
Поэтому при аудите формы нужно проверить не только доставку письма, но и вопрос: где остаётся запись о заявке. Если ответа нет, бизнес зависит только от почтового ящика.
Пример из практики: заявки были, но владелец их не видел
Сценарий типичный для сайта локальной услуги. Владелец запустил рекламу, люди переходили на страницу, форма показывала сообщение об успешной отправке. В почте было тихо. Первый вывод был простой: реклама не работает, спроса нет.
При проверке выяснилось другое. После смены почты домена старая схема отправки осталась прежней. Сайт пытался отправлять уведомления с адреса клиента из формы, а не с адреса домена сайта. Для Gmail и Outlook это выглядело как подозрительная подмена отправителя: письмо технически пришло с сервера сайта, но заголовок утверждал, что оно от внешнего адреса клиента.
Часть писем уходила в spam, часть отклонялась без заметного уведомления для владельца. На компьютере форма выглядела рабочей, потому что пользователь видел «отправлено». Проблема была не в дизайне формы, а в доставке.
В этом случае повезло: заявки сохранялись в админке сайта. По журналу удалось увидеть несколько обращений за последние дни, проверить время отправки, страницу, телефон и e-mail клиента. Часть клиентов ещё можно было догнать звонком или письмом. Если бы хранения заявок не было, восстановить их было бы почти невозможно. Остались бы только косвенные следы: клики в рекламе, посещения страниц, события аналитики, но не сами контакты клиентов.
Решение было не в том, чтобы «поставить другую форму». Сначала исправили схему:
- From заменили на адрес домена сайта
- Reply-To привязали к e-mail клиента
- отправку перевели через SMTP
- проверили SPF и DKIM
- добавили базовый DMARC в мягком режиме
- включили лог отправки
- отправили тесты на несколько почтовых ящиков
- проверили mobile-сценарий
После этого стало понятно, что сайт принимает заявки, письма доходят, а владелец может проверить историю, если снова возникнут сомнения.
Что можно проверить самому
Базовую проверку можно сделать без доступа к коду.
- Откройте форму как клиент, не из админки.
- Отправьте тест с компьютера.
- Отправьте тест с телефона.
- Используйте другой e-mail, не тот, на который приходит заявка.
- Проверьте inbox, spam, promotions, updates и «All mail».
- Нажмите Reply в полученном письме и посмотрите, кому уйдёт ответ.
- Проверьте, приходит ли автоответ клиенту, если он должен приходить.
- Посмотрите, сохраняется ли заявка в админке, CRM или таблице.
- Запишите точное время теста, страницу и e-mail отправителя.
- Не меняйте сразу пять настроек, иначе потом будет непонятно, что помогло или сломало.
Особенно важно тестировать форму перед рекламной кампанией. Если реклама уже ведёт людей на страницу, а форма молча теряет письма, бюджет уходит в пустоту. Владелец может ошибочно решить, что предложение плохое, хотя проблема находится в доставке заявок.
Когда проблема не в письмах
Иногда письмо вообще не создаётся. Тогда SMTP и DNS не помогут.
Так бывает, если:
- кнопка не нажимается на телефоне
- обязательное поле сломано
- captcha блокирует всех подряд
- после отправки происходит ошибка JavaScript
- форма находится в popup, а скрипт popup конфликтует с кешем
- файл темы или шаблона не передаёт данные формы
- endpoint формы заблокирован защитой или firewall
- многоязычная версия отправляет заявку в несуществующую форму
Поэтому диагностику нельзя начинать только с почты. Нужно пройти весь путь клиента: открыть страницу, заполнить форму, отправить, увидеть результат, проверить письмо, проверить лог и проверить сохранение заявки.
Когда лучше обратиться к Zen Webmaster
Если форма важна для заявок, бронирований, расчётов или продаж, её нельзя вести по принципу «поставили и забыли». Нужен контроль.
Zen Webmaster может проверить:
- работает ли форма на desktop и mobile
- не мешают ли popup, кеш, captcha или скрипты
- правильно ли настроены From и Reply-To
- есть ли SMTP и корректные доступы
- проходят ли SPF, DKIM и DMARC
- попадают ли письма в spam
- сохраняются ли заявки в админке, CRM или логах
- можно ли увидеть пропущенные обращения
- какие формы есть на сайте и все ли они работают
- что стоит тестировать регулярно после обновлений
После проверки можно оставить простую схему контроля: тестовая заявка раз в месяц, проверка после обновлений, контроль перед рекламой, лог отправки и хранение заявок там, где это возможно. Это скучная техническая рутина, но именно она защищает бизнес от ситуации «клиенты писали, а мы ничего не получили».
Главная мысль
Форма сайта - это не просто набор полей. Это вход в бизнес. Если она ломается, владелец может потерять не только письмо, но и клиента, рекламный бюджет и доверие к сайту.
Хорошая настройка не обещает магии. Она делает систему проверяемой: видно, что клиент отправил заявку, видно, ушло ли письмо, понятно, куда отвечать, и есть шанс найти пропущенные обращения. Если этого нет, сайт может казаться рабочим, но молча терять деньги.
Последние статьи
