Перенос сайта без сломанной почты: что проверить заранее

Короткий ответ

При переносе сайта почта ломается не потому, что это «тонкая магия», а потому что её просто забывают включить в план. Люди концентрируются на главной странице, HTTPS и сервере, а MX, SPF, служебные TXT и TTL вспоминают уже после переключения. Для бизнеса и VPN-проекта это одна из самых неприятных ошибок: сайт вроде запустился, а обращения пользователей начинают теряться.

Перед переносом сайта особенно важно не забыть почтовую часть: она держится на той же логике домена для почты и на корректных DNS-записях.

В каких случаях это всплывает сразу

если вы меняете хостинг, DNS-провайдера или доменную схему;
если почта уже работает на домене и её нельзя терять даже на несколько часов;
если у сайта есть support, биллинг, уведомления или регистрационные письма.

В чём корень проблемы

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

Сайт и почта часто живут в одной зоне, но это не значит, что они меняются одинаково. Перенос сайта обычно связан с A/AAAA, reverse proxy, CDN или хостингом. Почта — с MX, TXT, SPF, DKIM и иногда отдельными платформенными настройками. Когда команда переносит сайт и думает, что «остальное подтянется само», она как раз и закладывает проблему.

Безопасный перенос почты требует простой дисциплины:

составить список всех релевантных записей;
заранее проверить TTL;
отделить перенос сайта от почтовой логики;
после переключения сверить и приём, и отправку.

Если меняются nameservers, внимательность нужна вдвойне. В таком случае важно перенести не «примерно нужные записи», а весь рабочий почтовый контур.

Где чаще всего ошибаются

Самая частая ошибка — забывают MX. Вторая — забывают SPF и другие TXT-записи. Третья — не проверяют, что у нового DNS-провайдера всё действительно скопировано и активно. Четвёртая — не тестируют почту после миграции, потому что «главная же открывается».

Для VPN-сайта это особенно неприятно, потому что почта поддержки и уведомлений часто оказывается критичнее, чем кажется. Потерянное письмо о проблеме с доступом или оплатой может стоить заметно дороже, чем короткая недоступность страницы.

Практика без лишней теории

Попадание писем в спам после переезда редко лечится одной MX-записью: обычно приходится проверять доставляемость корпоративной почты и фактических отправителей.

Перед переносом полезно проверить:

```bash

dig MX example.com +short

dig TXT example.com +short

dig @1.1.1.1 MX example.com +short

```

После переключения:

повторить проверку через несколько резолверов;
отправить тестовое письмо;
проверить получение и отправку;
посмотреть, не изменился ли SPF-контур.

Таблица: когда использовать, а когда нет

| Подход | Когда использовать | Когда лучше не делать |

|---|---|---|

| Отдельный чек-лист для почты | Всегда при переносе сайта или DNS | Никогда не считать почту «автоматическим приложением» к сайту |

| Снижение TTL до миграции | Когда планируется переключение зоны или IP | Когда TTL трогают уже в момент аварии |

| Отдельное тестирование mail flow | Когда есть support, billing, уведомления | Когда ограничиваются проверкой главной страницы |

Как это выглядит в реальном проекте

При переносе сайта команда аккуратно проверила редиректы, SSL и доступность главной. Через несколько часов выяснилось, что обращения от пользователей не приходят: в новой зоне не перенесли часть TXT и перепутали логику маршрутизации почты. Проблема быстро нашлась, но сам факт был показательным: сайт проверили как продукт, а почту — нет.

Контрольный чек

Перед миграцией выполните четыре шага:

1. зафиксируйте все почтовые записи;

2. сохраните TTL и ключевые TXT;

3. после переноса проверьте MX и отправьте тестовое письмо;

4. убедитесь, что support-адрес реально получает входящие.

Если тест делается только «в уме», значит проверки нет.

Перенос домена поддержки нельзя считать завершённым без проверки SPF, DKIM и DMARC: иначе успешной окажется только веб-часть, а почта начнёт терять доверие.

Перенос сайта не переносит почтовую репутацию

Во время миграции сайта часто внимательно проверяют A-запись и HTTPS, но не замечают, что вместе с DNS переезжают SPF, DKIM, DMARC и верификации почтовых сервисов. В результате страница открывается, а письма теряют доверие или часть входящих уходит не туда. Почтовые TXT нельзя считать мусором в зоне: это рабочая часть коммуникации с пользователями, платёжными сервисами и поддержкой.

Проверка почты после миграции

После переноса нужно проверить не только входящие, но и исходящие письма. Минимальный тест: отправить письмо на внешний ящик, ответить на него, проверить заголовки, убедиться в прохождении SPF/DKIM/DMARC и посмотреть, не изменился ли маршрут MX. Если сайт переехал на новый хостинг, а почта осталась у прежнего провайдера, это нормально только при сохранённых MX и TXT. Любая «автоматическая» замена DNS-зоны требует ручной сверки.

Симптом: входящие есть, исходящие в спаме

Такой симптом часто появляется после частичного переноса. MX может быть сохранён, поэтому письма принимаются, но SPF больше не включает реального отправителя, DKIM-ключ не перенесён или DMARC стал конфликтовать с новой платформой. Исправление начинается не с текста письма, а с DNS и заголовков: нужно увидеть, какой механизм проверки не проходит и какой сервис фактически отправляет письмо.

Как сохранить письма входа и поддержки при переезде

Разделите компоненты проекта

Сайт VPN сервиса может переехать независимо от почтового провайдера. Поддомены VPN и домен для VPN сервера внесите в план отдельно. Адрес VPN сервера не меняют только потому, что поменялся IP веб-сайта. Хостинг для VPN выбирают по назначению компонента, а не используют один новый адрес во всех записях подряд.

Снимок зоны до изменений

DNS для ВПН сохраните целиком, включая почтовые MX и TXT. Домен VPN должен оставаться под контролем прежнего законного владельца. Сертификат для VPN проверьте по механизму выпуска и продления. Сайт VPN после переноса должен открываться по ожидаемому имени; успешный ответ по IP не проверяет ни почту, ни TLS, ни кабинет.

Проверка пользовательского пути

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

Когда часть пользователей видит старую инфраструктуру

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

FAQ

Если я не меняю почтового провайдера, почта в безопасности?

Не всегда. При смене DNS можно потерять нужные записи, даже если сам провайдер тот же.

Нужно ли переносить SPF и другие TXT при миграции?

Да, если они участвуют в работе почтовой отправки и верификаций.

Можно ли переносить сайт и почту одновременно?

Можно, но это увеличивает число рисков. Лучше, чтобы процесс был чётко описан и протестирован.

Почему после переноса сайта работает VPN соединение, но не приходят письма для входа?

Сервер туннеля и почта могут не зависеть друг от друга. При переносе зоны иногда забывают MX, DKIM или SPF, а веб-приложение может остаться со старыми почтовыми настройками. Проверьте отправку и получение тестового служебного письма отдельно от главной страницы и подключения клиента.

Почему после переноса сайта VPN не приходит письмо для входа?

Вместе с веб-записями могли потеряться MX или TXT, хотя туннель продолжает работать. Сначала проверьте доставку письма и настройки отправителя, затем доступ пользователя к ящику. Домен для VPN может обслуживать и поддержку, и кабинет; переносите DNS для VPN с учётом почты, а не только нового IP сайта.