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

Если форма показывает «Спасибо, заявка отправлена», а письмо на почте так и не появилось — форма почти всегда ни при чём. Разрыв прячется дальше: в функции отправки на сервере, в SMTP-канале до почтового сервиса или в спам-фильтре получателя, который тихо отбрасывает письмо на входе.

Заявка, которая пропала между «спасибо» и «нет писем»

Отдел продаж московской логистической компании ждёт заявки с сайта — форма стоит на странице «Грузоперевозки», трафик идёт, счётчик Яндекс.Метрики показывает 14 отправленных форм за неделю. Обычно с такого объёма трафика приходит 3-4 письма в день, менеджер успевает перезвонить каждому в течение часа. В почтовом ящике sales@ — ни одного письма. Менеджер проверяет папку «Спам», ищет в архиве, звонит в поддержку хостинга — пусто.

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

Первое звено: браузер честно отправил форму

Первым делом в таких случаях проверяют то, что видно глазами — саму форму. Открывают консоль разработчика, смотрят вкладку Network при отправке: запрос уходит, сервер отвечает 200 OK, JavaScript-валидация не блокирует поля. Браузер сделал всё, что должен: собрал данные и передал их на сервер. Искать проблему здесь — терять время, звено рабочее.

Второе звено: сервер сказал «отправлено», а почта его не получила

Дальше запрос попадает в обработчик формы на сервере — обычно это PHP-функция, которая должна собрать письмо и передать его на отправку. Именно здесь чаще всего рвётся цепочка.

Почему mail() в PHP выглядит рабочей функцией и не работает

Стандартная функция mail() в PHP не проверяет, дошло письмо до адресата или нет — она передаёт сообщение локальному почтовому агенту сервера (обычно sendmail или postfix) и возвращает true, если передача состоялась технически. Что происходит с письмом дальше, функция не знает и не сообщает. На сервере логистической компании стоял именно такой вызов: mail() отдавал true при каждой отправке, три года назад разработчик счёл настройку почты завершённой на этом этапе. Но почтовый агент сервера не был авторизован ни у одного крупного почтового сервиса — Mail.ru и Яндекс.Почта видели письма с чужого IP без SPF-записи и отклоняли их на этапе SMTP-диалога, до всякого спам-фильтра.

Проверяется это логами почтового агента — файл /var/log/mail.log на сервере. Там напротив каждой попытки отправки видна строка reject или deferred, которую не покажет ни форма на сайте, ни админка. Команда tail -f /var/log/mail.log, запущенная в момент тестовой отправки формы, за несколько секунд показывает, дошло письмо до очереди или отклонено сразу — быстрее, чем перебирать гипотезы про спам-фильтры и пароли.

На сайте логистической компании разработчик три года назад тестировал форму с личной почты на Gmail — и письмо доходило, потому что Gmail в тот момент ещё принимал такие письма с предупреждением, а не отклонял. За прошедшее время требования почтовых сервисов к SPF и авторизации отправителя ужесточились, тестовое письмо перестало бы доходить и туда, но саму цепочку доставки заново никто не проверял — она считалась настроенной один раз и навсегда.

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

Бывает и так, что сервер отправил письмо корректно, SMTP-сессия завершилась успешно кодом 250 — а получатель его всё равно не увидел. Причина тогда в проверках репутации на принимающей стороне: у домена отправителя нет записи SPF, нет DKIM-подписи, либо DMARC-политика получателя настроена на жёсткий отказ для писем без подтверждённого источника. Такие письма не попадают даже в папку «Спам» — их отклоняют на этапе приёма, и это самый обманчивый случай: в логах сервера-отправителя всё выглядит успешно, а в почте пусто.

В разборе логистической компании письма после исправления кода стали доходить до сервера получателя, но ещё полторы недели падали именно в такую яму: SPF-запись домена указывала на старый IP хостинга, а форма отправляла через новый — домен переехал на другой сервер полгода назад, DNS-записи при переезде поправили не все. Формально — отправлено. Фактически — отклонено на входе.

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

Цена простоя: что теряет бизнес, пока обрыв не найден

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

Когда причину нашли, исправление заняло меньше часа: донастроить SPF-запись и перевести отправку с mail() на авторизованный SMTP. Час работы сисадмина по такой задаче стоит 3800 рублей — против двух недель заявок, которые компания не увидела и не может пересчитать в деньгах задним числом. Такую проверку цепочки обычно проводят не отдельно, а вместе с остальными пунктами аудита сайта по 9 направлениям — тогда обрыв находят до того, как он стоит две недели заявок.

После исправления первая заявка пришла в почту через 40 секунд после тестовой отправки — с корректным SPF, DKIM-подписью и без единого reject в логе. Отдел продаж вернулся к обычному ритму: заявки снова видно в тот же час, когда клиент заполнил форму, а не через две недели разбирательств.

Быстрая самопроверка: четыре шага до звонка специалисту

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

• ✓Отправить тестовую заявку через форму и засечь время: письмо должно появиться в ящике за секунды, а не минуты — задержка в несколько минут уже говорит о проблеме в очереди отправки.
• ✓Попросить того, кто администрирует сервер, открыть хвост лога почтового агента сразу после тестовой отправки — строка reject или deferred напротив своей попытки видна сразу.
• ✓Проверить SPF-запись домена через любой публичный сервис проверки DNS-записей — если запись указывает не на тот IP, с которого реально уходит почта, письма будут теряться независимо от кода формы.
• ✓Отправить тестовое письмо не только на корпоративный ящик, а ещё на личный на другом почтовом сервисе — так видно, режет письма конкретный домен получателя или обрыв общий, для всех адресов сразу.

Если хотя бы один из четырёх шагов показывает сбой, дальше разбираться быстрее с логами перед глазами, чем гадать по симптомам — «письма нет» может означать три разных места обрыва, и без логов их не отличить.

Три способа отправки писем с формы — что оказалось надёжнее

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

Как это закрывает аудит сайта по 9 направлениям

Цепочка форма → сервер → SMTP → почта получателя выпадает из поля зрения и разработчика, и маркетолога: разработчик проверяет, что форма отправляется, маркетолог смотрит на конверсии в Метрике, а то, что происходит после нажатия кнопки, не проверяет никто — пока заявки не пропадут физически.

В аудите сайта по 9 направлениям этот сценарий закрыт отдельным техническим пунктом: реальная тестовая отправка через каждую форму сайта с проверкой логов сервера, записей SPF и DKIM домена и факта доставки письма — а не визуальная проверка, что кнопка «отправить» кликается. Если цепочка рвётся, в отчёте указывается конкретное звено и способ его закрыть, а не общая рекомендация проверить почту.

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

❓ Частые вопросы

Почему форма показывает «письмо отправлено», а само письмо не приходит?

Форма показывает «отправлено» сразу после того, как браузер успешно передал данные на сервер — на этом её работа заканчивается. Дальше письмо должно пройти обработчик на сервере и SMTP-канал до почты получателя. Разрыв почти всегда происходит именно там, а не в самой форме — проверять нужно логи сервера, а не код формы.

Как проверить, что письмо действительно ушло с сервера, а не потерялось раньше?

Логи почтового агента сервера (обычно /var/log/mail.log) показывают статус каждой попытки отправки: строка reject или deferred видна сразу после тестовой заявки. Если письма там вовсе нет — обрыв на уровне обработчика формы; если оно ушло, но отклонено — проблема в SMTP-авторизации или репутации домена у получателя.

Что такое SPF и DKIM и почему без них письма теряются?

SPF-запись в DNS домена подтверждает, каким серверам разрешено отправлять почту от его имени; DKIM-подпись подтверждает, что письмо не изменено по пути. Без них крупные почтовые сервисы либо отклоняют письмо на этапе приёма, либо кладут его в спам — независимо от того, насколько корректно работает форма на сайте.

Сколько стоит исправить недоставку писем с формы сайта?

Зависит от того, что именно сломано: смена метода отправки с mail() на авторизованный SMTP и настройка SPF/DKIM обычно занимает у сисадмина около часа работы по ставке 3800 рублей. Если проблема глубже — в конфигурации сервера или почтового сервиса, — часов может понадобиться больше; точный объём виден после разбора логов.

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

Разово настроенная доставка ломается при переезде на другой сервер, смене хостинга, смене пароля от почтового ящика или ужесточении требований почтовых сервисов к SPF и DKIM — без видимых изменений на самом сайте. Цепочку форма → SMTP → почта стоит перепроверять при каждом релизе сайта или смене инфраструктуры, а не один раз.