Перенос почтового ящика: безопасное переключение DNS

Как перенести почтовый ящик к новому поставщику: переключение DNS

При переносе ящика разница между спокойным переходом и простоем на 48 часов во многом определяется стратегией DNS. Ошибка в TTL или забытый SPF-include могут вызвать окончательные отказы доставки и ущерб для бизнеса.

Здесь нужна не импровизация, а точная последовательность технических действий. Разберём безопасный перенос содержимого ящика с учётом сроков распространения DNS, объединением идентификаторов SPF, DKIM и DMARC и маршрутизацией к новому поставщику с минимальным риском потери писем.

Сам перенос сообщений подробно описан в руководстве по синхронизации IMAP.

Почему DNS при переносе ящика обновляется не сразу

DNS представляет собой распределённую систему кэширования. После изменения записи приходится ждать, пока рекурсивные резолверы, включая DNS-серверы провайдеров, Google 8.8.8.8 и локальные маршрутизаторы, обновят кэш согласно Time-To-Live (TTL).

При стандартном TTL в 86,400 секунд (24 часа) часть серверов может ещё сутки направлять почту по старому маршруту. Одни письма попадут в новый ящик, другие в старый.

Запаздывающие серверы и отрицательное кэширование

При переносе ящиков регулярно мешают два незаметных фактора:

• Запаздывающие серверы: даже при низком TTL примерно 1-5% резолверов в мире игнорирует значения меньше 60 минут. После переключения рассчитывайте ещё около часа получать остаточный трафик у прежнего поставщика.
• Отрицательное кэширование (SOA): если запросить запись до её появления, например слишком рано проверить новый селектор DKIM, ответ NXDOMAIN кэшируется на минимальный TTL записи SOA, часто на 1 час. Поэтому опубликованная позже корректная запись некоторое время может быть не видна.

Этап 1: отсчёт 48 часов

Пока не меняйте записи MX. Сначала подготовьте среду к переключению.

Шаг 1: уменьшите TTL (за 48 часов)

Найдите записи MX, SPF (TXT) и DMARC. Уменьшите их TTL до 300 секунд (5 минут).

Это сокращает окно распространения. Многие резолверы увидят финальное изменение быстрее, чем при TTL в 24 часа, но обновление всех кэшей за 5 минут не гарантируется.

Шаг 2: объедините SPF (за 24 часа)

SPF (RFC 7208) разрешает IP-адресам отправлять почту от вашего имени. На переходном этапе должны быть одновременно разрешены оба поставщика.

Ловушка: SPF допускает не более 10 DNS-запросов. Объединение двух поставщиков, например Google Workspace и TrekMail, может превысить предел.

Решение: упрощайте запись только с помощью поддерживаемого механизма, который обновляет изменения IP. Иначе замена вложенных include: прямыми механизмами ip4: приведёт к устаревшим адресам.

Пример переходной записи:

Если TrekMail работает с вашим SMTP, например Amazon SES или SendGrid, вместо этого добавьте их записи SPF.

Шаг 3: заранее опубликуйте DKIM

DKIM использует селекторы, например google._domainkey. Создайте у нового поставщика ключи с уникальным селектором, например tm1._domainkey. Не используйте имя повторно. Новый селектор можно опубликовать за несколько дней без конфликта со старым поставщиком.

Шаг 4: временно ослабьте DMARC

Если политика DMARC равна p=reject или p=quarantine, не менее чем за 24 часа установите p=none. В первые часы при неполной настройке возможны ошибки аутентификации. p=none позволяет видеть их в отчётах RUA и не требует отклонения только по политике DMARC, но само по себе не гарантирует доставку. Настройка объяснена в руководстве Google по DMARC.

Этап 2: выполнение переключения

TTL снижены, записи аутентификации объединены. Теперь можно перевести маршрутизацию на новый хостинг.

Шаг 1: сравните авторитетный и рекурсивный ответы

Сначала проверьте новые записи на авторитетном сервере имён, а затем через публичный резолвер:

Шаг 2: обновите записи MX

По возможности сначала добавьте и проверьте новые MX, а затем удалите старые, либо выполните изменение атомарно. Для TrekMail:

Оставьте TTL на уровне 300 секунд. Пока не повышайте его.

Шаг 3: очистите кэш и проверьте

Очистите локальный кэш DNS: ipconfig /flushdns в Windows или sudo dscacheutil -flushcache в macOS. Повторите dig. Команда очищает только локальный кэш, поэтому появление новых MX всё ещё зависит от опрошенного резолвера.

Этап 3: стабилизация после переключения

Следите за ошибками определения тенанта (550 5.7.64)

Такая проблема часто возникает при переходе на Microsoft 365 и похожие комплексы. Если целевая система ещё не полностью добавила домен во внутренний каталог, она отклонит письмо с сообщением «Relay Access Denied». До изменения MX убедитесь, что у нового поставщика домен имеет статус «Verified» или «Healthy».

Проверяйте отчёты DMARC (72 часа)

Три дня следите за отчётами RUA:

• Успех: трафик с IP-адресов нового поставщика проходит SPF и DKIM.
• Ошибка: легитимные источники, например платёжные и маркетинговые системы, не проходят проверку. Оперативно исправьте SPF или DKIM.

Очистка (через 72 часа)

После стабилизации трафика:

1. Удалите include: прежнего поставщика из SPF только после прекращения отправки через него.
2. Удалите старые записи DKIM CNAME/TXT после безопасного окна, необходимого для проверки ранее подписанных писем.
3. Верните TTL к 3,600s (1 час) или 86,400s (24 часа).
4. Включите строгую политику DMARC: p=quarantine или p=reject, когда отчёты подтвердят корректную аутентификацию легитимных источников.

Краткий чек-лист переноса ящика

TrekMail упрощает перенос почтового ящика

При ручном управлении DNS легко ошибиться. Одна синтаксическая ошибка в TXT способна сделать недействительной всю политику SPF.

Для малого бизнеса

TrekMail предоставляет проверку состояния DNS в реальном времени. Панель запрашивает авторитетные серверы имён и сверяет записи MX, SPF и DKIM с необходимыми условиями. Обнаруживаемые синтаксические ошибки помечаются, чтобы их можно было исправить до появления возвратов.

Подробнее читайте в статье о настройке почты на своём домене.

Для агентств

Управление более чем 50 доменами требует стандартизации. TrekMail позволяет применять единый шаблон DNS ко всем клиентским пространствам. В тарифах Starter и Agency управляемый SMTP отвечает за репутацию IP и заголовки доставки, поэтому собственное упрощение SPF и план прогрева IP обычно не нужны.

Узнайте, как агентства используют хостинг почты для нескольких доменов.

Все платные тарифы предоставляют бесплатный пробный период на 14 дней, нужна карта. Тариф Nano не требует карты.

Заключение

При переносе ящика чаще всего проблемы возникают во время переключения DNS. Заранее снизьте TTL, объедините записи аутентификации, измените MX в окно обслуживания и наблюдайте за отчётами DMARC в течение 72 часов. Это основа безопасного процесса.

Если вы не хотите вручную координировать DNS, попробуйте TrekMail бесплатно и используйте панель для проверки записей.