Перенос почтовых учетных записей: план, IMAP и DNS

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

Знакомая ситуация: кто-то экспортирует PST, кто-то перетаскивает папки в Outlook, кто-то считает все адреса обычными ящиками. В понедельник sales@ не получает почту, большой ящик еще синхронизируется, а команда не знает, на каком сервере актуальные данные. Рассматривайте миграцию как перестройку работающей инфраструктуры, а не передачу файлов.

Это руководство объясняет, как переносить почтовые учетные записи по контролируемому административному процессу. Здесь описаны ручной IMAP, порядок переключения, важные сбои и работа через TrekMail для команд, агентств и MSP. Платформа может сократить обслуживание скриптов, но не гарантирует более быстрый перенос без перерывов.

Что означает перенос почтовых учетных записей?

Вы копируете содержимое ящиков между серверами IMAP, отдельно восстанавливаете алиасы и пересылки, затем при необходимости меняете прием своего управляемого домена через DNS. Перенос личного Gmail или Outlook не дает управления MX их доменов и не переносит исходный адрес автоматически.

Это важно: IMAP выполняет только часть работы. Он копирует папки и поддерживаемое состояние сообщений, но не все настройки вокруг ящика. Согласно области применения RFC 3501, IMAP предназначен для доступа к сообщениям и операций с ящиками, а не полного экспорта деловой учетной записи.

Поэтому при переносе выполняются три задачи:

1. Скопировать и проверить сообщения и структуру папок.
2. С разрешения владельцев восстановить алиасы, рассылочные группы и пересылки.
3. При смене приема своего домена изменить DNS после подготовки назначения.

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

Что переносит IMAP, а что требует отдельной работы

IMAP может переносить письма, папки и обычно флаги прочтения, если их предоставляют сервер и инструмент. Календари, контакты, задачи, подписи приложений и клиентские правила через него не копируются. Подготовьте отдельный план, прежде чем пользователи начнут искать их в новой системе.

Письменно согласуйте объем работ. Миграция TrekMail основана на IMAP и не заменяет перенос функций совместной работы. Поэтому инструкции описывают сервер, порт, имя пользователя, пароль и целевой ящик, а не календари и совместное планирование.

При подготовке используйте такую памятку:

Последний пункт особенно легко упустить. Разницу между алиасом и самостоятельным ящиком объясняет руководство по алиасам и ящикам. Правильный учет поможет избежать лишних исправлений.

Инвентаризация перед переносом почтовых учетных записей

До первой синхронизации соберите максимально полный список. Сопоставьте каждый ящик, алиас, группу, пересылку и требование к хранению с объектом назначения и этапом миграции. Это помогает уменьшить риски.

Одного экспорта пользователей недостаточно. Нужны и малозаметные функции.

Как минимум проверьте:

1. Основные ящики: активные пользователи, общие ящики и функциональные адреса.
2. Алиасы: дополнительные адреса, доставляющие в другой ящик.
3. Группы и списки рассылки: объекты маршрутизации, не являющиеся обычными ящиками IMAP.
4. Пересылки: серверные пути вроде info@ на owner@.
5. Catch-all: решите, сохранить, ограничить или отключить прием неизвестных адресатов.
6. Большие ящики: начните раньше и проверьте ограничения.

Большой объем меняет план. Провайдеры могут ограничивать IMAP, и копирование длится днями, а не часами. Не обещайте перенос за выходные для многолетних вложений без измеренного тестового прохода.

Пример: на пятницу назначен переход 60 пользователей. У руководителя ящик на 48 GB. К воскресенью готовы 59 пользователей, а большой ящик еще копируется. Это иллюстрация возможного риска, а не норматив срока; такую ситуацию нужно учитывать заранее.

Если одновременно стандартизируете создание записей, добавьте памятку подготовки, например инструкцию массового создания почтовых учетных записей. Неполная подготовка назначения может создавать проблемы не меньше DNS.

Как переносить несколько ящиков по этапам

Используйте последовательные группы вместо единовременного переключения всех. Пилот проверяет доступ, соединение и папки. Предварительная копия переносит старую почту в фоне. Следующие проходы учитывают изменения и согласуются с переключением DNS.

Практический порядок:

Этап 1: пилот

Начните с небольшой выборки: ИТ-сотрудники, тестовые записи и один обычный пользователь с реалистичным ящиком. Проверьте TLS на порту 993, цепочку сертификата и имя сервера, а также учетные данные. Сравните отправленные, черновики, архив и пользовательские папки назначения.

Этап 2: предварительное копирование

Запустите основной перенос до запланированных выходных. Старые данные должны оказаться в назначении до реального переключения MX, а не копироваться впервые после него.

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

До переключения перенесите новые и измененные данные. При необходимости измените MX своего домена и проверьте новый прием. Затем продолжайте повторные проходы для поздних писем со старой датой, перемещений и флагов. Старый SMTP, доступ администратора и откат сохраняют на время кешей и повторных доставок. Пользователям нужен один активный рабочий сервер: это не безопасная двусторонняя синхронизация.

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

Ручной перенос с imapsync

Для прямого контроля подходит инструмент IMAP-IMAP вроде imapsync. В зависимости от версии и настроек он поддерживает повторные проходы, сопоставление папок и флаги. Но результат все равно нужно проверить.

Перетаскивание в Outlook, PST и команды по памяти могут давать трудно проверяемые результаты. В клиенте используйте копирование вместо разрушительного перемещения и предварительно сохраните локальные данные.

Повторяемые пакетные задачи, отдельные журналы и запланированная досинхронизация облегчают контроль. TrekMail может объединить такие шаги без самостоятельного обслуживания всех технических компонентов. Подробнее см. руководство администратора по imapsync.

Ниже сохранен иллюстративный исходный шаблон, не готовый проверенный скрипт. Его shebang неверен. До запуска исправьте собственную рабочую копию и проверьте параметры установленной версии: в частности пароли, журналы, ускорение и сравнение размера. --log включает ведение журнала, а не принимает имя файла; для пути нужна подходящая опция установленной версии. Уточните актуальный сервер IMAP в настройках приложений. Простой разделитель запятыми не поддерживает полноценный CSV с кавычками, запятыми и переносами в полях. Файлы с паролями требуют ограниченных прав; учетные данные не должны бесконтрольно попадать в процессы и журналы:

#!$0

# users.csv format:
# source_user,source_pass,dest_user,dest_pass

while IFS=, read -r src_user src_pass dest_user dest_pass
do
  echo "[START] $src_user -> $dest_user"

  imapsync \
    --host1 imap.old-provider.com --user1 "$src_user" --pass1 "$src_pass" --ssl1 \
    --host2 mail.trekmail.net --user2 "$dest_user" --pass2 "$dest_pass" --ssl2 \
    --automap \
    --usecache \
    --fast \
    --skipsize \
    --subfolder2 "Imported_Mail" \
    --log "logs/${src_user}.log"

  echo "[DONE] Review logs/${src_user}.log"
done < users.csv

Несколько практических замечаний:

Используйте кеш осознанно. Поддерживаемый режим может уменьшать повторное чтение метаданных. Он необязателен, зависит от метода и не делает UID глобальными идентификаторами или доказательством целостности.

При необходимости используйте промежуточную папку. Отдельное размещение импорта может облегчать сверку, но не решает конфликт параллельной работы. Указанный каталог меняет целевые пути, не заменяет окончательное сопоставление и не гарантирует корректную обработку перемещений или удалений.

Ведите журнал каждого ящика. Нужно знать, какой ящик, где и почему завершился с ошибкой. Безусловная строка DONE ничего не доказывает: проверяйте код завершения, очищенные журналы, количество, содержимое, вложения, даты, папки и флаги. Ограничьте права на файлы и удаляйте секреты из диагностики. Разрушительное распространение удалений нельзя включать без отдельного плана и проверки.

Переключение DNS требует отдельного контроля

При смене приема своего домена заранее уменьшите TTL MX и учтите, когда истекут старые кеши. После готовности назначения переключите записи и планово уберите ненужные старые MX. Проверьте новый прием, сохраняя старый SMTP и досинхронизацию для писем, приходящих по кешам и повторным попыткам.

Завершение копирования не меняет доставку. DNS направляет прием своего домена; личные адреса провайдера требуют сохранения прежней записи или разрешенной пересылки.

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

Сверяйте записи с актуальной документацией и панелью TrekMail. Пример ниже нельзя применять вслепую: сохраняйте SPF-авторизацию всех легитимных служб, публикуйте подходящие ключи DKIM и проверяйте действующую подпись. DMARC требует успешного SPF с выравниванием или корректной DKIM-подписи с выравниванием; не ужесточайте политику без проверки во время переноса:

@                 MX   10 mail.trekmail.net.
@                 TXT  "v=spf1 include:spf.trekmail.net -all"
dkim._domainkey   TXT  "<unique TrekMail DKIM value>"
_dmarc            TXT  "v=DMARC1; p=quarantine;"

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

1. Ненужные старые MX удалены по плану.
2. Подходящие новые MX опубликованы.
3. Одна политика SPF на имя включает все нужные службы; другие TXT допустимы.
4. DKIM опубликован, реальная корректная подпись проверена.
5. DMARC опубликован, подтвержден хотя бы один успешный путь с выравниванием From.
6. Тест приходит в назначение, а поздняя почта на старом сервере еще учитывается.

После переключения следите за доставкой и отказами. Для значимого трафика Gmail Google Postmaster Tools могут дать дополнительные, но неполные сведения. Миграция требует проверки приема, отправки и работы, а не только последней копии письма.

Перенос через TrekMail

Документированный серверный инструмент TrekMail копирует почту из подходящего IMAP-источника. Это может избавить от собственного виртуального сервера и части скриптов. Доступ, ошибки, папки и дополнительные проходы все равно нужно контролировать.

Возможные различия:

Сверьте актуальный порядок:

1. Добавить домен и подготовить DNS, но переключать MX лишь после проверенного предварительного импорта.
2. Создать целевой ящик и проверить доступ.
3. Открыть миграцию в панели.
4. Указать исходный IMAP-сервер, порт, имя пользователя и допустимый пароль.
5. Выбрать ящик TrekMail назначением.
6. Запустить импорт и проверить состояние и фактический результат.

Актуальные инструкции: обзор IMAP, запуск миграции в панели, создание ящика и необходимые DNS-записи. Прямой импорт использует имя и пароль IMAP, не интерактивный OAuth. Пароль приложения Gmail зависит от двухэтапной проверки и политики; при обязательном OAuth нужен другой поддерживаемый путь.

Источник приводит Starter от $3.50 в месяц, Nano за $0 и платные Starter, Pro, Agency, Enterprise. Бесплатный Nano без карты и пробный период на 14 дней с банковской картой являются условиями источника; проверяйте их актуальность. Общее хранение может облегчать распределение крупных ящиков, но объем и функции по-прежнему ограничены тарифом.

Сравнивайте актуальные тарифы TrekMail.

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

Короткая заключительная проверка помогает обнаружить отсутствующие алиасы, старые DNS-значения, неверные пароли и незавершенные крупные импорты. Она уменьшает риск, но не гарантирует перенос без потерь.

До изменений убедитесь:

1. Все целевые ящики созданы, вход проверен.
2. Алиасы, пересылки и группы восстановлены с разрешением и протестированы.
3. Исходный IMAP доступен по TLS на порту 993, сертификат и имя проверены.
4. Большие ящики предварительно скопированы и проверены заранее.
5. TTL снижен вовремя, старые кеши учтены.
6. Старые MX записаны вместе с планом отката.
7. Досинхронизация до и после переключения запланирована.
8. Пользователи знают, когда прекращать изменения на прежнем сервере; локальные несинхронизированные данные сохранены до удаления профилей.
9. Один тестовый ящик готов к проверке приема и отправки.
10. Назначен ответственный за наблюдение после перехода.

Рутинность здесь полезна. Контролируемый перенос выявляет неожиданности заранее, а не только после жалоб пользователей.

Вывод: перенос по проверяемому процессу

Если нужно переносить почтовые учетные записи одного домена или пятидесяти, сначала учтите функции, скопируйте данные, аккуратно переключите нужный DNS и проверьте доставку. IMAP копирует ящики, но не заменяет продуманного проекта и проверки целостности.

Ручной путь остается вариантом для прямого контроля и самостоятельного обслуживания инструментов. При частых переносах могут помочь тарифная модель нескольких доменов, общее хранение, IMAP и панель TrekMail. Пригодность и расходы зависят от текущих условий и требований, а не обещания отсутствия оплаты каждого нового ящика. Рассмотрите Nano или тарифы, если нужен импорт в платном плане.