Как перенести почту на новый хостинг с минимальным простоем
Перенос почты в инфраструктуру нового хостинг-провайдера не обязательно означает 24-часовой перерыв, во время которого письма возвращаются отправителям или пропадают. Опасная зона возникает, когда администраторы не учитывают сроки хранения DNS-записей в кэше и пытаются сделать все за один прием. При параллельной работе старый сервис остается доступным, пока новый синхронизируется в фоновом режиме. Переключение выполняют после сверки источника и назначения.
В этом руководстве описан точный план переключения, которым пользуются специалисты при переносе почты на новый хостинг с минимальным перерывом. Подробную теорию миграции можно найти в нашей инструкции по переносу через IMAP.
Почему метод большого взрыва не работает
Подход большого взрыва предполагает, что в пятницу вечером вы копируете все данные, меняете DNS и надеетесь на лучшее. Он не работает, потому что скорость передачи непостоянна. Ограничение частоты запросов, включая ошибки HTTP 429, и лимиты пропускной способности могут остановить миграцию на полпути. К утру понедельника половина почтовых ящиков остается пустой, а служба поддержки захлебывается в обращениях.
Профессиональный способ перенести почту на новый хостинг заключается в параллельной работе двух систем. Вы готовите новую среду, в фоне синхронизируете исторические данные и меняете DNS только после тщательной сверки назначения с источником. До начала работ прочитайте также руководство о том, как сохранить репутацию отправителя при переключении.
4 этапа миграции электронной почты
| Этап | Срок | Действие | Цель |
|---|---|---|---|
| Подготовка | T-7 дней | Синхронизировать по IMAP письма старше 30 дней | Перенести 90% хранилища без чрезмерной нагрузки на канал |
| Снижение TTL | T-48 часов | Уменьшить TTL записей MX и SPF до 300 секунд | Обеспечить окно переключения примерно в 5 минут для DNS-кэшей, соблюдающих TTL |
| Переключение | T-Zero (вечер пятницы) | Направить MX-записи на новый хостинг | Маршрутизировать новые входящие письма на новый сервер |
| Добавочная синхронизация | T+1 час | Синхронизировать недавние элементы за последние 30 дней | Забрать письма, доставленные на старый сервер в переходный период |
Этап 1: распространение DNS и правило 300 секунд
Раздвоенная маршрутизация, при которой часть отправителей попадает на старый сервер, а часть на новый, возникает из-за большого TTL в DNS-записях. Рекурсивные резолверы кэшируют MX-записи на срок, заданный TTL. Стандартное значение часто составляет 86,400 секунд (24 часа). Если переключить MX без предварительного снижения TTL, закэшированные записи могут еще целые сутки направлять почту на старый сервер. Поэтому перед переносом почты на новый хостинг сначала нужно подготовить TTL.
Порядок прост: проверьте текущий TTL, уменьшите TTL для MX и SPF до 300 секунд, а затем выждите как минимум исходное значение TTL. Если пропустить ожидание, в работе останутся старые записи из кэша.
Ловушка с 10 запросами SPF
Во время миграции хочется добавить SPF-include нового провайдера рядом со старым, но здесь нужна осторожность. RFC 7208 ограничивает SPF 10 DNS-запросами. Одновременное использование нескольких провайдеров, например Google, Outlook и нового хостинга, нередко превышает этот предел, вызывает PermError и проблемы с доставкой. Сокращайте цепочку SPF только с помощью решения, которое регулярно обновляет базовые IP-адреса, либо на время переключения уберите некритичные маркетинговые сервисы. Дополнительные рекомендации приведены в нашем руководстве по настройке SPF.
Этап 2: синхронизация данных по IMAP
При переносе почты на новый хостинг миграция выполняется по протоколу IMAP (RFC 3501). Это не простое копирование файлов, а синхронизация состояния. Основную работу выполняют такие инструменты, как imapsync, но администратору важно понимать особенности протокола.
Проблема призрачного ящика Gmail
Если переносить из Gmail папку All Mail, интерпретируя ярлыки как папки, сообщения могут появиться в назначении несколько раз. Gmail показывает ярлыки как папки через IMAP, поэтому одно письмо с 3 ярлыками может быть видно в 3 отдельных IMAP-папках, а неподходящий инструмент воспримет эти 3 представления как разные элементы. Эта модель описана в собственной документации Google по миграции данных. Настройте корректное сопоставление ярлыков в инструменте миграции или целенаправленно исключите папку [Gmail]/All Mail.
Ограничение скорости и коды ошибок
При переносе почты на новый хостинг будьте готовы к ограничениям исходного сервера. Google может возвращать ошибки соединения 11001/11002, когда доступ по IMAP отключен или заблокирован межсетевым экраном. HTTP 429 означает ограничение частоты запросов. Многие провайдеры ограничивают соединения при объеме свыше 2 GB/hour/user. Используйте инструмент миграции с экспоненциальной задержкой, который распознает такие ограничения и автоматически приостанавливает работу.
Этап 3: влияние на почтовые клиенты
После переноса почты на новый хостинг серверная часть обычно оказывается проще. В нашем руководстве по переносу почтового ящика подробно описано переключение DNS. Основной поток обращений в поддержку чаще вызывает настройка клиентских устройств.
Несоответствие сертификата: если Outlook остается открытым во время изменения DNS, он подключается к mail.yourdomain.com, который уже указывает на новый хостинг, но может использовать прежние учетные данные. Вслед за этим появляются предупреждения о сертификате SSL/TLS. Попросите пользователей перезапустить почтовый клиент утром в понедельник и проверить соединение.
OAuth на мобильных устройствах: современные мобильные клиенты используют токены OAuth, привязанные к конкретному арендатору. В зависимости от клиента и провайдера учетную запись можно повторно авторизовать или перенастроить. В остальных случаях пользователю потребуется удалить старую учетную запись и добавить новое подключение IMAP.
Петли внутренней маршрутизации: после изменения MX старый сервер может по-прежнему считать домен локальным. Если пользователь A на старой системе пишет пользователю B, который также числится на ней, сервер доставит письмо локально. Пользователь B, уже читающий новый ящик, его не увидит. Настройте на старом хостинге безопасную пересылку поздних писем на новый, пока не истекут старые DNS-кэши. Отключайте локальную доставку только после проверки такой схемы.
Откат: страховка на первые 15 минут
Поскольку вы снизили TTL до 300 секунд, многие резолверы смогут быстро принять обратное изменение. Эта подготовка выполнялась на этапе 1. Если перенос на новый хостинг не удался, например из-за межсетевого экрана, лицензирования или отсутствия почтового потока в течение 30+ минут, верните MX-записи старого провайдера. Для кэшей, которые соблюдают TTL, новый трафик может снова пойти туда примерно через 5 минут. Другим кэшам понадобится больше времени, поэтому обе системы должны оставаться доступными и находиться под наблюдением.
Как TrekMail упрощает перенос
При ручном переносе почты на новый хостинг приходится обслуживать сценарии imapsync, разбирать малопонятные ошибки вроде 0x800CCC0E и следить за распространением DNS. В TrekMail встроен механизм миграции по IMAP, который для поддерживаемых данных автоматизирует сопоставление папок, задержку при ограничении скорости и добавочную синхронизацию. После него все равно нужна итоговая сверка с источником.
| Тариф | Цена | Для кого |
|---|---|---|
| Free | $0 | Тестирование и личные домены (карта не требуется) |
| Starter | $3.50/mo | Малый бизнес с одним доменом |
| Pro | $10/mo | Несколько доменов и опытные пользователи |
| Agency | $23.25/mo | MSP, переносящие 50+ клиентских доменов с общим хранилищем |
Все платные тарифы включают 14-дневный пробный период (требуется карта). Для тарифа Nano карта вообще не нужна.
TrekMail специализируется на производительном хранении и доставке почты, а также предоставляет календари и контакты для каждого ящика через CalDAV и CardDAV. Если вам также нужно создать почту на собственном домене, наша инструкция проведет вас через все этапы. Сама миграция переносит только почту. Экспортируйте календари и контакты у старого провайдера, а затем импортируйте их после запуска ящиков.
Агентствам, которые регулярно переносят на новый хостинг десятки доменов одновременно, TrekMail предлагает общее хранилище с распределением 200 GB между всеми доменами, управляемый SMTP с заранее сформированной репутацией IP и шаблоны подготовки, позволяющие применить настройки DNS и миграции к 100 доменам.
Вывод: перенос почты без черной дыры
Для успешного переноса почты на новый хостинг нужно одновременно управлять переходом состояния DNS, данных и клиентского доступа. Каждый администратор должен заранее учитывать эту сложность. Цель состоит в том, чтобы свести к минимуму возвраты писем, потерю данных и срочные обращения. Подготовьте TTL 300 секунд, используйте параллельную схему, выполните итоговую сверку данных и держите план отката наготове.
Дополнительные советы по выбору подходящей почтовой платформы и защите репутации домена во время перехода приведены в следующих руководствах.
Не платите за каждого пользователя ради функций, которыми вы не пользуетесь. Попробуйте TrekMail бесплатно и оцените почтовый хостинг, созданный для администраторов.
