# Письма с сайта перестали доходить. Причин было три

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

Интернет-магазин продуктов · 1С-Битрикс · кейс под NDA

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

Кейс закрыт соглашением о неразглашении: под плашками — домены, адреса и адрес сервера. Всё техническое оставлено как есть.

## Что мешало найти причину

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

## Слой первый: исходящий порт молча закрыт

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

Чтобы не спорить с хостингом словами, собрали доказательства: трассировка по 25-му порту глохла на первом же узле провайдера, а по 443-му проходила насквозь; сетевой дамп показывал запрос на соединение без единого ответа — тихое отбрасывание пакетов вышестоящей сетью. Локального файрвола на сервере не было.

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

## Слой второй: письма пошли, но их резали как спам

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

- В запись SPF добавили адрес сервера, с которого реально идёт отправка
- Подняли подпись DKIM: свой ключ на 2048 бит и фильтр в почтовом сервере
- Подпись подключили именно для писем, идущих не по SMTP: сайт отдаёт их локальной командой отправки, и на обычном SMTP-фильтре они бы прошли неподписанными
- Переписали адрес в конверте письма: заголовок был верный, а конверт — технический, и проверка SPF шла именно по нему

## Слой третий: сайт и сервер отправляли письма по-разному

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

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

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

## Что стало

- **2 недели** — без подтверждений заказов — столько длился сбой до нас
- **3** — независимые причины, каждая закрывала собой следующую
- **pass** — проверки SPF и DKIM у получателя
- **0** — писем в зависшей очереди после починки

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

## Чему это научило

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

## Другие разборы

- [BI-отчёт по платежам в облачном Битрикс24](https://it-zarya.ru/cases/bi-payments/) — Дашборд по платежам в семи валютах там, где код внутрь портала положить нельзя. Обошли ловушку в связях данных.
- [1 102 страницы городов на 37 доменах](https://it-zarya.ru/cases/multisite-cities/) — Тиражируемые страницы направлений в мультисайтовой установке: общий шаблон, различия в данных, единая выкатка на 37 доменов.
- [Приёмка проекта: утечка данных и потерянные миграции](https://it-zarya.ru/cases/clinic-handover/) — Разобрали чужой проект без документации, закрыли утечку персональных данных в логах, вернули боевой код под git.

## Похожая ситуация

Если письма с сайта не доходят, а причина не находится — расскажите, что происходит. Начнём с разбора: где именно теряются письма и на чьей стороне.

[Обсудить задачу](https://it-zarya.ru/contacts/) [Другие кейсы](https://it-zarya.ru/cases/)

---

Источник: https://it-zarya.ru/cases/mail-delivery/ · IT-агентство «Заря» · itzarya@mail.ru
Markdown-версия любой страницы сайта — тот же адрес с `.md` на конце. Индекс для ассистентов: https://it-zarya.ru/llms.txt