Доменная почта компании — как настроить адреса, доставляемость и доступы

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

Доменная почта — это не только красивый адрес name@company.ru. Это контур, в котором компании принадлежат домен и административные доступы, роли сотрудников понятны, письма от имени домена подтверждаются технически, а переписку можно передать, найти, сохранить и закрыть по правилам. Без этого сайт, продажи и поддержка зависят от личных учётных записей и памяти конкретных людей.

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

Минимум, который стоит зафиксировать в реестре активов:

Один супер-администратор не является достаточной схемой. Его учётная запись может быть заблокирована, владелец может быть недоступен, а пароль — потерян. Нужны как минимум две назначенные роли, многофакторная защита и понятный порядок аварийного доступа. Права следует выдавать по ролям, а не создавать для всех один общий пароль от sales@.

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

У доменной почты обычно есть три разных типа адресов.

Путаница начинается, когда один ящик пытается быть всем сразу. Адрес info@, к которому есть пароль у пяти человек, не даёт ни ответственности, ни аудита, ни безопасной передачи при увольнении. Общее обращение лучше обрабатывать через группу, общий ящик с разграниченными доступами или тикет-систему — конкретный механизм зависит от платформы, но принцип один: участники получают доступ под своими учётными записями, а не делят пароль.

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

Эти записи и настройки живут в DNS и почтовом сервисе, но отвечают на разные вопросы.

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

Проверка домена важна не только для массовых рассылок. У компании со временем появляются новые системы отправки, а старые остаются в настройках. Поэтому одного заполнения DNS-записей недостаточно: нужно знать всех отправителей, проверять реальные письма и пересматривать конфигурацию после изменений.

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

Дальше безопаснее двигаться так:

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

Проверять нужно по заголовкам реального письма. В строке Authentication-Results почтовый сервис обычно показывает результаты SPF, DKIM и DMARC. SPF и DKIM могут пройти, а DMARC — нет из-за несогласованности домена в From:. Это полезнее догадки по тому, в какую папку попало одно письмо.

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

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

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

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

В регламенте стоит определить:

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

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

Почта не остаётся настроенной навсегда. Новый сервис рассылок, смена CRM, перенос сайта или истёкший домен меняют её без видимого «почтового проекта».

Регулярная проверка может быть короткой:

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