Перенос почтового обслуживания домена почти всегда упирается в одно: письма не должны теряться, а пользователи не должны «заметить» переключение. На практике это означает управляемый mx migration с понятной последовательностью действий: подготовка DNS, работа с dns ttl, корректная расстановка mx priority, период dual delivery и аккуратный mail cutover. В конце обязательно нужен rollback plan, чтобы откатиться за минуты, а не за часы.
Ниже — схема, которая подходит и для переезда на новый почтовый сервис, и для миграции на свой сервер, и для смены провайдера при сохранении домена. Я буду говорить «старый» и «новый» почтовые серверы, но логика одинаковая.
Ключевая идея: куда реально идут письма при смене MX
Когда внешний отправитель доставляет письмо на ваш домен, он:
- получает MX-записи домена;
- сортирует их по приоритету (mx priority: меньшее число — выше приоритет);
- пытается доставить на самый приоритетный MX, при ошибке — на следующий;
- кэширует ответ DNS на время
dns ttl(и/или на своё внутреннее время кэширования).
Поэтому «я поменял MX, но письма ещё идут на старый сервер» — обычно норма: часть отправителей и резолверов живёт по старому кэшу. В миграции важнее другое: чтобы в период «разъезда кэшей» письма всё равно попадали в новый ящик, и вы контролировали процесс.
Подготовка перед mx migration: что собрать и проверить
Перед любыми изменениями в DNS сделайте «снимок состояния». Это экономит часы диагностики, когда внезапно «что-то не приходит».
1) Инвентаризация текущей почты
- Список доменов и алиасов, которые принимают почту (основной домен, дополнительные домены, поддомены).
- Список ящиков, групп, алиасов, правила доставки, catch-all (если используется).
- Как подключаются пользователи: IMAP/POP3/ActiveSync, автоконфигурация (Autodiscover/Autoconfig).
- Интеграции и отправители: сайт, CRM, тикет-система, сканеры/принтеры, мониторинги.
2) Снимок DNS
Снимите текущие записи: MX, A/AAAA для хостов MX, TXT (SPF, DKIM, DMARC), а также Autodiscover/Autoconfig (если используются), CNAME-псевдонимы.
dig +noall +answer MX example.com
dig +noall +answer A mail.example.com
dig +noall +answer AAAA mail.example.com
dig +noall +answer TXT example.com
dig +noall +answer TXT _dmarc.example.com3) Проверка доступности и «готовности» нового MX
До переключения убедитесь, что новый сервер:
- принимает SMTP на 25 порту и отвечает ожидаемым баннером;
- готов принять почту для домена: настроены домены, ящики, алиасы, квоты, ограничения;
- имеет TLS для SMTP (желательно, но сегодня почти обязательно);
- имеет корректный PTR (reverse DNS), если вы планируете исходящую почту с него.
nc -vz mail-new.example.net 25
openssl s_client -starttls smtp -connect mail-new.example.net:25 -servername mail-new.example.netЕсли новый сервер не готов принимать письма, переключение MX превращает миграцию в инцидент. Сначала доводим приём до «зелёного» состояния, и только потом меняем DNS.
Если вы переносите почту на собственную инфраструктуру, удобнее всего делать это на отдельной машине: так проще тестировать, менять настройки MTA и не мешать веб-проектам. Под такую задачу обычно берут VDS с выделенным IP и понятным контролем DNS/Reverse.
dns ttl: как управлять скоростью переключения
dns ttl — время, на которое резолверы кэшируют записи. Чем меньше TTL, тем быстрее «разойдутся» изменения. Но помните: многие крупные отправители и резолверы могут кэшировать дольше по своим политикам. TTL — не гарантия, а рекомендация для кэширующих узлов.
Рекомендуемая схема TTL для mail cutover
- За 24–48 часов до cutover снизьте TTL у MX и связанных A/AAAA до 300–600 секунд.
- Подождите минимум один старый TTL (на практике лучше сутки), чтобы кэш успел обновиться.
- После стабилизации верните TTL к разумному значению: 3600–14400 (по вашей практике изменений).
Снижать TTL «в момент переключения» поздно: кэш уже у всех разный. Правильный подход — подготовить TTL заранее.
mx priority: как выставлять приоритеты без сюрпризов
MX — это список «куда доставлять», а приоритеты — «в каком порядке пробовать». Типичная ошибка: поставить одинаковый приоритет у старого и нового MX и ожидать «плавного» переключения. На деле это приводит к непредсказуемому распределению доставки (зависит от логики отправителя), а значит — к сложной диагностике.
Шаблон приоритетов для контролируемой миграции
- До миграции: старый MX приоритет 10, новый MX в DNS отсутствует (или используется только в тестовом домене).
- На этапе «страховки»: новый MX добавляется как резервный, например приоритет 20.
- На этапе cutover: новый становится основным (10), старый — резервным (20).
- Финал: оставляем только новый MX (10), старый удаляем.
Пример MX-записей
; До добавления резерва
example.com. 300 IN MX 10 mail-old.example.com.
; Новый как резерв (это не dual delivery, а failover)
example.com. 300 IN MX 10 mail-old.example.com.
example.com. 300 IN MX 20 mail-new.example.net.
; Cutover (новый основной, старый резерв)
example.com. 300 IN MX 10 mail-new.example.net.
example.com. 300 IN MX 20 mail-old.example.com.Такой порядок помогает не потерять входящие при временных проблемах нового сервера. Но это ещё не dual delivery в смысле «каждое письмо попадает в новый ящик при любом раскладе» — это лишь резервирование точки приёма.
Dual delivery: два подхода и что выбрать
Dual delivery в миграции обычно понимают как период, когда письма гарантированно попадают в новый ящик, даже если часть отправителей всё ещё несёт их на старый сервер из-за кэшей/политик. Реализуют это двумя основными способами.
Подход A: MX переключили, на старом включили mail forwarding на новый
На практике это самый рабочий вариант: вы делаете mail cutover (новый MX становится основным), а на старом сервере включаете пересылку всех входящих на новый (mail forwarding). Тогда:
- «свежие» отправители доставляют сразу на новый MX;
- «отстающие» доставляют на старый MX, а старый пересылает дальше;
- в итоге новый сервер постепенно становится единственной точкой приёма.
Критичный момент: пересылка должна быть настроена так, чтобы не создавать петель и не ломать доставку из-за аутентификации. Для корректного форвардинга часто нужен SRS (Sender Rewriting Scheme); без него часть писем может получать SPF-fail у конечного получателя. Если у вас активный форвардинг (особенно с доменов со строгим DMARC), заранее проверьте, не нужен ли ARC и как это сочетается с вашим антиспамом. По теме может помочь заметка про ARC при форвардинге в Postfix/Rspamd.
Подход B: «зеркалирование» входящей почты на два места
Более сложный вариант: старый MTA принимает письмо и доставляет копию в старый ящик и на новый сервер (через транспорт, BCC/routing rules или специализированные механизмы конкретной платформы). Плюсы — максимальная полнота попадания на новый сервер. Минусы — сложная настройка, риск дублей, больше точек отказа.
В большинстве миграций хватает подхода A: переключили MX, включили пересылку на старом, подержали несколько дней, выключили старый. Подход B нужен, когда критична полнота архива в новом сервисе с первой минуты.
Пошаговый план mail cutover (без простоя)
Шаг 1. За 48–24 часа: снизить TTL и подготовить откат
- Снизьте
dns ttlу MX и A/AAAA записей хостов MX до 300–600. - Заранее выпишите текущие значения MX, цели, TTL и приоритеты (чтобы откат был «по бумажке»).
- Проверьте доступ к панели DNS и к старому почтовому серверу (пересылка, логи, очередь).
Шаг 2. Подготовить новый сервер к приёму домена
- Настройте домен и все ящики/алиасы, которые должны принимать почту.
- Подготовьте изменения SPF/DKIM/DMARC (особенно если новый сервер будет отправлять почту).
Шаг 3. Cutover: поменять MX приоритеты
В назначенное окно меняем MX так, чтобы новый стал основным, а старый остался резервным. Это снижает риск потерь из-за временных ошибок на новом сервере.
Шаг 4. Включить mail forwarding на старом сервере
Включите пересылку входящих писем со старого домена на новый. Реализация зависит от платформы, но общие требования одинаковые:
- пересылка должна охватывать все ящики и алиасы, включая catch-all (если он нужен);
- должны быть исключены петли (например, когда часть адресов уже маршрутизируется иначе);
- нужен мониторинг очереди и ошибок доставки на старом сервере.
Шаг 5. Период dual delivery: наблюдение и доведение до стабильности
Обычно 3–7 дней достаточно, чтобы большинство отправителей «перекэшировались». В этот период:
- смотрите логи входящей почты на новом и на старом (сколько ещё приходит «по старому»);
- контролируете очередь (mail queue), повторы доставок и типовые коды ошибок;
- делаете тестовые доставки из разных источников;
- фиксируете обращения пользователей: проблемы клиентов, спам, недоставка исходящих.
Шаг 6. Финализация: убрать старый MX, поднять TTL
Когда входящий поток на старом сервере близок к нулю и ошибок нет, удалите старый MX из зоны и верните TTL к обычному значению (например, 3600 или 14400). Mail forwarding можно оставить ещё на 1–2 дня «на всякий случай», но не держите его неделями без необходимости.
SPF/DKIM/DMARC при миграции: где чаще всего ломается почта
Хотя тема статьи — MX, на практике mail cutover чаще ломается из-за аутентификации исходящей почты и строгого DMARC у получателей. Входящая доставка по MX может работать идеально, но письма с нового сервера начнут хуже доставляться или попадать в спам.
SPF
Если новый сервер будет отправлять письма от имени домена, добавьте его IP (или include вашего провайдера) в SPF. Если вы используете форвардинг, помните про SPF: пересылаемые письма иногда получают SPF-fail у конечного получателя, если форвардер не делает SRS. После включения пересылки обязательно мониторьте жалобы «не дошло после пересылки» и отказы в логах.
DKIM
Сгенерируйте DKIM-ключи на новом сервере и добавьте TXT записи селектора. На время миграции нормально держать несколько селекторов (старый и новый) — это штатный сценарий.
DMARC
Если у домена строгая политика (p=reject), любые ошибки SPF/DKIM будут заметнее. На период миграции иногда оправдано временно смягчить политику до p=quarantine или увеличить долю выборки, но делайте это осознанно и на короткий срок. Если хотите глубже разобраться в диагностике, пригодится разбор про DMARC отчёты и доставляемость.
Rollback plan: как откатиться за 10–15 минут
Rollback plan нужен даже если вы уверены в новом сервисе. Простейший откат — вернуть приоритет старому MX. Но учитывайте эффект «раздвоения»: часть писем уже пришла на новый сервер, часть будет приходить на старый, и пользователи могут увидеть неполную картину в зависимости от того, куда подключён их клиент.
Что подготовить для отката заранее
- Сохранённый снимок старых MX/A/AAAA/TXT и их TTL (чтобы не вспоминать «как было»).
- Понимание, как быстро отключить mail forwarding (чтобы не образовать петлю после отката).
- Доступ к логам и очередям на обоих серверах.
- Короткая коммуникация пользователям: что делать с настройками клиентов, если потребуется временно вернуться назад.
Сценарий отката (типовой)
- Вернуть MX: старый приоритет 10, новый 20 (или временно убрать новый).
- Отключить пересылку со старого на новый, если она мешает доставке после отката.
- Проверить входящие тестовые письма с внешних адресов.
- Устранить причину сбоя на новом сервере и повторить cutover по той же схеме.
Откат почти всегда проще, когда в первые дни старый MX оставлен резервным. Если старый MX уже удалён и сервер выключен, восстановление будет дольше и рискованнее.
Проверки после переключения: что смотреть, чтобы не пропустить потери
DNS наблюдение
Проверяйте MX из разных точек и не забывайте про кэш локального резолвера:
dig +short MX example.com
dig @1.1.1.1 +short MX example.com
dig @8.8.8.8 +short MX example.comПочтовые логи и очереди
Если вы администрируете MTA, базовый минимум — смотреть рост очереди и повторяющиеся коды ошибок.
mailq
postqueue -pТестовые доставки
Отправьте письма на домен с разных источников (крупные почтовики, корпоративный SMTP, ваш мониторинговый адрес). Проверяйте не только «пришло», но и куда пришло (на новый ящик), и нет ли дублей из-за форвардинга/зеркалирования.
Частые ошибки при mx migration
- Не снизили
dns ttlзаранее — переключение растягивается, сложно понять «что уже работает». - Сделали одинаковый mx priority — получили случайное распределение доставки.
- Убрали старый MX сразу — при проблеме на новом сервере письма будут ретраиться у отправителей и могут «протухнуть».
- Включили mail forwarding без контроля петель — письма начинают ходить кругами и копиться в очередях.
- Забыли про SPF/DKIM/DMARC — исходящая почта с нового сервера резко ухудшает доставляемость.
Мини-чеклист: миграция MX без простоя
- Собрать текущие MX/TXT, подготовить rollback plan.
- Снизить
dns ttlзаранее (MX и A/AAAA хостов MX). - Проверить новый сервер: приём домена, SMTP, TLS, ящики.
- Сделать mail cutover: новый MX основной, старый резервный.
- Включить mail forwarding со старого на новый на период dual delivery.
- Наблюдать 3–7 дней: логи, очереди, тесты.
- Удалить старый MX, поднять TTL.
Если хочется «приземлить» план под ваш кейс, начните с трёх ответов: где сейчас живёт почта, какая политика DMARC и есть ли активный форвардинг на адреса вне домена. Именно эти нюансы чаще всего решают, будет ли миграция «незаметной» или превратится в серию странных недоставок.
