Первые 30 дней после Яндекса: когда переезд почты закончен

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

Сразу после смены MX: что оставить работающим

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

DNS не синхронизируется одновременно по всему миру. TTL задаёт время кеширования записи; после изменения у разных резолверов могут оставаться старые ответы. Я записываю прежний TTL и время переключения, проверяю ответы авторитетных серверов зоны и нескольких независимых резолверов. Уменьшение TTL в момент переезда не сокращает срок уже закешированного ответа. Обещания про обязательные 10–15 минут или ровно сутки заменяю наблюдением за реальной доставкой.

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

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

• Зафиксировать время смены MX и прежний TTL.
• Сохранить приём остаточных писем и доступ к исходным данным.
• Проверить маршрут пересылки либо дополнительной синхронизации.
• Назначить ответственного и проверить доступность журналов.

Дни 1–3: как искать письмо, которое не дошло

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

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

В экспертной базе есть полезное различие, закреплённое в RFC 5321: SMTP-ответы 4xx означают временный отказ, 5xx — постоянный отказ для текущей попытки. При временной ошибке почтовый сервер обычно оставляет сообщение для повторной доставки; при постоянной сначала исправляют причину и проверяют уведомление отправителю. Слепой повтор каждого письма может создать дубли. Нажатие кнопки отправки не ремонтирует маршрутизацию — хотя выглядит очень деятельно.

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

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

Первая неделя: какие отправители остались на старом SMTP

Смена MX меняет маршрут входящей почты домена. Она не переписывает SMTP-настройки сайта, учётной системы, сканера и почтовых программ. Поэтому я составляю реестр отправителей: система, назначение писем, сервер отправки, способ входа, адрес отправителя, владелец и контрольная операция. Продолжительность аудита зависит от найденных систем и доступа к ним; универсальные 1–3 часа здесь выдумывать незачем. Программа, отправляющая счета только в конце месяца, легко переждёт поверхностную проверку.

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

Отдельно проверяю SPF у имени домена, для которого получатель выполняет эту проверку. По RFC 7208 должна выбираться одна SPF-запись: две отдельные TXT-записи с началом v=spf1 дают результат permerror. Разрешённые старые и новые источники на переходный период включают в одну согласованную политику. Это не запрет на остальные TXT-записи домена и не требование уместить запись в одну текстовую строку. Список разрешений сверяю с реестром отправителей, а не с догадками о том, что могло остаться.

Для DKIM проверяю конкретную подпись исходящего письма и опубликованный ключ для её селектора. Селектор определяет, какой ключ искать в DNS: наличие какого-нибудь ключа ещё ничего не доказывает. Новый сервис может подписывать другим селектором. При штатной смене ключа старый публичный ключ сохраняют на переходный период, пока ранее подписанные письма ещё могут находиться в пути; сроки определяют по маршруту и очередям. Итог смотрю на стороне получателя. Зелёная галочка в панели отправителя чужую проверку не заменяет.

• Проверить сайт, учётную систему, CRM и устройства отправки.
• Запустить контрольную операцию из каждой системы.
• Сверить единственную SPF-политику с действующими источниками.
• Проверить селектор DKIM и результат проверки у получателя.

Условный разбор: форма записи в «Белом кабинете»

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

Я отправляю через форму контрольную заявку с уникальной пометкой и сопоставляю время с журналом приложения. Затем проверяю, дошло ли дело до SMTP и что ответил сервер. В этом сценарии отказ происходит при авторизации на старом узле: новый сервер сообщения ещё не видел. Делать вывод о пропаже письма из нового ящика рано. Также проверяю, сохранилась ли сама заявка в системе сайта. От этого зависит, можно ли повторно отправить уведомление после исправления.

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

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

• Проследить заявку от формы до целевого ящика.
• Проверить сохранение заявки и ошибку SMTP в приложении.
• Принять исправление по двум контрольным уведомлениям.
• Закрепить владельца интеграции и повторяемый тест.

Вторая неделя: что сверять и восстанавливать из копии

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

Я сопоставляю папки, счётчики и отчёт инструмента переноса, разбираю каждое необъяснённое расхождение. Дополнительно открываю выбранные старые письма, проверяю вложения и даты. Перед повторным копированием уточняю, что оно сделает с дублями и удалениями в целевом ящике. Запускать зеркалирование вслепую после начала работы сотрудников опасно для новых данных. Выборочная проверка дополняет отчёт переноса, но не подменяет разбор ошибок. Цель — получить объяснение каждого расхождения.

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

Резервную копию проверяю восстановлением в отдельный тестовый ящик или изолированную среду, поддерживаемую выбранным решением. Выбираю письмо с вложением, восстанавливаю и открываю его. Копии храню отдельно от основного хранилища и ограничиваю доступ к ним; копия в соседней папке того же диска не решает отказ диска. Замеряю длительность операции и возраст доступной копии, затем согласую с руководителем допустимые потери и время возврата к работе. Универсального экзамена на 15 минут здесь нет. Успешный значок задания пока подтверждает только отчёт задания.

• Сравнивать данные на согласованную временную границу.
• Разобрать расхождения по папкам и отчёту переноса.
• Принять контакты, календари и права отдельно от писем.
• Восстановить письмо с вложением и записать результат.

День 30: когда можно закрыть переезд и старую почту

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

В течение месяца проверяю редкие операции: регламентную отправку документов, уведомления по расписанию, работу общего адреса и доступ заменяющего сотрудника. Если событие не случилось за эти 30 дней, запускаю согласованный контрольный сценарий либо оставляю зависимость открытой. В журнале обращений ищу повторяющиеся ошибки по одной причине. Пустая очередь сегодня не доказывает, что завтра месячная рассылка воспользуется новым сервером. За каждым пунктом должен стоять результат конкретного теста и человек, который его принял.

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

В передаче эксплуатации оставляю описание маршрутов, перечень интеграций, порядок работы с отказами и протокол восстановления. Доступы для переноса отзываю после завершения зависимых работ; настройки и необходимые журналы сохраняю по согласованному сроку. Затем оформляю отключение старого сервиса и повторяю контроль внешней доставки. Мой критерий завершения — документированные проверки и работающий порядок сопровождения. Состав постоянных работ разобран в статье про обслуживание почтового сервера.

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

Частые вопросы