Как Mailcore подключает домен: от заявки до рабочей почты

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

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

Кому подходит сопровождаемое подключение

Сценарий рассчитан на небольшую команду, которой нужны адреса на собственном домене: например, info@company.uz, sales@company.uz и именные ящики сотрудников. Пользователи получают веб‑почту, а также параметры IMAP и SMTP для настроенных почтовых программ.

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

Управление доменом остаётся у клиента, пароль от регистратора передавать не нужно. Мы не меняем MX без согласованного окна и контрольных проверок. Старые письма переносятся отдельным этапом по IMAP, если исходный сервер это позволяет. Обязательные требования к SLA, MFA и хранению фиксируются при согласовании конфигурации.

Если хочется сначала разобраться в терминах, начните со статьи что такое корпоративная почта. Она объясняет разницу между доменом, ящиком, веб‑почтой и почтовым сервером.

Что мы выясняем до любых изменений

Первый этап — короткая инвентаризация. Она нужна даже для нового домена: DNS может обслуживаться не там, где домен был куплен, а часть записей уже может использовать сайт, CRM или сервис рассылок.

Перед подключением мы просим подтвердить:

• доменное имя и место, где сейчас управляется его DNS;
• список требуемых ящиков и служебных адресов;
• наличие действующей почты и примерный объём старых писем;
• почтовые программы, которыми пользуется команда;
• сервисы, которые отправляют письма от имени домена;
• человека, который сможет внести DNS-записи и выполнить контрольный тест.

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

Отдельно фиксируется перечень адресов. Распространённая ошибка — перенести только именные ящики и забыть info@, support@, адрес для счетов или перенаправление с устаревшего имени. До переключения полезно собрать список из панели прежнего провайдера и дополнить его адресами, указанными на сайте, в договорах и визитках.

Как проходит подключение по шагам

1. Проверяем исходный DNS

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

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

2. Создаём согласованные ящики

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

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

3. Готовим набор DNS-записей

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

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

4. Согласовываем окно и меняем MX

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

Во время обновления DNS разные отправители некоторое время могут видеть разные ответы. Часть писем способна прийти на старый сервер, часть — уже на новый. Это нормальная особенность распределённой системы DNS, поэтому оба контура временно остаются доступными. Подробнее саму механику записи объясняет статья как работает MX для почты.

5. Выполняем контрольные тесты

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

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

Что происходит со старой почтой

Переключение MX влияет на новые входящие письма, но не переносит историю. Архив остаётся на прежнем сервере, пока его не скопируют или пользователь не сохранит его другим способом. Поэтому до отключения старого тарифа важно проверить срок доступа и не удалять исходные ящики.

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

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

Что получает команда после проверки

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

Мы передаём короткий чек‑лист для пользователей: как войти, как добавить аккаунт в клиент, куда сообщить о проблеме и какие тесты уже выполнены. Если использовался прежний сервер, отдельно фиксируется статус переноса архива и дата, до которой старый доступ нужно сохранить.

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

Контрольный список владельца домена

Перед тем как считать подключение завершённым, проверьте пять вещей:

1. Каждый согласованный адрес принимает тестовое письмо извне.
2. Из каждого типа клиента — веб‑почты или почтовой программы — можно отправить ответ.
3. MX, SPF, DKIM и DMARC видны в публичном DNS именно в согласованном виде.
4. Старый почтовый сервер ещё доступен, если на нём остались письма переходного периода.
5. У команды есть контакты для сообщения об ошибке и никто не хранит общий пароль в открытом документе.

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

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

Источники

• Google: требования к отправителям писем
• Google Workspace: рекомендации по DMARC
• Microsoft Learn: аутентификация электронной почты
• RFC 5321: Simple Mail Transfer Protocol
• RFC 9051: Internet Message Access Protocol