Перенос почты к новому провайдеру: порядок и проверка

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

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

Решение понятное, но не мгновенное: держите старую и новую системы работающими параллельно, заранее скопируйте архив писем, заблаговременно уменьшите DNS TTL, переключитесь в контролируемое окно и выполните заключительную синхронизацию изменений перед отключением старого сервиса.

Это практическое руководство, а не обещание «нулевого простоя». Здесь описан подход для условий 2025-2026.

Почему миграции почты дают сбой

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

Когда кто-то пишет на ваш домен, его сервер запрашивает MX-записи. Ответы кэшируют рекурсивные резолверы, почтовые шлюзы и другая инфраструктура в интернете. Сам SMTP описан в RFC 5321, но практическая проблема связана с эксплуатацией: серверы отправителей обновляют DNS-данные не одновременно.

В результате некоторое время работают два адресата доставки:

Отправитель A ещё видит старую MX-запись и доставляет письмо старому провайдеру.
Отправитель B видит новую MX-запись и доставляет письмо новому провайдеру.
Ваш пользователь проверяет только один ящик и уверен, что письма пропали.

Поэтому переключение в пятницу вечером по принципу «поменять записи и надеяться» рискованно. Чтобы уменьшить вероятность перерывов при переносе, нужна поэтапная миграция, а не одно переключение.

Что учесть до изменения DNS

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

Начните с ящиков, которые обычно требуют больше всего внимания:

1. Большие ящики. Всё, что превышает 20-50 GB, стоит планировать отдельно: перенос по IMAP занимает время, а провайдеры могут ограничивать скорость.
2. Общие адреса. `info@`, `sales@` и `support@` часто устроены не как обычные пользовательские ящики.
3. Псевдонимы и переадресации. Если `jane@` также получает письма для `hello@` и `jd@`, эти связи должны работать в новой системе с первого дня.
4. Ящики бывших сотрудников, на которые ещё приходит почта. Такие незаметные ошибки часто обнаруживаются спустя несколько недель.

Без этого этапа у вас не полноценный план миграции, а набор предположений.

Google прямо предупреждает: интенсивная синхронизация по IMAP может активировать защитные ограничения пропускной способности. В рекомендациях Google Workspace, приведённых в исходном снимке, указаны 2500 MB в день для скачивания по IMAP и 500 MB в день для загрузки по IMAP. При превышении ограничений блокировка может длиться до 24 часов; действующие условия нужно уточнять у провайдера. Поэтому копирование большого ящика может занять дни, а не часы.

При использовании TrekMail важно и устройство тарифов. Согласно исходному снимку, платные планы начинаются от $3.50 в месяц, используют общий пул хранения вместо оплаты за каждого пользователя и включают серверный инструмент миграции начиная со Starter. В зависимости от актуальных условий это может помочь заранее запустить целевую систему и дождаться длительного импорта в фоне, не оплачивая параллельно лицензии на каждого пользователя.

Практичный порядок переноса почты

Один из надёжных организационных подходов к переносу почты предусматривает параллельную работу: сначала подготовьте целевую систему, заранее скопируйте старые письма, уменьшите DNS TTL до переключения, смените MX в контролируемое окно, затем выполните заключительную синхронизацию изменений.

Порядок действий такой:

1. Сначала подготовьте целевую систему

Создайте домен, ящики, псевдонимы и правила переадресации на новой платформе до изменения MX. В TrekMail для этого нужно добавить домен, проверить готовность DNS-конфигурации и создать целевые ящики до запуска импорта.

Полезная документация: добавление домена, запуск миграции по IMAP и настройки IMAP/SMTP.

2. Заранее скопируйте старые письма

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

Инструмент миграции TrekMail переносит сообщения с внешних IMAP-серверов, например Gmail, Outlook и хостингов на базе cPanel, в конкретный ящик TrekMail. Включите пропуск дубликатов и проверяйте результат при повторном запуске заданий.

3. Уменьшите TTL за 48 часов

Уменьшите TTL записей MX и связанных DNS-записей примерно за 48 часов до переключения. 300 секунд могут служить практичным начальным значением. После истечения старых записей в кэше это способно сократить переходный период. Однако низкий TTL сам по себе не даёт оснований судить о реакции спам-фильтров.

Если вы также меняете настройки отправки, внимательно проверьте DNS. В документации TrekMail отмечена частая ошибка: создание второй SPF-записи вместо объединения include в одной записи.

4. Остановите изменения в старой системе

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

5. Измените MX и проверьте результат извне

Обновите MX-записи, затем проверьте, какие ответы видны из интернета.

dig mx example.com +short
nslookup -type=mx example.com

Не полагайтесь только на панель управления DNS. Выполняйте внешние запросы.

6. Выполните синхронизацию изменений

После смены MX запустите ещё один проход импорта. Он захватит письма, поступившие старому провайдеру во время переходного периода. Этот заключительный проход помогает перенести и входящие сообщения последних часов миграции.

7. Своевременно отключите старый пользовательский доступ

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

Какие DNS-записи обычно меняются при переключении

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

Точные значения зависят от провайдера, но общая схема выглядит так:

; Incoming mail
example.com.   300   IN MX 10 mail.your-new-provider.tld.

; SPF - keep only one SPF TXT record
example.com.   300   IN TXT "v=spf1 include:your-sender.example -all"

; DKIM - provider-specific selector and key
selector1._domainkey.example.com. 300 IN TXT "v=DKIM1; k=rsa; p=..."

; DMARC
_dmarc.example.com. 300 IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"

Особенно важны два правила:

1. Никогда не публикуйте две SPF-записи для одного имени хоста.
2. Не удаляйте старые записи отправки, пока не убедитесь, что через прежний сервис больше ничего не отправляется.

Если среди получателей много пользователей Gmail, учитывайте требования к отправителям. В FAQ Google, приведённом в исходном снимке, массовыми отправителями названы те, кто отправляет примерно 5,000 или больше сообщений в день на личные аккаунты Gmail. Для них обязательна аутентификация почты; усиление применения требований было заявлено с ноября 2025. Сверяйтесь с актуальной страницей FAQ Google о требованиях к отправителям.

Что на практике ломается при переносе почты

Большинство проблем миграции не выглядят как крупные аварии. Это малозаметные несоответствия: дублирование или пропуск писем, неправильная привязка папок, старые устройства с отправкой через прежний сервер и DNS-записи, обновлённые лишь частично.

Вот типичные сценарии:

Ограничения скорости IMAP

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

Дубликаты писем

Неправильно организованные повторные проходы или неудачные настройки устранения дубликатов могут повторно скопировать сообщения. Используйте параметры пропуска дубликатов, затем сверяйте число писем.

Проблемы с привязкой папок

Отправленные письма нередко попадают не в ту папку: одна система использует `Sent`, другая `Sent Items`, третья путь с пространством имён. Если пользователь говорит, что почта исчезла, проверьте, не лежит ли она в другой папке. Статья TrekMail об imapsync разбирает подобные эксплуатационные детали.

Старые ящики продолжают принимать почту

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

Старые клиенты отправляют через прежний сервер

Телефоны и профили Outlook сохраняют свои настройки. После переноса пользователям нужны новые параметры IMAP/SMTP, иначе клиенты продолжат обращаться к прежней системе. Если в рамках проекта вы также пересматриваете владельцев ящиков и восстанавливаете доступ, полезна статья об управлении почтой клиентов.

Как проверить миграцию по фактам

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

Используйте этот список:

1. Сравните число сообщений в исходном и целевом ящике для каждого пользователя.
2. Отправьте тестовые письма от внешнего провайдера на несколько адресов, включая псевдонимы и общие ящики.
3. Ответьте из нового ящика и проверьте, что письмо появилось в папке отправленных у нового провайдера.
4. Убедитесь, что старый провайдер больше не разрешает пользовательский вход.
5. Выполните внешние MX-запросы из нескольких сетей.
6. Выборочно проверьте папки с необычными именами, архивы и вложенные структуры.

Не сравнивайте размер ящиков в гигабайтах у разных провайдеров. Способы учёта хранения слишком различаются. Сверяйте число сообщений.

Привычный подход и альтернатива

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

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

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

Когда TrekMail может подойти для такой миграции

TrekMail может подойти, если нужны IMAP-ящики на основе открытых стандартов, управление несколькими доменами, общий пул хранения, встроенная миграция и управляемый SMTP либо BYO SMTP. Он не позиционируется как полноценный офисный пакет; более узкий набор возможностей может упростить настройку.

Тарифные сведения TrekMail, зафиксированные в исходном снимке по страницам цен; проверяйте действующие условия:

• Free: $0, до 10 доменов, 5 GB общего хранения, BYO SMTP.
• Starter: от $3.50 в месяц, 50 доменов, 15 GB общего хранения, управляемый SMTP, инструмент миграции.
• Pro: $10 в месяц, 100 доменов, 50 GB общего хранения, доступ к API.
• Agency: $23.25 в месяц, 1000+ доменов, 200 GB+ хранения, API и MCP.
• Enterprise: индивидуальные цены.

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

Чтобы рассчитать расходы на параллельную работу до переноса, используйте страницу тарифов TrekMail.

Главное правило переключения

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

Весь порядок действий: сначала инвентаризация, затем предварительный перенос больших ящиков, заблаговременное уменьшение TTL, смена MX в контролируемое окно, заключительная синхронизация и проверка по числу сообщений, а не по впечатлениям.

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