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

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

Отсюда главный вывод: фраза «я сам заполнил форму, письмо пришло» ничего не доказывает. Вы проверили ровно один маршрут - со своего компьютера, в свой ящик, чаще всего в том же домене, где стоит сайт. У посетителя другое устройство, другой провайдер и другой почтовый сервис, а значит, и маршрут другой.

Короткий ответ: почтовый сервис не верит, что письмо действительно отправлено от имени вашего домена, потому что домен не подписан. За это отвечают три записи в настройках домена.

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

Это давно не рекомендация. Google требует с 1 февраля 2024 года, чтобы каждый отправитель настроил SPF или DKIM, а тот, кто шлёт больше 5000 писем в день на адреса Gmail, - ещё и DMARC, отписку в один клик и удержание доли жалоб на спам ниже 0,3%. Mail.ru проверяет подлинность отправителя так же и показывает результат в служебном заголовке Authentication-Results.

Самое неприятное здесь - тихое удаление: письмо не приходит даже в папку «Спам», а отправляющая сторона считает его доставленным. Именно так теряются заявки, о существовании которых вы никогда не узнаете. Типовые причины провала: отправка с общего адреса хостинга, отправитель в чужом домене (форма подставляет почту самого посетителя), отсутствующая подпись DKIM, слишком длинная цепочка вложенных записей в SPF.

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

Когда это случается чаще всего:

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

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

Так бывает чаще, чем кажется: письмо доставлено, но в ящик, который никто не открывает.

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

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

Даже дошедшая заявка теряется, если её увидели поздно. Исследование Lead Response Management (профессор Олдройд, данные шести компаний за три года, больше 15 000 обращений) показало: при росте времени ответа с 5 до 30 минут шансы квалифицировать лид падают в 21 раз, а в течение первого часа вероятность вообще дозвониться снижается более чем в десять раз. Если разбирать почту раз в день, часть заявок к этому моменту уже ничья. Здесь помогают ИИ-агенты для обработки заявок, которые принимают и квалифицируют обращения круглосуточно.

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

Зарубежная капча грузится с иностранных серверов: она периодически недоступна из России, а передача данных посетителя за рубеж - отдельный юридический риск по закону о персональных данных. Российский аналог, Яндекс SmartCaptcha, снимает обе проблемы и умеет работать в невидимом режиме: проверку видят только подозрительные запросы.

Блокировщики рекламы режут скрипты по именам файлов и доменам. Если форма подгружается сторонним скриптом с «рекламным» адресом, у части посетителей формы на странице просто не окажется. Оценки доли людей с блокировщиками расходятся в разы - от примерно десятой части аудитории до четверти, - поэтому единственная значимая цифра тут ваша собственная, снятая на своём сайте.

Три технических требования, которые снимают большую часть риска: форма должна отправляться, даже если капча не загрузилась; защита от спама обязана дублироваться на стороне сервера; чем меньше сторонних скриптов участвует в отправке, тем меньше точек отказа.

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

В согласии указывают цели, перечень собираемых данных, срок и порядок отзыва. Галочка на форме не должна стоять по умолчанию, а ссылка рядом с ней должна вести на отдельный документ. Штрафы по статье 13.11 КоАП для организаций начинаются от 100 000 рублей и по отдельным составам доходят до 700 000 (разбор на «Гаранте»). На этом сайте согласие вынесено на отдельную страницу - согласие на обработку персональных данных.

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

Восемь шагов, которые не требуют программиста.

• 1. Отправьте тестовую заявку с телефона на мобильном интернете, а не с офисного компьютера: так форму видит большинство посетителей.
• 2. Повторите отправку на три разных ящика - корпоративный, Яндекс и Mail. Письмо, которое дошло на один и не дошло на другой, сразу указывает на проблему с аутентификацией домена.
• 3. Загляните в папку «Спам». Если письмо там, откройте служебные заголовки и найдите строку Authentication-Results: в ней должно быть spf=pass, dkim=pass, dmarc=pass.
• 4. Прогоните письмо через mail-tester.com: сервис выдаёт спам-рейтинг и разбор SPF и DKIM.
• 5. Подключите постмастер почтовых сервисов - подтверждённому владельцу домена он показывает доставку, попадания в спам, блокировки и жалобы.
• 6. Откройте форму с включённым блокировщиком рекламы и без него, сравните поведение.
• 7. Посмотрите, кто сейчас числится получателем заявок, и совпадает ли этот список с теми, кто реально отвечает клиентам.
• 8. Засеките, через сколько минут заявку увидел живой человек. Это и есть ваша настоящая скорость ответа.

Порядок важен: чинить лучше не по сложности, а по тому, сколько заявок каждая мера возвращает.

• Дубль заявки помимо почты. Пока заявка существует только в виде письма, любая проблема с доставкой равна потере клиента. Сохранение в базу, CRM или мессенджер закрывает сразу половину сценариев из этой статьи.
• Аутентификация домена. SPF, DKIM и DMARC настраиваются один раз и разом снимают проблему спама и тихих удалений.
• Список получателей. Самая дешёвая правка с самым быстрым эффектом: минута работы, а заявки перестают уходить в пустоту.
• Капча и лишние скрипты. Уберите всё, без чего форма может обойтись, а остальное перенесите на российские сервисы.
• Регламент реакции. Договоритесь, за сколько минут заявку берут в работу, и измеряйте это.

Заодно продумайте запасной канал захвата: ИИ-чат на сайте отвечает посетителю сразу и фиксирует контакт даже тогда, когда форма подвела.

Пройдитесь по списку и отметьте, что у вас закрыто.

• Заявка сохраняется где-то ещё, кроме почты.
• У домена настроены SPF, DKIM и DMARC, а тестовое письмо проходит все три проверки.
• Письма доходят минимум на три разных почтовых сервиса и не попадают в спам.
• В списке получателей только действующие сотрудники, ящики не переполнены.
• Форма показывает «Спасибо» только после подтверждения сервера, а при ошибке говорит об ошибке.
• Форма отправляется при включённом блокировщике рекламы и при неработающей капче.
• Капча российская или отсутствует, защита от спама продублирована на сервере.
• Согласие на обработку данных - отдельный документ, галочка не предзаполнена, ошибка подсвечивается.
• Известно среднее время от заявки до первого ответа человека.
• Тестовая заявка отправляется регулярно, а не один раз после запуска сайта.

Скорее всего, у сервисов разная строгость фильтров, а домен не подписан. Тот, кто строже, применяет политику DMARC и отправляет письмо в спам или удаляет его. Лечится настройкой SPF и DKIM, а не сменой текста письма.

Минимум, который требует Google с февраля 2024 года, - SPF или DKIM. На практике имеет смысл настроить все три: без DMARC вы не получаете отчёты и не видите, что часть писем отбрасывается.

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

В любое место, которое не зависит от почты: CRM, база на стороне сайта, уведомление в мессенджер. Лучше два канала сразу - тогда сбой одного вы заметите по тишине в другом.

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

• Требования Google к отправителям писем
• Аутентификация отправителя в Mail.ru
• Исследование Lead Response Management о скорости ответа
• Новые требования к согласию на обработку персональных данных
• Документация Яндекс SmartCaptcha