Как изменить A-запись сайта и не сломать почту через MX

Почему изменение A-записи сайта иногда ломает почту

Изменение A-записи сайта не меняет MX напрямую, но может изменить адрес сервера, к которому в итоге приводит MX. Именно поэтому в DNS-панели почтовая запись иногда выглядит прежней, а входящие письма уже пытаются попасть совсем на другой сервер.

Допустим, DNS-зона выглядит так:

example.com.       A     192.0.2.10
example.com.       MX    10 mail.example.com.
mail.example.com.  A     192.0.2.20

Здесь веб и почта разделены. Сайт использует 192.0.2.10, почтовый сервер — 192.0.2.20. Если заменить только A-запись example.com на новый IP веб-сервера, маршрут входящей почты останется прежним.

Другая схема:

example.com.       A     192.0.2.10
example.com.       MX    10 mail.example.com.
mail.example.com.  A     192.0.2.10

Сайт и почта находятся на одном IP. Само по себе это не мешает переносу. example.com можно направить на новый VPS, а mail.example.com оставить на 192.0.2.10, если старый сервер продолжает обслуживать почтовые ящики.

Перенос ломается, когда старый IP находят в нескольких A-записях и меняют его одной пачкой. Сайт действительно начинает работать на новом VPS. Но mail.example.com тоже уходит туда, а SMTP, IMAP и почтовые ящики на новом сервере никто не переносил.

Есть ещё более чувствительная схема:

example.com.  A     192.0.2.10
example.com.  MX    10 example.com.

MX использует основной домен как имя почтового сервера. После смены A-записи example.com меняется не только адрес сайта, но и конечный IP для входящей почты. MX не изменился. Маршрут изменился.

Перед переносом достаточно начать с трёх запросов:

dig example.com A +short
dig example.com MX +short
dig mail.example.com A +short

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

Какие DNS-записи нужно проверить до изменения IP сайта

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

Какие записи относятся к сайту

У обычного сайта чаще всего задействованы основной домен и www:

• A для example.com;
• AAAA для example.com, если используется IPv6;
• A для www.example.com либо CNAME на основной домен;
• отдельные поддомены приложения, если они тоже переезжают.

Если задача состоит только в переносе сайта, обычно меняются именно эти записи. При CNAME нужно смотреть не только на имя, которое вводит пользователь, но и на конечный hostname. Например, если www.example.com — CNAME на example.com, отдельный IP для www менять не требуется.

Какие записи определяют доставку входящей почты

Для входящих писем в первую очередь нужны MX и A/AAAA hostname, указанного в MX:

example.com.       MX  10 mail.example.com.
mail.example.com.  A   192.0.2.20

Здесь критична не A-запись сайта, а адрес mail.example.com. Если MX указывает на внешний сервис вроде mx.provider.net, собственный mail.example.com может вообще не участвовать в серверной доставке.

Отдельный нюанс — MX target не стоит строить через случайную цепочку CNAME. Имя, указанное в MX, должно быть корректным почтовым hostname с рабочими A/AAAA. Если в старой зоне обнаружилась необычная схема с alias, её лучше сначала разобрать, а не переносить вслепую.

Какие записи используют Outlook, Thunderbird и телефоны

MX отвечает за доставку писем между почтовыми серверами. Outlook, Thunderbird, мобильный клиент или CRM могут вообще не обращаться к MX при подключении пользователя. Они используют настройки аккаунта:

• mail.example.com;
• imap.example.com;
• smtp.example.com;
• autodiscover.example.com;
• autoconfig.example.com.

Поэтому возможна на первый взгляд странная ситуация: входящие письма доставляются нормально, MX правильный, но Outlook у сотрудников перестал подключаться после переноса сайта. Причина находится не в MX, а в A, AAAA или CNAME имени, прописанного в почтовом клиенте.

Какие записи отвечают за SPF, DKIM и DMARC

TXT-записи SPF, DKIM и DMARC обычно не нужно менять при переносе только сайта, но их необходимо сохранить. Это особенно критично, если одновременно меняются NS и DNS-зона создаётся у нового провайдера заново.

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

Нужно ли заранее уменьшать TTL

Если переключение планируется заранее, полезно проверить текущий TTL A и AAAA без параметра +short:

dig example.com A
dig example.com AAAA
dig mail.example.com A

TTL показывает, как долго recursive DNS-резолвер может хранить полученную запись в кеше. Уменьшение TTL заранее сокращает период, в течение которого после переключения могут одновременно встречаться старые и новые ответы.

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

Что проверить, если DNS работает через Cloudflare

Если зона обслуживается Cloudflare, отдельно посмотрите режим проксирования у почтовых hostname. Имя, которое используется для обычных SMTP, IMAP или POP3-подключений, обычно должно разрешаться непосредственно в почтовый сервер, то есть работать в режиме DNS only, если вы специально не используете отдельное решение для проксирования этих протоколов.

Сценарий простой: MX остаётся mail.example.com, но mail.example.com случайно переводят под HTTP-прокси вместе с веб-записями. В DNS появляется не тот адрес, к которому должен подключаться SMTP. Поэтому mail hostname проверяется отдельно от example.com и www.

Как проверить, куда на самом деле ведёт MX домена

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

Как прочитать результат dig MX

Выполните:

dig example.com MX +short

Ответ может выглядеть так:

10 mail.example.com.

Число 10 — приоритет MX. Чем меньше значение, тем выше приоритет сервера. mail.example.com — hostname, который используют внешние SMTP-серверы при доставке почты на домен.

Следующий запрос:

dig mail.example.com A +short

Например:

192.0.2.20

Этот IP уже нужно сравнить со старым и новым адресом сайта. Если сайт переезжает с 192.0.2.10 на 198.51.100.30, а mail.example.com остаётся на 192.0.2.20, веб и входящая почта разделены.

Если у домена несколько MX, нужно проверить каждый hostname:

dig example.com MX +short

Например:

10 mx1.example.net.
20 mx2.example.net.

Для внешнего почтового сервиса собственная запись mail.example.com может вообще не участвовать во входящей доставке. Тогда смена A сайта сама по себе не затрагивает MX, но при переносе DNS-зоны всё равно нельзя потерять записи внешнего провайдера.

Почему MX на основной домен требует отдельной проверки

Если запрос возвращает:

10 example.com.

а example.com имеет A-запись старого веб-сервера, смена A одновременно меняет конечный IP для MX.

До переноса:
example.com A 192.0.2.10
example.com MX 10 example.com.

После переноса:
example.com A 198.51.100.30
example.com MX 10 example.com.

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

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

Как безопасно изменить A-запись, если сайт и почта находятся на разных серверах

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

Допустим, сейчас используется такая схема:

example.com        192.0.2.10
www.example.com    192.0.2.10
mail.example.com   192.0.2.20
MX                 mail.example.com

Новый веб-сервер   198.51.100.30

До изменения выполните:

dig example.com A +short
dig www.example.com A +short
dig example.com MX +short
dig mail.example.com A +short
dig mail.example.com AAAA +short

Если результаты соответствуют схеме, меняется A основного домена:

example.com A 198.51.100.30

Для www действие зависит от существующей записи. Отдельную A тоже нужно обновить. Если www — CNAME на example.com, новый адрес подтянется через основной домен.

MX, mail.example.com, SPF, DKIM и DMARC при таком переносе не меняются только потому, что сменился веб-сервер. Сайт переезжает. Почтовая инфраструктура остаётся там, где была.

После переключения ожидаемая DNS-схема выглядит так:

example.com        198.51.100.30
www.example.com    198.51.100.30
MX                 mail.example.com
mail.example.com   192.0.2.20

Но на DNS-проверке останавливаться рано. Если сотрудники работают через mail.example.com, откройте почтовый клиент и проверьте IMAP/SMTP. Если сайт отправляет заявки или уведомления, отправьте тестовое письмо уже с нового веб-сервера. Это отдельный маршрут, и MX его не проверяет.

Что делать, если сайт и почта сейчас используют один IP

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

До переноса:

example.com       A   192.0.2.10
mail.example.com  A   192.0.2.10
example.com       MX  10 mail.example.com.

Сайт переезжает на новый VPS, а ящики остаются на старом хостинге. Тогда после переключения схема может быть такой:

example.com       A   198.51.100.30
mail.example.com  A   192.0.2.10
example.com       MX  10 mail.example.com.

Старый IP больше не обслуживает сайт, но продолжает принимать SMTP и обслуживать почтовые клиенты. Нормальная схема. Главное — не заменить A для mail.example.com вместе с A сайта.

Старый хостинг нельзя отключать сразу после того, как сайт открылся с нового VPS. Если почтовые ящики, IMAP или SMTP остались на старом сервере, удаление аккаунта остановит эти службы независимо от того, насколько аккуратно настроен MX.

Почему AAAA и IPv6 могут испортить перенос даже при правильной A-записи

Если у домена есть AAAA, проверка только IPv4 недостаточна. A может уже вести на новый сервер, а AAAA — на старый IPv6. Тогда два пользователя могут получать разный результат при обращении к одному домену.

Например:

A     198.51.100.30
AAAA  2001:db8:1::10

IPv4 уже новый, IPv6 остался старым. Клиент с рабочим IPv6 может продолжить обращаться к старому серверу, а клиент только с IPv4 сразу увидит новый. Из-за этого перенос выглядит «плавающим»: на одном компьютере всё уже работает, на другом — старая версия сайта или ошибка.

Та же проблема встречается у mail.example.com:

mail.example.com A     192.0.2.20
mail.example.com AAAA  2001:db8:2::20

A может вести на правильный почтовый сервер, а AAAA — на старую машину, где SMTP уже остановлен. Часть отправляющих серверов попытается использовать IPv6 и получит ошибку, хотя обычная проверка A выглядит безупречно.

Проверяйте обе семьи адресов:

dig example.com A +short
dig example.com AAAA +short
dig mail.example.com A +short
dig mail.example.com AAAA +short

Если система с nc поддерживает принудительный IPv6, отдельно можно проверить доступность SMTP:

nc -6 -vz mail.example.com 25

Неудачное IPv6-соединение само по себе ещё не доказывает ошибку MX. Оно показывает, что hostname публикует IPv6, но почтовая служба по этому маршруту недоступна. Тогда нужно решить, должен ли этот AAAA вообще существовать.

Если новый веб-сервер не обслуживает IPv6, старую AAAA сайта либо заменяют на корректный IPv6 нового сервера, либо удаляют. Для mail.example.com решение принимается отдельно: если почтовый сервер действительно работает по IPv6, его AAAA должна остаться.

Нужно ли менять SPF, DKIM и DMARC вместе с A-записью сайта

Обычная смена IP веб-сайта не требует автоматически менять DKIM или DMARC. SPF тоже часто остаётся прежним. Но здесь есть исключение: новый веб-сервер может сам отправлять письма от имени домена.

Получить TXT-записи можно командой:

dig example.com TXT +short

Если SPF выглядит так:

v=spf1 ip4:192.0.2.20 ~all

в нём явно разрешён 192.0.2.20. Если это действующий почтовый сервер и он никуда не переезжает, менять SPF только из-за нового IP сайта не нужно.

Почему механизм a в SPF зависит от A-записи

Рассмотрим другую политику:

v=spf1 a mx ~all

Механизм a разрешает адреса, которые DNS возвращает для указанного имени. После смены A example.com с 192.0.2.10 на 198.51.100.30 фактический набор адресов, разрешённых этим механизмом, тоже меняется.

Механизм mx работает через MX-хосты домена. Поэтому SPF с a и mx нельзя оценивать только визуально по TXT-строке. Нужно понимать, во что эти механизмы разрешаются после изменения DNS.

Почему после переноса WordPress может перестать нормально отправлять письма

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

До переноса WordPress мог отправлять через локальный Postfix или sendmail со старого IP:

WordPress
local MTA
192.0.2.10

После переноса тот же сайт отправляет уже с нового VPS:

WordPress
local MTA
198.51.100.30

Если новый IP не разрешён SPF для envelope-from домена, исходящее сообщение может получить SPF fail. Если на новом сервере нет прежней DKIM-подписи, изменится и результат DKIM. Входящая почта при этом продолжит работать совершенно нормально.

Перед редактированием SPF сначала выясните, как именно сайт отправляет сообщения:

• через PHP mail() и локальный MTA;
• через локальный Postfix/Exim;
• через SMTP-плагин WordPress;
• через внешний SMTP relay или почтового провайдера.

Если WordPress использует внешний SMTP и авторизуется на нём, новый IP веб-сервера может вообще не участвовать в SPF как отправляющий MTA. Если же VPS доставляет письма непосредственно получателям, его адрес и почтовая конфигурация уже имеют значение.

Если SMTP-плагин WordPress отправляет через ukr.net, отдельно проверьте типичные проблемы с отправкой через SMTP-сервер ukr.net: они могут проявляться независимо от MX домена.

После тестовой отправки полезно посмотреть заголовки полученного письма и найти Authentication-Results. Там обычно видно результаты SPF, DKIM и DMARC. Не нужно менять все три механизма заранее: сначала определить реальный путь письма, потом исправлять конкретную проверку.

Что происходит с DKIM и DMARC

DKIM обычно публикуется по имени вроде:

selector._domainkey.example.com

DMARC:

_dmarc.example.com

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

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

Как проверить сайт и почту сразу после изменения DNS

После смены A-записи нужно проверить не два, а несколько независимых маршрутов. Открытие сайта подтверждает HTTP/HTTPS. Успешный MX-запрос подтверждает только DNS-маршрут входящей почты. Это разные проверки.

Минимальная DNS-проверка

dig example.com A +short
dig example.com AAAA +short
dig example.com MX +short
dig mail.example.com A +short
dig mail.example.com AAAA +short

Если AAAA не используется, пустой ответ нормален. Если MX возвращает внешний hostname, A/AAAA нужно проверять уже для этого hostname, а не автоматически для mail.example.com.

После переключения должны выполняться четыре условия:

• A сайта содержит новый IPv4;
• AAAA сайта содержит правильный IPv6 либо отсутствует, если IPv6 не используется;
• MX соответствует запланированной почтовой схеме;
• hostname из MX разрешается в действующий почтовый сервер.

Как отличить DNS-кеш от ошибки в самой зоне

Если один компьютер показывает старый IP, а другой новый, сравните recursive resolver с authoritative DNS.

Сначала получите NS:

dig example.com NS +short

Затем запросите один из authoritative серверов напрямую:

dig @ns1.example.net example.com A

И для сравнения один публичный resolver:

dig @1.1.1.1 example.com A

Если authoritative NS уже возвращает новый IP, а recursive resolver ещё старый, причина похожа на кеш и TTL. Если сам authoritative NS отдаёт старое или неправильное значение, ждать «распространения DNS» бессмысленно — сначала нужно исправить зону.

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

Первый тест: отправьте сообщение с внешнего сервиса на user@example.com. Второй: ответьте с доменного ящика на внешний адрес.

Эти проверки отвечают на разные вопросы. Первое письмо тестирует входящую доставку через MX. Второе показывает, может ли почтовая инфраструктура домена отправлять наружу.

При необходимости доступность SMTP можно проверить отдельно:

nc -vz mail.example.com 25

Для SMTPS:

openssl s_client -connect mail.example.com:465

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

Проверьте почтовый клиент, даже если MX работает

Если пользователи подключаются к mail.example.com, imap.example.com или smtp.example.com, откройте один реальный аккаунт в Outlook, Thunderbird или другом используемом клиенте. Проверьте получение и отправку.

Так обнаруживается ситуация, в которой MX полностью исправен, но A/AAAA клиентского hostname случайно переехала вместе с сайтом. Внешние серверы доставляют почту, а сотрудники не могут к ней подключиться.

Проверьте письмо, которое отправляет сам сайт

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

Если письмо пользователя отправляется нормально, а WordPress не доставляет уведомления, нужно смотреть способ отправки сайта, SMTP-настройки, локальный MTA и результаты SPF/DKIM. MX в такой ситуации может быть полностью исправен.

Если сайт отправляет через ukr.net, перед изменением DNS стоит сверить параметры с разбором SMTP ukr.net, чтобы не принять проблему авторизации или отправки за ошибку MX.

Что проверить, если после смены A-записи письма перестали приходить

Если проблема появилась сразу после DNS-переключения, не меняйте одновременно MX, SPF, порты и настройки клиентов. Идите по уровням: MX, hostname, IP, сеть, SMTP. Так быстрее видно место, где почтовая цепочка перестала работать.

Начните с:

dig example.com MX +short

Предположим, ответ:

10 mail.example.com.

Дальше:

dig mail.example.com A +short
dig mail.example.com AAAA +short

MX правильный, но mail.example.com получил новый IP

Так бывает после массовой замены старого IP во всех A-записях. В панели MX выглядит прежним, но mail.example.com уже ведёт на новый веб-сервер.

Если почта должна остаться на старом хостинге, восстановите A и при необходимости AAAA для mail.example.com. Затем снова проверьте:

dig mail.example.com A +short
dig mail.example.com AAAA +short

Ответ должен соответствовать серверу, где реально работают почтовые ящики и SMTP.

MX правильный, входящие идут, но Outlook не подключается

Здесь MX уже не главный подозреваемый. Посмотрите имя сервера в настройках почтового клиента. Если там указан mail.example.com, imap.example.com или smtp.example.com, проверьте эти DNS-записи отдельно.

Также имеет смысл проверить порты, которые использует конкретная конфигурация клиента. Например, наличие соединения с сервером можно проверить через OpenSSL, если сервис использует TLS:

openssl s_client -connect mail.example.com:465

Ошибка подключения после смены DNS при рабочем MX часто означает, что серверное имя клиента разрешается не туда или нужная служба на полученном IP не слушает порт.

Письма не приходят, а сервер отвечает connection refused или timeout

Если DNS уже приводит на ожидаемый IP, но соединение с SMTP не устанавливается, проблема находится ниже DNS-уровня.

nc -vz mail.example.com 25

Результат вроде connection refused означает, что соединение дошло до узла, но нужный порт не принимает подключение. connection timed out может указывать на фильтрацию, firewall, сетевой маршрут или недоступность сервера. Такой результат не доказывает ошибку MX, если MX и A/AAAA уже проверены.

Если исходящая отправка настроена через ukr.net, отдельно исключите типичные ошибки SMTP ukr.net. Это отдельный уровень диагностики и он не меняет маршрут входящей почты по MX.

DNS выглядит правильно, но почта всё равно не работает

Тогда отделите проблему authoritative DNS от SMTP. Сначала получите NS:

dig example.com NS +short

Потом запросите конкретный authoritative сервер:

dig @ns1.example.net example.com MX
dig @ns1.example.net mail.example.com A
dig @ns1.example.net mail.example.com AAAA

Подставьте реальный NS домена вместо ns1.example.net.

Для проверки цепочки делегирования можно использовать:

dig +trace example.com MX

Если authoritative DNS уже возвращает ожидаемые MX и A/AAAA, DNS дальше мучить нет смысла: переходите к SMTP, настройке домена на почтовом сервере, firewall и состоянию MTA.

Если одновременно менялись NS, сравните новую зону со старой. Часто сайт уже работает, потому что A перенесли, а часть mail-, TXT- или autodiscover-записей в новую зону просто не попала.

Безопасная схема переноса сайта без остановки почты

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

До изменения DNS

1. Сохраните текущую DNS-зону.
2. Запишите старые A и AAAA сайта.
3. Уточните новый IPv4 и, если используется, IPv6 веб-сервера.
4. Проверьте MX домена.
5. Проверьте A и AAAA каждого hostname из MX.
6. Запишите hostname, которые используют Outlook, Thunderbird, телефоны и другие почтовые клиенты.
7. Проверьте, как WordPress или другая CMS отправляет сообщения.
8. Если перенос планируется заранее, проверьте TTL и при необходимости уменьшите его до переключения.
9. Сохраните SPF, DKIM, DMARC, autodiscover и остальные почтовые записи.

Во время переключения

1. Измените A основного домена на новый IPv4.
2. Обновите www, если это отдельная A-запись.
3. Обновите AAAA только при наличии рабочего IPv6 на новом сервере.
4. Не меняйте MX и hostname почтовых сервисов, если почта не переезжает.
5. Если используется Cloudflare, не переводите почтовый hostname под веб-прокси вместе с сайтом.

После изменения

1. Проверьте A/AAAA сайта и hostname из MX.
2. Откройте сайт по HTTPS.
3. Получите письмо с внешнего адреса.
4. Отправьте сообщение с доменного ящика наружу.
5. Проверьте используемый почтовый клиент.
6. Отправьте тестовое письмо из WordPress, CMS или формы сайта.
7. При разных DNS-ответах сравните recursive resolver с authoritative NS.

Когда лучше откатить A-запись

Откат нужен не при любом подозрительном симптоме, а когда подтверждено, что новая веб-инфраструктура не готова и именно переключённая A/AAAA мешает работе сервиса.

Например, есть смысл вернуть старое значение, если authoritative DNS уже показывает новый IP, но новый веб-сервер не принимает сайт, SSL-конфигурация не готова или вместе с веб-записью на новый сервер случайно уехал hostname, от которого зависит почта.

Если проблема только в кеше recursive DNS, откат A не поможет — он создаст ещё одну смену значения и усложнит картину. Если MX и mail.example.com правильные, а SMTP не отвечает на старом почтовом сервере, возврат веб-A тоже не исправит SMTP.

Поэтому перед откатом зафиксируйте три факта:

• какое значение сейчас отдаёт authoritative DNS;
• какой IP должен обслуживать проблемный сервис;
• какая именно изменённая запись отправляет трафик не туда.

Если виновата A или AAAA сайта, верните сохранённое значение и продолжайте разбирать новый сервер без аварийного переключения пользователей. Если виновата A/AAAA для mail.example.com, восстанавливайте именно почтовую запись, а не весь DNS целиком.

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

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