Перенос почты: скрытые причины сбоев

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

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

Коротко: при переносе почты основные риски редко связаны с данными в ящиках. Опасность кроется вокруг них: в кеше DNS, цепочках SPF, ключах DKIM, токенах OAuth, правилах пересылки и старых алиасах, которые никто не задокументировал. Достаточно упустить одну зависимость, и перенос почты превратится в аварию.

Можно безупречно скопировать 40GB почты и все равно провалить проект, если ответы попадут в спам, письма для сброса пароля будут отклоняться, а Outlook продолжит подключаться к прежнему провайдеру.

Почему проекты по переносу почты срываются еще до переключения

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

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

Сначала найдите три категории.

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

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

Огромные ящики. Всегда находится аккаунт объемом от 35GB до 80GB, с деревом папок, которое ведется с 2009 года, и папкой входящих, используемой как база данных. Такой ящик не будет вести себя как остальные.

Здесь помогает и модель TrekMail. Старый подход означает платить Google или Microsoft за каждого пользователя и удалять историю ради экономии. Новый подход предлагает общий пул хранилища и инфраструктуру с фиксированной оплатой. Так старые ящики можно оставить в качестве архивов, а не превращать их в эксплуатационные мины замедленного действия. Тариф Starter от TrekMail стоит от $3.50/mo, а тариф Nano остается бесплатным и не требует карты.

Расхождение данных DNS приводит к потере писем при переносе

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

Большинство команд меняет MX и считает работу законченной. Но DNS работает иначе. Рекурсивные резолверы кешируют записи на срок, заданный TTL. Если TTL для MX составлял час, двенадцать часов или целые сутки, часть серверов продолжит доставлять почту на прежний адрес, пока кеш не истечет.

Решение скучное, поэтому его часто пропускают. Снизьте TTL до переноса. Дождитесь окончания прежнего TTL. Только после этого переключайте MX.

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

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

example.com.      300 IN MX  10 mail.trekmail.net.
example.com.      300 IN TXT "v=spf1 include:spf.trekmail.net -all"
_dmarc.example.com. 300 IN TXT "v=DMARC1; p=quarantine;"

Практическое правило простое:

1. За сорок восемь часов до переноса почты снизьте TTL для MX до 300 секунд.
2. Подождите достаточно долго, чтобы прежний TTL истек во всех значимых точках.
3. Во время переключения измените MX.
4. Не отключайте старую почтовую службу не менее 72 часов, а затем выполните заключительную синхронизацию.

Если после переключения почта не поступает, контрольный список TrekMail для проблем с получением писем начинается с правильного вопроса: обычно причина в DNS, а не в мистике.

Аутентификация ломается после переноса почты, а не во время него

Сбой аутентификации представляет собой незаметную угрозу при переносе почты. Отправка продолжает работать, но ответы попадают в спам или отклоняются, поскольку новый хостинг, новые IP-адреса и новые ключи DKIM больше не соответствуют прежней цепочке аутентификации.

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

SPF становится первой ловушкой. Спецификация SPF допускает не более десяти механизмов и модификаторов, требующих запросов DNS. Поэтому перегруженные записи перестают работать в реальных схемах отправки. Подробнее см. RFC 7208. Во время переноса администраторы часто сохраняют Google, Microsoft, платформу службы поддержки, CRM, сервис рассылок и нового провайдера в одной записи. Так и возникает permerror.

DKIM становится второй ловушкой. Не заменяйте ключ старого селектора новым в расчете на отсутствие последствий. Задержавшиеся в пути письма могут не пройти проверку подписи, если селектор уже указывает на другой ключ.

DMARC становится третьей ловушкой. Режим мониторинга DMARC существует не просто так. В RFC 7489 значение p=none прямо описано как способ собирать отчеты без изменения обработки писем получателями во время проверки легитимных отправителей.

Для контролируемого переноса оператору следует:

1. Опубликовать разрешение SPF для нового провайдера и удалить старое, как только это станет целесообразно.
2. Создать новый селектор DKIM для новой платформы. Не использовать названия прежних селекторов повторно.
3. Временно ослабить политику DMARC до p=none, если одновременно меняется несколько маршрутов отправки.
4. Вернуть строгую политику после проверки корректной подписи и выравнивания на новом маршруте.

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

Из-за IMAP большой перенос почты не укладывается в выходные

Миграция по IMAP идет медленно, поскольку протокол создавался для синхронизированного доступа к ящику, а не для массовой передачи. Большой перенос останавливается на перечислении папок, ограничениях провайдера, проверке дубликатов и видимых клиентам изменениях состояния задолго до того, как единственной проблемой становится пропускная способность.

Большинство узнает об этом лишь после обещания выполнить за выходные перенос ящика, которому требовалось две недели. IMAP создает много обменов: множество запросов, долгое ожидание и масса возможностей для одной проблемной папки сорвать график.

В худших случаях сочетаются три фактора: огромные папки, ограничения провайдера и повторные дельта-проходы. В документации Google для некоторых сценариев часто упоминается лимит загрузки по IMAP примерно в 2,500 MB в сутки. Поэтому ящик объемом 50GB легко выходит за отведенное на переключение окно, если пытаться перенести его за один проход.

Именно поэтому опытные операторы выполняют предварительную загрузку. За две недели до переноса сначала перемещают старые письма, а во время самого переключения переносят только свежую дельту. Более подробное руководство по IMAP и типичным сбоям доступно в материале TrekMail про imapsync.

Процесс импорта в TrekMail описан в обзоре миграции по IMAP и руководстве по импорту из панели управления. Встроенный инструмент поддерживает внешние источники IMAP и пропуск дубликатов. Это важно при повторном запуске задания в ходе поэтапного переноса почты.

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

Порядок переключения определяет, пройдет ли перенос спокойно

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

На практике надежно работает следующая последовательность.

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

При работе с TrekMail здесь помогает ориентация платформы на стандарты. До переключения можно добавить домен, проверить состояние DNS, создать ящики и запустить импорт. Инструмент миграции доступен на платных тарифах, а постоянно бесплатный Nano подходит для подготовки и тестирования при использовании собственного SMTP.

Клиенты и токены аутентификации требуют незапланированных ресурсов

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

Это зона паники понедельника. Серверная часть в основном исправна. Пользователи еще не готовы.

Владельцы iPhone и Android, входившие через Google или Microsoft, не могут просто изменить одно поле с именем хоста и продолжить работу. Такие токены привязаны к провайдеру. Проще говоря: удалите аккаунт и добавьте его заново.

С настольным Outlook еще сложнее. Он цепляется за устаревшие предположения Autodiscover и кешированные настройки, которые «работали в последний раз». Обычно быстрее создать новый профиль, чем два часа пытаться исправить старый.

Точные параметры клиентов TrekMail публикует в руководстве по настройке IMAP и SMTP: imap.trekmail.net на порту 993 с SSL/TLS и smtp.trekmail.net на порту 465 или 587 в зависимости от шифрования. TrekMail поддерживает только IMAP, но не POP3. При переносе это важно: состояние должно синхронизироваться на всех устройствах, а не загружаться в один клиент и пропадать для остальных.

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

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

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

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

TrekMail учитывает эксплуатационные реалии: собственные домены, ящики IMAP, поддержку catch-all, пересылку ящиков, собственный SMTP на Nano или включенный SMTP на платных тарифах, серверную миграцию и процесс настройки DNS и аутентификации без притворства, будто электронная почта устроена просто. Для агентств и MSP такая ценовая модель меняет расчеты. Независимых основателей она избавляет от платы за каждое место. Малому и среднему бизнесу больше не приходится удалять важные адреса ради экономии нескольких долларов.

Контрольный список переноса: что проверить перед изменением MX

Хороший контрольный список требует проверять зависимости в правильном порядке. Если вы не можете дать четкий ответ по каждому пункту, менять MX еще рано. Сообщения могут успешно мигрировать, но проект останется под угрозой.

1. Перечислите все ящики, алиасы, пересылки, правила catch-all и удаленные адреса, которые по-прежнему важны.
2. Найдите огромные ящики и заранее загрузите их данные.
3. Заблаговременно снизьте TTL для MX и дождитесь истечения прежнего периода кеширования.
4. Опубликуйте SPF, DKIM и DMARC для нового провайдера.
5. Решите, нужно ли временно перевести DMARC в режим мониторинга.
6. Создайте целевые ящики и проверьте вход до переключения.
7. Подготовьте инструкции на понедельник для пользователей iPhone, Android, Outlook и Gmail.
8. Оставьте старую службу включенной для заключительной синхронизации, а не отключайте ее в ту же ночь.

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

Вот желаемый результат: скучный перенос почты. Без паники, пропавших писем для сброса пароля и внезапных проблем со спамом. Только правильная маршрутизация, корректная аутентификация, поэтапная миграция IMAP и платформа, которая не берет оплату за каждого пользователя.