Куда пропадают заявки с сайта

Самая опасная проблема формы на сайте — та, которую никто не замечает. ⚠️

Посетитель заполняет форму.

Нажимает «Отправить».

Видит сообщение:

💬 «Спасибо! Ваше сообщение отправлено».

Менеджер ждёт письмо.

Письма нет.

Через час его всё ещё нет.

Через день никто не звонит клиенту.

А сайт продолжает работать как ни в чём не бывало.

⚠️ Именно поэтому проблемы с отправкой почты опаснее обычной ошибки на странице.

Если сайт показывает PHP error или перестаёт открываться, проблему быстро замечают.

Если письмо потерялось после отправки — об этом может не узнать никто.

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

Разберём, почему это происходит, как устроена отправка писем из WordPress и как проверить, действительно ли заявки доходят до адресата.

Что происходит после нажатия кнопки «Отправить»

Многие воспринимают форму на сайте очень просто:

клиент → форма → письмо менеджеру

Но технически цепочка гораздо длиннее.

Упрощённо она выглядит так:

Браузер посетителя → WordPress → форма → механизм отправки → почтовый сервер → почтовый провайдер → почтовый ящик менеджера

И проблема может возникнуть практически на любом этапе. 🔎

Например:

❌ JavaScript не отправил форму;
❌ сервер не обработал запрос;
❌ WordPress сформировал письмо с неправильным адресом;
❌ PHP попытался отправить письмо через локальный mail-сервис;
❌ почтовый сервер отклонил сообщение;
❌ письмо ушло, но попало в спам;
❌ отправитель не прошёл SPF/DKIM-проверку;
❌ почтовый сервис посчитал сообщение подозрительным;
❌ письмо было принято, но отфильтровано уже внутри корпоративной почты.

💡 Поэтому фраза «WordPress отправляет письмо» ещё не означает, что письмо получил человек.

Это принципиальная разница.

Где чаще всего ломается цепочка

Условно проблемы можно разделить на четыре уровня.

Уровень 1. Форма

Посетитель не может корректно отправить данные.

Причина может быть в:

JavaScript;
CAPTCHA;
AJAX;
конфликте плагинов;
неправильной валидации;
серверной ошибке.

В этом случае письмо вообще не формируется.

Уровень 2. WordPress

Форма отработала, но WordPress не смог нормально передать письмо дальше.

Здесь встречаются проблемы с:

wp_mail();
серверной конфигурацией;
PHP Mail;
SMTP;
DNS;
настройками отправителя.

Уровень 3. Почтовый сервер

Сообщение сформировано, но почтовая инфраструктура его не принимает или отклоняет.

Причиной может стать:

отсутствие SPF;
ошибка DKIM;
неправильный DMARC;
подозрительный IP;
плохая репутация отправляющего сервера;
неверный reverse DNS;
слишком большое количество похожих сообщений.

Уровень 4. Почтовый ящик

Письмо дошло до почтового сервиса, но не оказалось во «Входящих».

Оно может попасть:

в спам;
в карантин;
в другую папку;
под автоматическое правило;
под корпоративный фильтр безопасности.

🔎 Поэтому диагностика должна идти от формы до конечного почтового ящика, а не заканчиваться на кнопке «Отправить».

Почему стандартный PHP Mail — слабое место

WordPress для отправки писем часто использует функцию wp_mail().

Важно понимать: сама wp_mail() не является полноценным почтовым сервером.

Она передаёт задачу почтовой инфраструктуре сервера.

На простом хостинге это может работать годами.

А потом внезапно перестать. ⚠️

Например, хостинг меняет настройки сервера, усиливает антиспам или меняет правила исходящей почты.

WordPress при этом продолжает работать.

Страницы открываются.

Админка доступна.

Форма визуально исправна.

Но сообщения перестают доходить.

❗ Именно поэтому проверка формы только через интерфейс сайта недостаточна.

Почему SMTP обычно надёжнее

SMTP позволяет отправлять почту через конкретный почтовый сервер.

Вместо условной схемы:

WordPress → непонятный механизм сервера → получатель

получается более контролируемая:

WordPress → SMTP-сервис → почтовый сервер получателя

При этом можно использовать корпоративную почту или специализированный сервис отправки.

Преимущество не только в самой доставке.

Появляется возможность контролировать:

адрес отправителя;
авторизацию;
TLS/SSL;
журнал отправки;
ошибки;
статус доставки;
отклонённые сообщения.

💡 Для сайта, который ежедневно получает реальные заявки, это значительно важнее, чем просто увидеть зелёное сообщение «Форма отправлена».

Contact Form 7 может показать успех, даже если клиент не получил письмо

Это один из моментов, который часто вводит владельцев сайтов в заблуждение.

Форма Contact Form 7 может успешно обработать запрос.

Пользователь увидит сообщение об успешной отправке.

Но дальше письмо может не попасть в нужный почтовый ящик.

Получается два разных события:

Форма приняла данные

Почтовая система доставила письмо.

Это не одно и то же. ❗

Поэтому при проверке формы нужно тестировать не только саму отправку, но и весь маршрут сообщения.

Проблема №1 — неправильный адрес отправителя

Одна из распространённых ошибок — использовать адрес посетителя в поле From.

Например, клиент вводит:

client@gmail.com

И сайт пытается отправить письмо менеджеру так, будто отправителем является Gmail клиента.

Для почтовой системы это может выглядеть подозрительно.

Гораздо правильнее разделять:

From — адрес корпоративного домена сайта.

Reply-To — адрес клиента.

Например:

From:
website@company.kz

Reply-To:
client@gmail.com

Тогда письмо отправляется от контролируемого домена, а ответ менеджер может направить непосредственно клиенту.

✅ Такая схема лучше соответствует современной логике проверки отправителей.

SPF: почтовый сервер должен знать, кому можно отправлять письма

SPF — это DNS-запись, которая указывает, какие серверы имеют право отправлять почту от имени домена.

Представим компанию company.kz.

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

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

В итоге SPF должен учитывать реальную инфраструктуру.

⚠️ Просто добавить случайную запись из интернета недостаточно.

Неправильный SPF способен создать новые проблемы, если в нём забыть существующего почтового провайдера.

DKIM: письмо получает криптографическую подпись

DKIM работает иначе.

Почтовый сервер подписывает исходящее сообщение специальным ключом.

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

Для бизнеса это важно по двум причинам:

повышается доверие к отправителю;
снижается вероятность проблем с доставляемостью.

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

заявки;
уведомления;
подтверждения регистрации;
сообщения интернет-магазина;
уведомления о заказах;
письма восстановления пароля.

DMARC связывает SPF и DKIM с политикой домена

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

Это уже не просто вопрос:

«Есть ли SPF?»

И не только:

«Есть ли DKIM?»

Важна согласованность всей схемы.

Например, домен может иметь SPF, но письмо отправляется с другого домена в поле From.

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

DMARC помогает контролировать подобные ситуации.

Но вводить жёсткую политику без предварительной проверки инфраструктуры тоже рискованно.

⚠️ Если настроить её неправильно, можно начать блокировать собственные легитимные письма.

Почему письмо может попасть в спам

Даже если технически письмо было доставлено, это не означает, что менеджер увидит его во «Входящих».

На решение почтового сервиса влияет множество факторов.

Например:

репутация отправителя;
домен;
IP-адрес;
содержимое письма;
история отправок;
техническая аутентификация;
поведение получателей;
наличие подозрительных ссылок;
массовость отправки.

Поэтому сообщение:

«Письмо отправляется»

не равно:

«Письмо доставлено во входящие».

Это две разные метрики.

Почему тест «отправил себе письмо» ничего не гарантирует

Допустим, разработчик открыл сайт, заполнил форму и получил письмо.

Можно ли считать проблему решённой?

Нет.

Один успешный тест подтверждает только один конкретный сценарий.

На практике стоит проверить несколько вариантов:

Gmail;
корпоративную почту;
другой домен;
мобильное устройство;
разные формы;
несколько адресов получателей.

Иногда письмо приходит на личный Gmail, но не проходит в корпоративную почту.

Иногда проблема проявляется только с определённого адреса.

Иногда обычные сообщения доходят, а письма WooCommerce — нет.

🔎 Одна успешно полученная тестовая заявка ещё не доказывает надёжность всей системы.

Как отличить проблему формы от проблемы почты

Это один из первых вопросов при диагностике.

Предположим, посетитель говорит:

«Я отправил заявку, но мне никто не ответил».

Здесь возможны минимум три сценария.

Сценарий 1. Форма вообще не сохранила заявку

Тогда проблема находится на уровне сайта.

Сценарий 2. Заявка сохранилась, но письмо не ушло

Проблема находится между WordPress и почтовым сервером.

Сценарий 3. Письмо ушло, но менеджер его не увидел

Проблема находится на стороне доставки или почтового ящика.

💡 Поэтому хороший способ защиты — не делать email единственным местом хранения заявки.

Заявка должна сохраняться независимо от почты

Для коммерческого сайта это один из самых полезных принципов.

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

Тогда возникает резервная цепочка:

Форма → запись заявки → уведомление по email

Если email временно не работает, данные не исчезают.

Менеджер может получить их после восстановления почты.

Это особенно важно для:

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

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

Что проверить, если заявки перестали приходить

Начинать нужно не с переустановки плагина.

Сначала нужно установить точку отказа. 🔎

Проверка №1. Доходит ли запрос до WordPress

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

Проверка №2. Создаётся ли письмо

Проверить настройки формы и почтовые поля.

Особое внимание:

To;
From;
Reply-To;
Subject;
формат сообщения.

Проверка №3. Есть ли журнал отправки

Если используется SMTP-плагин или внешний сервис, проверить журнал.

Он позволяет увидеть:

была ли попытка отправки;
успешно ли сообщение передано;
возникла ли ошибка;
какой SMTP-сервер использовался.

Проверка №4. Что происходит с DNS

Проверить:

SPF;
DKIM;
DMARC;
MX;
при необходимости связанные DNS-записи.

Проверка №5. Что видит получатель

Проверить папки:

Входящие;
Спам;
Карантин;
Промоакции;
другие автоматические категории.

Проверка №6. Есть ли заявка в системе

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

Именно здесь иногда обнаруживается самая неприятная картина:

🚨 В системе 17 заявок, а менеджер получил только 12 писем.

Пять обращений уже потеряны из рабочего процесса.

Как понять, что сайт уже теряет заявки

Есть несколько тревожных сигналов. 🚨

Первый:

Клиенты говорят, что оставляли заявку, но менеджеры её не видят.

Второй:

Письма приходят с большой задержкой.

Третий:

Часть форм работает, а часть — нет.

Четвёртый:

Письма регулярно попадают в спам.

Пятый:

После переноса сайта или хостинга почта перестала работать.

Шестой:

После изменения DNS перестали приходить уведомления.

Седьмой:

На сайте нет истории отправленных заявок.

Если появляется хотя бы один из этих признаков, стоит проверить цепочку доставки.

Перенос сайта часто ломает почту

Смена хостинга — не только перенос файлов WordPress.

Если старая инфраструктура отвечала ещё и за отправку почты, после переезда могут измениться:

IP;
SMTP;
DNS;
SPF;
DKIM;
reverse DNS;
правила сервера.

Сам сайт при этом откроется.

Поэтому после миграции часто проверяют только страницы.

❌ Это ошибка.

После переноса нужно отдельно протестировать:

формы;
уведомления;
регистрацию;
восстановление пароля;
WooCommerce;
SMTP;
интеграции;
корпоративную почту.

⚠️ Сайт, который открывается после миграции, ещё не обязательно работает полностью.

Особый случай — интернет-магазин

Для WooCommerce проблема с почтой становится ещё серьёзнее.

Через email могут отправляться:

подтверждения заказа;
уведомления администратора;
изменения статуса заказа;
сброс пароля;
сообщения клиенту;
уведомления о регистрации.

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

Клиент может оформить заказ и не получить подтверждение.

Менеджер может не узнать о новом заказе.

Сотрудник может не увидеть изменение статуса.

🛒 Поэтому для магазина почтовая инфраструктура должна рассматриваться как часть коммерческой системы, а не как второстепенная функция WordPress.

Почему нельзя бесконечно менять SMTP-плагины

Когда письма перестают приходить, иногда начинают экспериментировать:

«Поставим другой SMTP-плагин».

Если не установлена причина проблемы, это может ничего не изменить.

Плагин — только инструмент.

Если неправильно настроен DNS, новый SMTP-плагин не исправит SPF.

Если заблокирован аккаунт почтового сервиса, установка другого плагина не решит проблему.

Если письмо попадает в корпоративный карантин, проблема может быть вообще за пределами WordPress.

🔧 Поэтому сначала диагностика, потом изменение конфигурации.

Минимальная надёжная схема для сайта

Для большинства коммерческих WordPress-сайтов разумно стремиться к такой архитектуре:

Посетитель → Форма WordPress → Сохранение заявки → SMTP / транзакционный почтовый сервис → Почтовый сервер → Менеджер

Параллельно должна существовать возможность проверить:

что произошло с конкретной заявкой.

Если менеджер говорит:

«Письма не было».

Технический специалист должен иметь возможность установить:

форма получила заявку или нет;
письмо было сформировано или нет;
WordPress попытался его отправить или нет;
SMTP принял сообщение или нет;
сервер получателя его принял или отклонил;
письмо оказалось в спаме или карантине.

🔎 Без такой диагностики поиск превращается в угадывание.

Что стоит сделать владельцу сайта

Не нужно каждый день проверять DNS-записи.

Достаточно организовать контроль.

Раз в несколько месяцев

Отправлять тестовые заявки на разные почтовые адреса.

После изменений

Обязательно тестировать почту после:

переноса хостинга;
изменения DNS;
смены домена;
установки нового SMTP;
изменения формы;
обновления крупных компонентов;
подключения CDN;
изменения корпоративной почты.

Постоянно

Следить за тем, чтобы заявки не существовали только в email.

💡 Если обращение имеет коммерческую ценность, оно должно иметь отдельную точку хранения.

Чек-лист проверки формы WordPress

Форма

✅ Форма действительно отправляет данные.
✅ Нет ошибок JavaScript.
✅ CAPTCHA работает.
✅ Все обязательные поля обрабатываются.
✅ Сообщение об успехе соответствует реальному результату.

WordPress

✅ Настроена корректная отправка почты.
✅ Проверена функция wp_mail().
✅ Нет конфликтов плагинов.
✅ Есть журнал отправки.

SMTP

✅ Используется авторизованный SMTP.
✅ Корректно настроен TLS/SSL.
✅ Данные авторизации актуальны.
✅ Проверяются ошибки отправки.

DNS

✅ SPF настроен корректно.
✅ DKIM работает.
✅ DMARC соответствует инфраструктуре.
✅ DNS-записи не конфликтуют между собой.

Получатель

✅ Письмо приходит во «Входящие».
✅ Не попадает в спам.
✅ Не блокируется корпоративным фильтром.
✅ Адрес получателя актуален.

Заявки

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

Главная ошибка — проверять только кнопку

Владелец сайта обычно проверяет форму следующим образом:

открыл сайт;
ввёл имя;
указал телефон;
нажал кнопку;
увидел «Спасибо»;
получил письмо.

Если всё получилось — форма считается рабочей.

Но такой тест не показывает, что произойдёт завтра.

Не показывает, попадёт ли письмо в спам.

Не показывает, что будет после смены IP.

Не показывает, сможет ли корпоративный сервер принять письмо.

Не показывает, что произойдёт при временной ошибке SMTP.

И главное — не показывает, сколько заявок сайт потерял раньше.

❗ Поэтому проверять нужно не кнопку, а всю цепочку доставки.

Что происходит с бизнесом, когда заявки теряются

Проблема редко выглядит как большая техническая авария.

Она проявляется в цифрах. 📉

Компания запускает рекламу.

Получает 1000 посетителей.

Конверсия формы — 3%.

Это 30 потенциальных обращений.

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

Владелец видит:

«Реклама приводит заявки».

Отдел продаж видит:

«Заявок мало».

Маркетолог меняет рекламную кампанию.

SEO-специалист ищет проблему в трафике.

Менеджеры считают, что лиды некачественные.

А причина может находиться вообще в почтовой инфраструктуре.

💰 Именно поэтому техническое состояние формы напрямую влияет на бизнес-метрики.

Как должна выглядеть нормальная диагностика

Если сайт перестал отправлять заявки, специалисту не стоит сразу говорить:

«Переустановим Contact Form 7».

Нормальная диагностика начинается с вопроса:

🔎 На каком этапе исчезает сообщение?

Дальше проверяется вся цепочка:

Отправляется ли запрос.
Получает ли его WordPress.
Обрабатывает ли его форма.
Сохраняется ли заявка.
Формируется ли письмо.
Передаётся ли оно SMTP.
Принимает ли его почтовый сервер.
Проходит ли оно SPF/DKIM/DMARC.
Попадает ли оно во входящие.
Можно ли подтвердить доставку.

🛠️ Только после этого имеет смысл менять настройки.

Такой подход экономит время и позволяет не маскировать проблему случайными изменениями.

Форма на сайте — это не просто несколько полей и кнопка.

Для бизнеса это входная точка продаж.

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

Самое неприятное, что сайт при этом может выглядеть полностью исправным.

Страницы открываются.

WordPress работает.

Форма показывает сообщение об успешной отправке.

Но письмо не доходит.

Чтобы этого не происходило, нужно контролировать всю цепочку:

форма → WordPress → SMTP → DNS-аутентификация → почтовый сервер → почтовый ящик

А критически важные заявки лучше сохранять независимо от электронной почты.

Тогда даже временный сбой почтовой системы не означает потерю обращения.

🚨 Если сайт приносит бизнесу заявки, его почта должна рассматриваться не как второстепенная функция WordPress, а как часть коммерческой инфраструктуры.

Если самостоятельно разбираться с SMTP, DNS, резервными каналами и диагностикой доставки нет необходимости, такую задачу можно передать на техническое сопровождение WordPress-сайта.

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

А сотни пропущенных заявок уже превращаются в проблему, которую невозможно увидеть в Google Analytics или в панели WordPress.