#Симптомы и область применимости
После переноса почты на нового провайдера часть входящих писем по-прежнему приходит на старый сервер. Обычно разные отправители видят неодинаковые закешированные MX, но возможны также старые NS, дополнительная MX-запись и локальные правила маршрутизации.
#Причины и диагностические признаки
| Возможная причина | Как узнать | Что делать |
|---|---|---|
| Изменена не авторитетная зонаДомен делегирован на другие NS, чем редактируемый провайдер. | В панели DNS новый MX, а публичный ответ остаётся прежним | Найдите действующие авторитетные серверы имён. |
| В DNS осталась старая записьОтправители могут выбирать сервер согласно приоритету или доступности. | В ответе есть и старый, и новый MX | Уберите устаревший MX только после готовности нового сервиса. |
| Сохранился кеш записиДо окончания TTL возможны разные ответы; новые записи тоже кешируются. | Одни резолверы показывают старый MX, другие новый | Сопоставьте TTL и время изменения. |
#Пошаговая диагностика и исправление
- 1. Зафиксируйте маршрут одного тестового письмаОтправьте письмо с внешнего независимого адреса и посмотрите на каком сервере оно фактически принято. Сохраните время, заголовки Received и журнальную строку, не публикуя содержимое. Не отключайте прежний почтовый сервер, пока нет устойчивой доставки на новый.
- 2. Проверьте делегирование NSС компьютера с dig запросите NS домена и сравните с тем DNS-провайдером, где меняли MX. Если делегирование не совпадает, правка в неавторитетной зоне не влияет на публичную доставку.
- Терминал с dig, замените доменLinux · Терминал (Bash)КомандаТерминал с dig, замените домен. Только чтение; результат может быть кешированным, для доказательства используйте авторитетный сервер.
dig NS example.com +short
- 3. Посмотрите текущие MX на разных резолверахЗапросите MX через обычный системный резолвер и отдельно у авторитетного NS из предыдущего шага. Сравните hostname, приоритет и TTL. Не меняйте A-запись сайта только потому, что изменился MX.
- ЧтениеLinux · Терминал (Bash)КомандаЧтение. Для авторитетной проверки используйте: dig @имя_NS example.com MX +norecurse.
dig MX example.com +noall +answer
- 4. Сверьте имена MX с адресами конечных серверовЗапросите A и AAAA всех названных хостов. Новый MX должен разрешаться на нужную службу, а сам хост поддерживать приём на TCP 25. Для MX обычно нельзя использовать CNAME вместо надлежащего имени с адресными записями.
- 5. Проверьте настройки почтового домена на обеих сторонахВ админке нового поставщика проверьте, что домен подтверждён, ящики и переадресации созданы, нет ошибочной локальной доставки. На старом сервере выясните, продолжает ли он принимать почту как локальную; не удаляйте старые ящики до переноса накопленной почты.
- 6. Исправьте авторитетные MX и сохраните план откатаВ правильной DNS-панели создайте только утверждённый набор MX с предписанными приоритетами, уберите прежние после проверки готовности новой системы. Сохраните снимок старой зоны и список почтовых ящиков; не используйте случайные приоритеты в надежде ускорить кеш.
- 7. Учитывайте TTL и ранее известные ответыСразу после изменения разные отправители ещё могут направлять почту по старым MX. Поддерживайте старый сервер доступным как минимум на время плановой миграции, включите пересылку/досбор почты по согласованной схеме. Не объявляйте время распространения DNS универсально фиксированным.
- 8. Сравните доставку и завершите переключениеПовторите тест из разных почтовых систем, проверяя Received и журналы на новом сервере. Когда старый сервер перестанет принимать новые письма и все накопленные сообщения перенесены, согласуйте его отключение, сохранив архив и инструкции восстановления.
#Как убедиться, что проблема устранена
Авторитетные NS возвращают только утверждённый набор MX, новые внешние тесты приходят на новый сервер, а на старом не возникает новых входящих сообщений после завершения периода кеширования.
#Если проблема осталась
Если один провайдер продолжает отправлять на старый сервер, сохраните его заголовки и запросите у него проверку кеша MX. Если авторитетный ответ неверен, исправьте делегирование или зону, а не настройки IMAP-клиента.