Как подключить почту к домену: пошаговая инструкция

Почта на собственном домене начинается не с кнопки «Создать ящик», а с маршрута: отправители должны понимать, на какой сервер доставлять сообщения для company.uz, а получатели — иметь рабочие способы входа и отправки. За маршрут отвечает DNS, за хранение — почтовый сервис, а за ежедневный доступ — веб‑почта или приложение с IMAP и SMTP.

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

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

Разделите домен, DNS и почтовый сервис

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

Сначала выясните, где находятся авторитетные DNS-серверы домена. Именно там нужно будет менять MX и добавлять записи аутентификации. Панель регистратора может показывать настройки домена, но не управлять зоной, если NS-записи делегированы другому сервису.

Затем зафиксируйте, что уже работает от имени домена. Помимо обычных ящиков письма могут отправлять CRM, форма на сайте, система уведомлений или сервис рассылок. Если забыть такой источник при изменении SPF и DMARC, легитимные сообщения начнут проваливать проверку.

Для общего понимания архитектуры полезно прочитать что такое корпоративная почта, а назначение протоколов входа и отправки разобрано в статье IMAP и SMTP: в чём разница.

Составьте список адресов до настройки

Создайте таблицу всех требуемых адресов. В неё стоит включить не только сотрудников, но и функциональные контакты: info@, sales@, support@, адрес для счетов, уведомлений и восстановления доступа к важным сервисам.

Для каждого адреса определите тип:

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

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

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

Подготовьте ящики и доступ пользователей

Ящики создаются до переключения MX. Для каждого пользователя понадобятся уникальный пароль и понятная инструкция по входу. Если сервис поддерживает веб‑почту, проверьте авторизацию через браузер. Если команда работает в Outlook, Thunderbird, Apple Mail или мобильном приложении, заранее уточните параметры IMAP и SMTP.

Нельзя считать настройку завершённой только потому, что форма создания ящика показала зелёную отметку. До публичного переключения полезно проверить:

1. правильность написания каждого адреса;
2. вход в веб‑почту;
3. подключение по IMAP для получения и синхронизации папок;
4. SMTP с шифрованием и авторизацией для отправки;
5. смену временного пароля и хранение секретов в менеджере паролей.

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

Получите у провайдера точные DNS-записи

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

MX не должен указывать на IP-адрес: по стандартной модели он ссылается на доменное имя почтового сервера. Если сервис выдаёт несколько MX, сохраните все значения и их приоритеты. Подробное объяснение есть в статье MX-запись для почты.

У домена должна быть одна результирующая SPF-политика. Добавление нескольких отдельных TXT-записей, каждая из которых начинается с v=spf1, создаёт ошибку проверки. Когда источников несколько, их объединяют в одну политику с учётом ограничений SPF. Точные механизмы лучше поручить администратору или сверить с документацией каждого отправителя.

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

Выберите безопасный момент для переключения MX

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

До изменения MX убедитесь, что:

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

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

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

Проверьте почту с внешних адресов

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

Минимальный контроль выглядит так:

1. внешний адрес отправляет письмо на домен;
2. пользователь получает его в веб‑почте;
3. пользователь отвечает через SMTP;
4. внешний получатель видит ответ;
5. в технических заголовках отражаются ожидаемые результаты SPF, DKIM и DMARC;
6. проверка повторяется для одного адреса в почтовом приложении через IMAP.

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

Сохраните старый контур до приёмки

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

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

Храните исходные данные до формальной приёмки. Даже если копирование прошло без ошибок, пользователи могут заметить недостающую нестандартную папку или локальный архив позже. Старый контур остаётся страховкой до подтверждения нового.

Как этот процесс выглядит в Mailcore

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

Технический специалист со стороны клиента сохраняет контроль над DNS и получает готовый набор значений и сценарий проверки. Сайт, CRM и другие внешние маршруты учитываются до ужесточения SPF и DMARC. Необходимость переноса старых писем оценивается отдельно, а исходный сервер сохраняется до приёмки. Подробный процесс со стороны сервиса описан в статье как 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
• Google: требования к отправителям писем