Письма с сайта не доходят: что проверить в отправке и домене

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

Найдите событие и получателя

Запишите форму, время, идентификатор заявки и ожидаемое сообщение. Уведомление менеджеру и ответ посетителю проверяйте отдельно. Смотрите сохранённые адреса и настройки события. Если письмо формируется только после внешней передачи в CRM, задержка может начаться ещё до почтового этапа.

Для условного сайта консультаций запрос сохраняется сразу, а письмо ставится в фоновую очередь. При остановке задания заявки остаются доступны, но почта не отправляется. Такую ситуацию нельзя объяснить фильтром спама без проверки очереди. Сотруднику нужен способ увидеть обращение независимо от одного канала уведомлений.

Установите факт передачи сервису

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

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

Сопоставьте адреса и домен

Используйте согласованный адрес отправителя, которым сайт имеет право пользоваться. Адрес посетителя можно передавать как Reply-To по проверенным правилам, а не подставлять произвольным From. Уточните фактический домен и почтовый сервис. Внешне одинаковый адрес в шаблоне не означает правильную настройку доставки.

SPF описывает разрешённых отправителей, DKIM позволяет проверить доменную подпись, а DMARC связывает результат аутентификации с доменом From по своим правилам. Настройку берите у используемого провайдера. Требования почтовых получателей отличаются и меняются, поэтому проверяйте актуальную документацию для вашего объёма и сценария.

Меняйте DNS с учётом всех отправителей

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

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

Примите доставку на разных ящиках

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

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

Связанные материалы

Письма о заказах не приходят: где искать причину

Очередь фоновых задач: когда её стоит добавить в приложение

Договорённости по поддержке: задачи, сроки реакции и приоритеты

Документация для проверки

Требования к отправителям писем: Gmail

Ссылки на документацию проверены 8 октября 2026 года. Названия настроек и возможности сервисов могут меняться; перед внедрением сверяйте факты с актуальной документацией.