Вы настроили SMTP Timeweb, нажали «Отправить тест», увидели успешный ответ и решили, что доставка восстановлена. Но следующий счёт клиент нашёл в Спаме. Успешное подключение показывает, что приложение смогло взаимодействовать с сервером. Куда попала принятая копия, проверяют отдельно, на стороне получателя.
Задача этой инструкции — пройти путь после настройки подключения. Она подходит сайту, CRM или почтовой программе, которая действительно отправляет через SMTP Timeweb. Если Timeweb только хранит сайт, а исходящий сервер принадлежит другому сервису, используйте параметры того сервиса и проверяйте его маршрут.
Учебный пример: CRM успешно авторизуется одним ящиком, но уведомление отдельного филиала подставляет другой From. Служебный тест при этом использует адрес авторизации и проходит. Для проверки такой гипотезы сравните два рабочих события в журнале и заголовках. Исправляйте правило выбора отправителя в CRM, если именно оно подтверждено, а затем повторите уведомление филиала без изменения текста.
Сверьте совместимые параметры
Согласно документации Timeweb, исходящий сервер — smtp.timeweb.ru, для SMTP используется авторизация адресом почтового ящика. Вариант STARTTLS связан с портом 587, SSL — с портом 465. Настройка шифрования должна соответствовать выбранному порту; названия полей в приложениях могут различаться.
Не отключайте проверку сертификата ради зелёного статуса. Если защищённое подключение не проходит, сохраните ошибку и разберите её отдельно. Несовпадение имени сервера, недоступность сети и отказ авторизации происходят до определения папки. Переписывание темы сообщения такие ошибки не устраняет.
Проверьте, какой адрес приложение предъявляет
В инструкции Timeweb для CMS отдельно указано соответствие адреса отправителя ящику SMTP-авторизации. Поэтому сравните Username и From Email в настройках сайта. Псевдоним, который красиво выглядит в интерфейсе, не обязательно разрешён для выбранной учётной записи.
Дальше посмотрите заголовки полученной копии. Некоторые программы подставляют адрес из собственного профиля, а плагин доставки — другой. Не полагайтесь на сохранённое поле в административной панели: рабочее событие может переопределить отправителя. Адрес для ответа клиенту задаётся отдельно и не должен случайно заменять домен, от имени которого сайт отправляет письмо.
Тест плагина и письмо клиенту могут различаться
Короткое служебное сообщение обычно не содержит счёта, кнопок, персонализации и подписи менеджера. Даже если оно дошло во Входящие, результат не описывает автоматически рабочий шаблон. Сохраните тип сообщения, от которого поступила жалоба: подтверждение заказа, уведомление формы или ответ сотрудника.
Подготовьте безопасные тестовые данные и запустите тот же сценарий. Для счёта используйте демонстрационные реквизиты, для заказа — тестовую запись без оплаты и отгрузки. Ссылки и структура должны соответствовать проверяемому варианту; если вы их заменили, запишите это ограничение. Не отправляйте реальные клиентские документы ради диагностики.
Зафиксируйте исходное размещение
Откройте проверку письма в Check и возьмите доступные контрольные адреса текущего теста. Отправьте копию через настроенную интеграцию. Отдельно сохраните время принятия SMTP и время обнаружения в ящике. Положительный ответ сервера не подменяет наблюдение папки.
В результате рассматривайте каждого доступного принимающего провайдера отдельно. Спам, основные Входящие и дополнительная категория — разные состояния. Если нужного провайдера среди контрольных адресов нет, тест его не проверил. Если данные отсутствуют, сначала выясните, нет ли ошибки наблюдения или неподтверждённой доставки.
Выберите следующую проверку по фактам
При ошибке аутентификации домена проверьте отправителя и записи для фактического маршрута. При успешной аутентификации исследуйте конкретную гипотезу о рабочем письме. Например, сравните вариант с одной изменённой ссылкой, сохранив остальные элементы. Такой опыт не раскрывает правило фильтра, но делает изменение сопоставимым.
Не меняйте одновременно SMTP-сервис, From, HTML и тему. Если требуется заменить весь маршрут, прямо называйте опыт сравнением маршрутов и сохраняйте содержимое. При этом возможные различия в исходящих IP и подписях нужно записать, а не трактовать как контролируемую проверку единственного фактора.
Что считать завершённой проверкой
Подключение подтверждено, рабочий обработчик использует нужную учётную запись, полученная копия показывает ожидаемые адреса и подпись, а папки зафиксированы с временем. Это проверяемый результат. Формулировка «SMTP исправлен, значит всё попадёт во Входящие» значительно шире имеющихся данных.
Если SPF, DKIM и DMARC прошли, но папка осталась Спамом, сохраняйте этот факт без выдуманного объяснения. В методологии Check описаны границы технических проверок и наблюдения. Передайте поддержке очищенные заголовки и идентификатор конкретной отправки: такой материал полезнее списка всех настроек сайта без связи с письмом.
Видео-памятка: что проверить
Видео без звука, 24 секунды. Текстовая версия краткого плана:
- Подключение к SMTP и папка у получателя — разные проверки.
- Сопоставляйте From с ящиком SMTP-авторизации.
- Повторяйте рабочее письмо, сохраняя текст и ссылки.