SMTP не работает: почему сайт не отправляет письма

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

Важно различать использование SMTP Яндекса для исходящей отправки и отправку с другого сервера на ящик Яндекса. В первом случае сайт обращается к выбранному сервису отправителя; во втором отказ может исходить от принимающей системы. Фраза «Яндекс не работает» не описывает эту разницу. Здесь разобран порядок проверки отправки сайта. Он не означает, что у провайдера сейчас есть общий сбой, и не предлагает обходить ограничения почтовых сервисов.

Начните с действия приложения, а не с настройки домена

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

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

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

Подключение и авторизация проверяются раздельно

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

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

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

Сохраните ответ сервера целиком, но без секретов

Код и текст отказа нужно связывать с этапом протокола и фактическим сервером. RFC 5321 различает классы SMTP-ответов, однако одна цифра без контекста не устанавливает причину конкретного сбоя. Запишите доступное пояснение и время. Временное отклонение, постоянный отказ по текущему запросу и успешный промежуточный шаг требуют разного разбора. Нельзя считать любой ответ сервера подтверждением приёма всего сообщения.

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

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

Принятие SMTP не равно попаданию во входящие

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

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

Проверьте реальный сценарий после исправления

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

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

Что передать специалисту и как принять результат

1. Назовите действие сайта, окружение и контролируемого получателя.
2. Приложите безопасный идентификатор попытки, время и точное сообщение отказа.
3. Укажите фактический сервис отправки и согласованный способ доступа без передачи секретов.
4. Сохраните найденный этап сбоя и основание изменения настроек или кода.
5. Проверьте передачу и появление контрольного сообщения у разрешённого получателя.
6. Разберите очередь переходного периода и зафиксируйте оставшиеся ограничения.

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