Корпоративная почта в Узбекистане: чек‑лист для IT

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

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

Используйте эту статью для предпродажной оценки и постановки требований. После выбора поставщика переходите к отдельным инструкциям: подключение почты к домену, безопасная смена MX, настройка SPF, DKIM и DMARC и перенос архива.

1. Зафиксируйте владельца домена и DNS

Регистратор домена, авторитетные DNS‑серверы, веб‑хостинг и почтовый сервис могут находиться у разных поставщиков. Сначала определите:

• у кого зарегистрирован домен и когда он продлевается;
• какие NS опубликованы и где редактируется фактическая зона;
• кто имеет административный доступ к DNS;
• какие MX действуют сейчас и сколько у них приоритетов;
• есть ли доступный ответственный на окно переключения.

Mailcore не требует переносить домен или передавать пароль от регистратора. Специалист готовит точные значения, а владелец зоны или его администратор вносит их в согласованное время.

Проверять нужно публичный DNS, а не только интерфейс панели. Для первичного снимка пригодятся nslookup -type=mx company.uz или эквивалентный запрос через dig. Сохраните текущие значения и TTL для плана возврата.

Что проверить именно в Узбекистане

Кроме протоколов, зафиксируйте локальные эксплуатационные условия. Уточните расчёт в сумах, сторону договора и комплект закрывающих документов, язык и часы поддержки, а также доступность ответственного в часовом поясе компании. Для домена .uz отдельно проверьте, кто управляет регистрацией, а кто — фактической DNS‑зоной: это могут быть разные организации.

Не выводите местонахождение данных только из задержки или подключения узла к TAS‑IX. Запросите схему хранения, резервных копий и внешних шлюзов. Исходящее письмо может проходить через отдельного провайдера и затем систему получателя за пределами страны. Если локальность обязательна, она должна быть описана по каждому компоненту, а не одним словом «сервер в Узбекистане».

Сравнение этих условий и вопросов по оплате собрано в статье о выборе почтового хостинга в Узбекистане.

2. Постройте карту почтовых идентичностей

Выгрузите или вручную соберите все объекты, которые должны продолжить работу:

• именные ящики сотрудников;
• ролевые адреса info@, sales@, support@, billing@;
• псевдонимы и пересылки;
• общие ящики и адреса подразделений;
• технические адреса для сайта, мониторинга и уведомлений;
• адреса восстановления доступа к банку, CRM и рекламным кабинетам.

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

3. Найдите все исходящие системы

Самая частая проблема после миграции — забытый отправитель. Пользовательская почта уже работает, но форма сайта, CRM или сервис счетов продолжает отправлять по старой схеме либо перестаёт проходить DMARC.

Составьте реестр потоков:

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

4. Проверьте набор DNS‑записей

Роли записей различаются:

• MX задаёт маршрут новых входящих сообщений;
• SPF перечисляет допустимые источники для envelope-from;
• DKIM позволяет проверить подпись конкретного сообщения;
• DMARC связывает результат SPF или DKIM с доменом в видимом From;
• A/AAAA и PTR участвуют в идентичности почтового узла.

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

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

5. Проверьте клиентский доступ до рабочего потока

Для подготовленных ящиков подтвердите:

1. Вход в веб‑почту.
2. Подключение по IMAP с шифрованием.
3. Авторизованную отправку по SMTP.
4. Смену или безопасную передачу первоначального пароля.
5. Работу хотя бы одного используемого настольного или мобильного клиента.

В Mailcore доступны веб‑почта, IMAP и SMTP. При подключении клиент получает точные имена серверов, порты и режимы шифрования. Эти параметры можно раздать сотрудникам отдельной инструкцией, не включая в неё пароли.

6. Разделите переключение MX и перенос архива

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

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

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

7. Определите критерии приёмки

До изменения рабочего MX подготовьте короткий протокол. Минимальный набор:

• все согласованные адреса созданы и принимают локальные тесты;
• внешний адрес доставляет письмо в новый ящик;
• новый ящик отправляет ответ внешнему получателю;
• в заголовках видны ожидаемые SPF, DKIM и DMARC;
• веб‑почта, IMAP и SMTP проверены на используемых клиентах;
• резервный контур прошёл контрольное восстановление;
• сохранены прежние DNS‑значения и понятен порядок возврата;
• старый сервер остаётся доступным до окончания наблюдения.

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

Кто за что отвечает при подключении Mailcore

Такое разделение не отнимает у клиента домен и не оставляет администратора один на один с почтовой инфраструктурой.

Тариф и сценарий, для которого подходит Mailcore

Mailcore ориентирован на небольшие команды, которым нужна управляемая почта на домене без отдельного почтового администратора. Пилотный тариф — 59 000 сум в месяц за один домен и пять ящиков по 1 ГБ, каждый дополнительный ящик с 1 ГБ — 8 000 сум в месяц.

Документы, календарь и видеовстречи не нужно переносить, если команда уже использует подходящие инструменты: Mailcore закрывает именно почтовую часть. Обязательные требования к MFA, SLA, хранению и размещению данных фиксируются в начале, чтобы до оплаты подтвердить доступную конфигурацию.

Что отправить для технической оценки

Для первого ответа достаточно домена, числа ящиков, текущего провайдера, примерного объёма архива и списка внешних отправителей. Mailcore проверит публичный DNS, задаст уточняющие вопросы и подготовит расчёт и порядок перехода. Рабочие записи при этом не меняются.

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

Источники

• RFC 5321: Simple Mail Transfer Protocol
• RFC 7208: Sender Policy Framework
• RFC 6376: DomainKeys Identified Mail
• RFC 9989: Domain-based Message Authentication, Reporting, and Conformance
• RFC 9051: Internet Message Access Protocol
• Google: требования к отправителям электронной почты
• Cloudflare: DNS-записи для электронной почты