После переноса в Timeweb сайт открывается, почта принимает входящие, но новые письма клиентам оказываются в Спаме. Слово «перенос» здесь скрывает несколько разных операций. Смена регистратора, NS-серверов, веб-хостинга и почтового сервиса по-разному влияет на отправку. Для начала восстановите точную последовательность изменений.
Если перенесена только регистрация домена, исходящий SMTP мог остаться прежним. Если изменены DNS, могли потеряться записи старого отправителя. Если перенесён сайт, локальные письма могут идти с нового сервера, хотя адрес From не менялся. Эти сценарии требуют разных действий.
Перед завершением перехода проверьте адрес, на который приходят отчёты о недоставке. Старый ящик возвратов может перестать обслуживаться раньше, чем закончится отправка старой очереди. Тогда команда потеряет важные диагностические ответы. Сохраните рабочий способ получать возвраты для используемого маршрута и проверьте его отдельно от красивого имени отправителя в обычном письме.
Составьте карту до и после
Запишите прежнего и нового регистратора, NS, сервер сайта, почтовый сервис сотрудников и транспорт уведомлений. Добавьте CRM и другие системы, которым разрешено отправлять от домена. Рядом укажите дату переключения. Это позволяет сопоставить жалобу с конкретным изменением, а не объявлять весь перенос причиной фильтрации.
Возьмите по одной исходной копии до и после переключения, если они доступны. Сравните From, домен DKIM, селектор и технический адрес возвратов. Историческая копия помогает установить различие маршрутов, но её прежняя папка не всегда известна. Не восстанавливайте прошлый результат по памяти сотрудника как точный замер.
Проверьте действующую DNS-зону
При смене NS важна полнота перенесённых записей. Копирование только A и MX недостаточно для всех отправляющих систем. В документации Timeweb о почтовых записях рассмотрены SPF, DKIM и DMARC. Сверяйте значения с фактическими сервисами, которые продолжают работать, а не заменяйте всё стандартным набором нового хостинга.
Для каждого старого DKIM-селектора выясните, используется ли он ещё. Не удаляйте его только потому, что появился новый ключ. Аналогично проверьте источники в SPF: отдел продаж может продолжать отправлять через прежнюю систему, пока сайт уже работает через новую. Любое удаление должно соответствовать завершённому переключению конкретного потока.
Не принимайте рабочий MX за исправленную отправку
Если входящие приходят, это подтверждает работу входящего маршрута в проверенных условиях. Исходящие могут использовать совершенно другой сервис. Например, сотрудники продолжают работать через внешний SMTP, а сайт после переноса вызывает локальную почтовую функцию Timeweb. Для таких потоков нужны отдельные проверки.
Не меняйте MX, чтобы «починить спам» исходящей почты, если входящий маршрут исправен и его перенос не планировался. Проверьте настройки приложения и полученную копию. Для PHP-отправки полезна инструкция Timeweb по mail(): её технический отправитель может отличаться от ящика, настроенного в почтовой программе.
Учтите кэш и переходный период
После изменения DNS разные запросы могут временно показывать разные значения из-за кэширования. Сохраните время публикации и ответы авторитетных серверов. Не назначайте универсальное число минут, через которое вся почта обязана заработать: это зависит от записей, TTL и предыдущих ответов.
Письма, уже находящиеся в очередях, могут отправляться по прежней конфигурации. Поэтому сравнивайте время создания, передачи и получения. Старое задание, доставленное после переноса, не обязательно использовало новый маршрут. Для чистого опыта сформируйте новое безопасное событие после подтверждения настроек.
Проверьте каждый важный поток
Через Check проверьте размещение письма сотрудника и уведомления сайта отдельно. Сохраняйте рабочий шаблон и отправителя; замените только данные, которые нельзя передавать в тест. Используйте доступные контрольные адреса, а не придуманный список поддерживаемых провайдеров.
При обнаруженной ошибке исправьте один участок и повторите соответствующий поток. Если меняется весь SMTP, сравнивайте именно маршруты. Если исправляется ключ, сохраните остальные параметры. Общий итог «перенос завершён» полезно разделить на проверенные сценарии: переписка, форма, заказ, восстановление доступа.
Зафиксируйте границы результата
Подтверждённая папка относится к конкретной копии. Разные папки у разных принимающих сервисов не показывают, что DNS частично «работает», без отдельного технического подтверждения. Если наблюдений нет, укажите пробел, а не записывайте автоматический отказ.
Ограничения и источники технических данных описаны в методологии Check. Завершайте перенос документированной схемой отправки и сохранёнными контрольными результатами. Тогда следующая жалоба будет сравниваться с известным состоянием, а настройки можно будет восстановить без повторного поиска по нескольким кабинетам.
Видео-памятка: что проверить
Видео без звука, 24 секунды. Текстовая версия краткого плана:
- Уточните, что перенесено: регистрация, DNS, сайт или почта.
- Сохраните записи всех действующих отправителей.
- Сравнивайте письма до и после изменения маршрута.