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

Если после смены MX письма приходят на старую почту, сначала проверьте, какие MX-записи видят отправители и куда они ведут. Затем выясните, принимает ли старый сервер новые сообщения и не пересылает ли их обратно. В статье — порядок проверки, который помогает найти сбой без гадания и не потерять письма в переходный период.

Почему письма идут на старую почту после смены MX

MX-запись подсказывает отправляющему почтовому серверу, куда доставлять письма для домена. Смена MX меняет этот указатель в DNS, но не переносит сами ящики, не копирует архив и не выключает старую почтовую систему. Это три отдельные задачи, которые часто по ошибке называют одним словом — «переезд».

Если отправитель всё ещё видит прежний MX, он может направить письмо на старый сервер. Причина может быть в том, что запись ещё не обновилась в используемом им DNS-ответе, либо домен по-прежнему опубликован со старым значением. Но сам факт, что письмо появилось в старом ящике, ещё не доказывает, что виноват DNS: старый сервис может быть настроен на пересылку или доставку в локальный ящик.

В примере с сетью «Дельта-Профиль» сотрудники сменили MX, но коллеги сообщили, что не получают ответы. Я бы не стал сразу объявлять перенос неудачным или просить всех отправителей подождать. Сначала нужно выяснить, где именно оказалось конкретное входящее письмо: на старом сервере, на новом, в очереди либо оно вообще не было принято. Без этой развилки любые изменения — лотерея.

Если нужна не только смена маршрута, но и настройка новых ящиков и домена, в АйТи-Фреш мы ведём корпоративную почту как единый сервис. Но даже при самостоятельном переносе принцип тот же: фиксируем исходные настройки, подтверждаем прием и лишь затем меняем маршрут для всех отправителей.

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

Как проверить MX и DNS после переключения

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

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

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

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

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

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

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

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

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

Если письмо отвергнуто с ошибкой, сохраните полный текст отказа и время отправки. Ошибка вида 554 5.4.0 может быть связана с неправильной конфигурацией маршрута, но код сам по себе не указывает на единственную причину. Проверяйте ответ сервера, журналы почтового узла и актуальные DNS-данные вместе. Формула «увидели 554 — меняем MX» не является диагностикой.

На этом этапе проще всего потерять время, потому что специалисты исправляют DNS, хотя новый сервер ещё не готов принимать домен, или чинят новый сервис, хотя отправитель всё ещё доставляет на старый. Мы в АйТи-Фреш можем разобрать маршрут, сверить DNS и проверить прием на обеих сторонах до отключения старой системы.

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

Как отличить задержку DNS от ошибки на новом сервере

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

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

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

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

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

Контрольный план переноса без потери новых писем

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

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

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

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

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

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

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