Миграция почты без потери писем: пошаговая схема

MAATRIX

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

Общая логика миграции

Прежде чем переходить к командам, важно понять саму механику — иначе шаги будут выглядеть как ритуал без смысла. Почта устроена так, что отправляющий сервер узнаёт, куда доставлять письмо, не в момент отправки, а заранее — он смотрит MX-запись домена и часто держит её результат в кэше (DNS resolver на его стороне) какое-то время. Из-за этого смена почтового сервера — это не «выключил старый, включил новый», а растянутый во времени процесс, в котором оба сервера должны какое-то время работать параллельно.

Пошагово это выглядит так:

1. Разворачиваете и полностью настраиваете новый почтовый сервер — домены, ящики, SPF/DKIM/DMARC — пока MX ещё указывает на старый.
2. Переносите существующие письма imapsync-ом, пока старый сервер продолжает как ни в чём не бывало принимать новую входящую почту.
3. Снижаете TTL у MX-записи заранее, за 24–48 часов до переключения.
4. Делаете финальную (дельта-)синхронизацию — переносите то, что пришло на старый сервер уже после первого переноса.
5. Переключаете MX на новый сервер.
6. Ключевой момент, который обычно упускают: старый сервер должен ещё некоторое время после переключения принимать почту и либо форвардить её на новый, либо ждать повторной синхронизации — потому что не все отправители в интернете узнают о смене MX мгновенно.

Дальше — детали каждого шага с конкретными командами и записями.

Готовим новый сервер заранее

Новый сервер должен быть полностью рабочим ДО того, как на него пойдёт хоть один реальный запрос доставки. Это значит: почтовый демон установлен и настроен, все ящики созданы, DNS-записи для аутентификации подготовлены (но не обязательно ещё «боевые» — SPF/DKIM/DMARC можно и нужно поднять заранее, MX-переключение с ними не связано).

Если стек — Postfix (SMTP) + Dovecot (IMAP), базовая установка и первичная настройка подробно разобраны в статье про установку почтового сервера Postfix на VPS — не буду повторять её здесь, сосредоточусь на том, что специфично именно для миграции.

Что обязательно нужно на новом сервере до переноса писем:

• Домен и все алиасы/ящики созданы в Dovecot (/etc/dovecot/ + база пользователей — mysql, sqlite или virtual mailboxes, в зависимости от вашей схемы).
• Postfix настроен принимать почту для домена (mydestination или virtual_mailbox_domains) и слушает 25/465/587 порты извне — проверьте, что провайдер VPS не блокирует 25-й порт по умолчанию (у некоторых хостеров он закрыт для новых аккаунтов, уточняйте отдельно).
• IMAP на новом сервере доступен снаружи — он понадобится, чтобы imapsync мог к нему подключиться для переноса писем.

DNS-записи для аутентификации подготовьте заранее, в отдельном TXT-имени, чтобы не трогать пока боевые SPF/DKIM. Пример полного набора для домена example.com:

; SPF — заявляем, какие сервера имеют право слать почту от домена
example.com.            TXT   "v=spf1 mx ip4:203.0.113.10 ~all"

; DKIM — публичный ключ подписи, селектор произвольный, например mail2026
mail2026._domainkey.example.com. TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSq..."

; DMARC — политика и адрес для отчётов
_dmarc.example.com.     TXT   "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; pct=100"

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

Переносим существующие письма: imapsync

Когда новый сервер готов принимать письма через IMAP, переносите содержимое ящиков — стандартный инструмент для этого imapsync: он подключается по IMAP сразу к двум серверам и копирует письма, папки и флаги (прочитано/непрочитано) между ними, при этом умеет докопировать только новое при повторном запуске, не дублируя уже перенесённое.

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

Пример запуска для одного ящика:

imapsync \
  --host1 old.example.com --user1 'ivanov@example.com' --password1 'STAROY_PAROL' --ssl1 \
  --host2 new.example.com --user2 'ivanov@example.com' --password2 'NOVY_PAROL'   --ssl2 \
  --automap --syncinternaldates --skipsize

Флаги, которые стоит понимать:

• --automap — автоматически сопоставляет одноимённые папки (Inbox, Sent, Drafts) даже если у серверов разные соглашения об именах.
• --syncinternaldates — сохраняет исходную дату письма, а не дату переноса — иначе почтовый клиент отсортирует всё «сегодняшним числом».
• --skipsize — ускоряет сверку, не сравнивая размер писем побайтово (полезно на больших ящиках).

Если ящиков много, оберните вызов в цикл по списку аккаунтов:

#!/bin/bash
# accounts.txt: строки вида user@example.com:пароль_на_старом:пароль_на_новом
while IFS=: read -r email pass_old pass_new; do
  imapsync \
    --host1 old.example.com --user1 "$email" --password1 "$pass_old" --ssl1 \
    --host2 new.example.com --user2 "$email" --password2 "$pass_new" --ssl2 \
    --automap --syncinternaldates --skipsize \
    --logdir "/var/log/imapsync/$email"
done < accounts.txt

Для крупных ящиков (гигабайты писем) первый прогон может занять часы — это нормально, запускайте его заранее, за несколько дней до планируемого переключения MX, а не в ночь перед ним. --logdir пригодится, чтобы потом свериться, сколько писем реально перенеслось и не было ли ошибок аутентификации на каком-то ящике.

Снижаем TTL у MX-записи заранее

Это отдельный, самостоятельный шаг, который нужно сделать за 24–48 часов до фактического переключения MX — не в момент переключения, а именно заранее. TTL (time to live) — это время в секундах, которое резолверы по всему интернету хранят ответ DNS в кэше, прежде чем спросить заново. Если у вашей текущей MX-записи TTL, скажем, 43200 (12 часов) или больше, то после переключения часть отправителей будет узнавать о смене ещё до конца этого срока.

Смотрим текущий TTL:

dig example.com MX
# example.com.  43200  IN  MX  10 old.example.com.
#               ^^^^^ вот это TTL в секундах

Снижаем его в панели DNS-провайдера до 300 секунд (5 минут), сохраняя пока тот же старый MX-адрес — меняется только TTL, значение записи трогать рано:

example.com.  300  IN  MX  10 old.example.com.

Важный нюанс: снижение TTL само по себе не ускоряет распространение мгновенно — старое, уже закэшированное где-то значение с прежним (большим) TTL будет жить в чужих кэшах ровно столько, сколько было указано ДО вашего изменения. Именно поэтому снижать TTL нужно заранее и подождать хотя бы столько времени, сколько был старый TTL, — только тогда к моменту реального переключения все резолверы будут спрашивать запись заново каждые 5 минут, а не досиживать старое значение часами.

Финальная синхронизация перед переключением

К моменту, когда TTL уже снижен и прошло достаточно времени, на старом сервере наверняка накопились новые письма — те, что пришли между первым прогоном imapsync и текущим моментом. Запустите imapsync повторно по тем же аккаунтам: инструмент сам определит, какие письма уже перенесены (по Message-ID и внутренним меткам), и скопирует только дельту — разница обычно занимает минуты, а не часы, даже если первый перенос шёл сутки.

# тот же скрипт что и раньше — imapsync сам пропустит уже перенесённое
while IFS=: read -r email pass_old pass_new; do
  imapsync \
    --host1 old.example.com --user1 "$email" --password1 "$pass_old" --ssl1 \
    --host2 new.example.com --user2 "$email" --password2 "$pass_new" --ssl2 \
    --automap --syncinternaldates --skipsize
done < accounts.txt

Эту финальную синхронизацию имеет смысл запускать максимально близко к моменту переключения MX — например, за час-два до него, — чтобы дельта была минимальной и вы точно не потеряли ни одного письма, пришедшего на старый сервер за время подготовки.

Переключаем MX и следим за распространением

Теперь меняете саму MX-запись на новый сервер:

example.com.  300  IN  MX  10 new.example.com.

Дальше — не расслабляться, а следить. Проверяйте, что видят разные точки интернета:

dig example.com MX
dig @8.8.8.8 example.com MX
dig @1.1.1.1 example.com MX

Честно предупреждаю: при низком TTL большинство резолверов подхватят новую запись в течение нескольких часов, но это не значит, что абсолютно весь интернет узнает об изменении так же быстро. Полное глобальное распространение DNS-изменения — это вопрос дней, а не часов: часть почтовых систем в мире кэширует MX агрессивнее рекомендованного TTL, часть работает через собственные внутренние резолверы с задержкой обновления, а часть отправителей вообще шлёт письма редко и может «вспомнить» старый MX спустя долгое время после последнего обращения к DNS. Рассчитывать конкретный процент здесь бессмысленно — ситуация у каждого домена своя, в зависимости от того, кто и как часто ему пишет.

Именно из-за этой неопределённости следующий шаг — не формальность, а обязательное условие, чтобы не потерять письма.

Критический момент: старый сервер должен ещё принимать почту

Это самая частая причина реальной, безвозвратной потери писем при миграции почты — и её обходят стороной в поверхностных инструкциях. После переключения MX старый сервер ОБЯЗАН продолжать принимать почту ещё какое-то время (разумный ориентир — несколько дней, но точный срок зависит от того, кто вам пишет), потому что часть отправителей в мире физически ещё не знает о смене MX и будет пытаться достучаться по старому адресу.

Если в этот момент старый сервер просто выключен или перестал принимать почту на домен — письма от таких отправителей не встанут в очередь на новом сервере и не «долетят» позже. Они либо вернутся отправителю с ошибкой недоставки (если его сервер вообще будет пытаться повторно — а это не гарантировано), либо, что хуже, будут просто потеряны без какого-либо уведомления, если старый сервер отвечает 550 на неизвестный домен вместо честного 421 try again later. Второй случай — самый опасный, потому что вы даже не узнаете, что письмо не дошло.

Есть два рабочих способа закрыть эту дыру, и лучше комбинировать оба:

Способ 1: форвардинг со старого сервера на новый. Настройте на старом Postfix пересылку всей входящей на домен почты на новый сервер вместо локальной доставки — тогда письма, попавшие «не туда», автоматически долетят до адресата без вашего участия:

# /etc/postfix/transport на старом сервере
example.com    smtp:[new.example.com]:25

postmap /etc/postfix/transport
postconf -e 'transport_maps = hash:/etc/postfix/transport'
systemctl reload postfix

Старый сервер при этом продолжает принимать письма как раньше (проверка SPF/грейлистинг проходят на нём), но вместо локальной доставки в ящик пересылает их дальше — на новый сервер, где они и попадают в реальный mailbox. Оставьте эту конфигурацию работать хотя бы неделю после переключения MX, а лучше дольше, если есть возможность — выключить старый сервер вы всегда успеете, а вот вернуть потерянное письмо — нет.

Способ 2: повторная финальная синхронизация через несколько дней. Даже если вы настроили форвардинг, не лишним будет через 3–7 дней после переключения снова прогнать imapsync по старому серверу — на случай, если форвардинг где-то дал сбой или несколько писем всё же осели локально в старых ящиках, а не переслались. Это дешёвая страховка, которая занимает пару минут на аккаунт.

Если по каким-то причинам форвардинг настроить нельзя (например, старый сервер арендован у провайдера, который вы уже покидаете, и доступ ограничен) — тогда единственная защита это регулярные повторные imapsync-прогоны на всём протяжении «хвостового» окна, пока старый сервер физически ещё жив и принимает почту. Отключать старый сервер раньше, чем вы убедитесь по логам, что на него давно никто не стучится, — не стоит: похожие сценарии рассинхронизации DNS разобраны в статье про проблемы с DNS после переезда, там же — как отличить «ещё расходится» от «уже сломано».

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