Не приходят письма с сайта: где рвётся цепочка и как поймать

3 августа 2026 · 8 мин чтения

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

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

Чтобы письмо с сайта дошло до человека, оно проходит три звена, и «не приходят письма» — это обрыв на одном из них:

1. Сайт отправляет письмо. CMS (WordPress, 1С-Битрикс, самописный движок) формирует письмо и передаёт его почтовому серверу — через встроенную функцию или через SMTP.
2. Почтовый сервер принимает и пересылает. Сервер отправителя отдаёт письмо серверу получателя.
3. Письмо попадает во «Входящие» получателя. Именно во «Входящие», а не в «Спам».

Разберём, что ломается на каждом звене.

Звено 1. Сайт вообще не отправил письмо

• Не настроена отправка почты. Многие сайты по умолчанию отправляют письма встроенной функцией сервера (в PHP это mail()). На современных хостингах она часто отключена или работает ненадёжно — письмо «отправляется» в никуда. Правильно — настроить отправку через SMTP (внешний почтовый сервис), но это делают не всегда.
• Сломался плагин или интеграция. Обновился плагин формы, слетели настройки SMTP-плагина, поменялся пароль почтового ящика — и отправка тихо перестала работать.
• Ошибка в коде формы. Доработка формы, переезд сайта, смена темы — и письмо перестало формироваться, хотя форма визуально работает и показывает «спасибо».

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

Звено 2. Отправил, но письмо не дошло до сервера получателя

• Хостинг режет исходящую почту. Часть хостингов закрывает прямую отправку (порт 25) или ставит жёсткие лимиты, чтобы бороться со спамом. Письмо уходит «в стенку».
• Почтовый сервер получателя отклонил письмо (bounce). Домен отправителя в чёрных списках, IP хостинга с плохой репутацией — принимающий сервер молча отвергает письмо.
• Неверный адрес получателя. Опечатка в настройках, старый ящик сотрудника, переполненный ящик — письмо уходит, но приходить ему некуда.

Звено 3. Дошло, но улетело в спам

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

• SPF — какие серверы имеют право отправлять почту от имени домена.
• DKIM — цифровая подпись, подтверждающая, что письмо не подделано.
• DMARC — правило, что делать с письмами, не прошедшими SPF и DKIM.

Без этих записей почтовые сервисы не доверяют отправителю и отправляют письма в спам — особенно новые домены и письма с хостинга общего пользования.

Почему это замечают поздно

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

Как понять, где именно рвётся цепочка

Разовая диагностика идёт по звеньям сверху вниз:

• Логи отправки на сайте. Пыталась ли CMS отправить письмо вообще? Если в логах пусто — обрыв на звене 1, дело в настройке отправки (SMTP, плагин, код).
• Тестовое письмо и bounce. Отправьте письмо на внешний ящик и посмотрите, не вернулось ли оно с ошибкой. Возврат — звено 2 (хостинг, репутация, адрес).
• Папка «Спам» и записи домена. Проверьте, не лежит ли письмо в спаме, и сверьте SPF, DKIM, DMARC. Спам при формальной доставке — звено 3.

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

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

Проверять надо не «отправилось ли с сайта», а дошло ли письмо до ящика — то есть конечный результат всей цепочки. Именно это делает проверка доставки формы в Pingvera: система по расписанию отправляет тестовую заявку через форму вашего сайта — с уникальным маркером в тексте — и затем проверяет контрольный почтовый ящик: пришло ли письмо с этим маркером. Пришло — тракт исправен на всех трёх звеньях. Не пришло за отведённое время — приходит оповещение в Telegram, на почту или в Max, и вы узнаёте о проблеме сразу, а не через неделю потерянных заявок.

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

Проверка доставки идёт рядом с обычным мониторингом доступности, домена и SSL — то есть сайт контролируется не только как «открывается ли», но и как работающий бизнес-инструмент: доходят ли через него заявки и письма.

Читайте также: Не приходят заявки с сайта: почему форма молчит и как это ловить · Карта бизнес-путей сайта: практический шаблон · Магазин работает, а заказов нет: 5 тихих поломок чекаута · Статус-страница, которую читают не только люди · Бесплатно проверить сайт.