Корпоративная почта на своём домене: выбор и настройка

Из чего состоит почта на своём домене

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

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

Шаг 1. Выберите размещение по задачам, а не по числу красивых функций

Из российских сервисов можно рассмотреть Яндекс 360 и VK WorkSpace. Для собственного контура существуют коммерческие платформы и открытые компоненты, например Postfix/Dovecot; администрирование такого стека — отдельный проект. Возможности Dovecot описаны в документации проекта.

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

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

Шаг 2. Защитите домен и административные аккаунты

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

1. Зафиксируйте владельца домена, регистратора, срок оплаты и ответственного.
2. Найдите фактический DNS-хостинг: он может отличаться от регистратора и веб-хостинга.
3. Включите MFA для административных входов и подготовьте аварийный способ восстановления.
4. Разделите повседневный доступ к ящику и управление всей организацией.
5. Сохраните экспорт DNS-зоны и список исходных настроек перед изменениями.

Доступы должны принадлежать компании, а подрядчик — получать управляемые полномочия. Не делегируйте NS без необходимости: при смене серверов DNS нужно сохранить записи сайта, сертификатов, VPN и остальных сервисов, а не только MX.

Шаг 3. Соберите все источники и получателей писем

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

• Сотрудники: персональные ящики и устройства.
• Общие адреса: sales@, support@, accounting@ и право отвечать от их имени.
• Приложения: 1С, CRM, сайт, системы уведомлений.
• Устройства: принтеры и сканеры, которые отправляют документы.
• История: папки, архивы, правила, делегирование, контакты и календари.

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

Пример: sales@ может быть общим ящиком с историей и ответственными. Alias на одного менеджера просто доставит письмо в его ящик; распределения, общей истории и прав команды от этого не появится.

Шаг 4. Подтвердите домен и создайте адреса до переключения MX

1. Добавьте домен в выбранную почтовую организацию.
2. Возьмите проверочный TXT/CNAME из её кабинета и опубликуйте на фактическом DNS-хостинге.
3. Дождитесь подтверждения права управления доменом.
4. Создайте пользователей, общие адреса, группы и необходимые aliases.
5. Настройте MFA, восстановление доступа, квоты и права.
6. Проверьте вход пилотного пользователя через штатную веб-почту.

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

Не раздавайте всем один пароль от общего ящика. Используйте персональные учётные записи и поддерживаемое делегирование. Пароли генерируют; первоначальную выдачу и восстановление организуют отдельно от общедоступного списка сотрудников.

Что означают MX, SPF, DKIM и DMARC

Другие TXT, например подтверждение домена, могут существовать рядом со SPF. Удалять все TXT подряд нельзя. В разных панелях имя задаётся как @, полное имя или относительная часть; проверьте, что домен не добавился дважды.

Шаг 5. Настройте входящую доставку: MX

В инструкции провайдера возьмите полный набор MX, приоритеты и необходимые значения. В поле MX обычно указывают имя сервера, а не IP, URL веб-почты или адрес сотрудника. Меньшее значение приоритета означает предпочтительный маршрут.

Конкретный пример для Яндекс 360, сверенный с официальной инструкцией MX:

Тип:       MX
Имя:       @
Приоритет: 10
Значение:  mx.yandex.net.

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

• Старый MX не оставляют «на всякий случай», если на нём нет согласованной маршрутизации и защиты.
• Несколько MX не означают дублирование каждого письма на все серверы.
• Если перед ящиками используется антиспам-шлюз, публичный MX должен соответствовать именно этой архитектуре.
• Подробная инструкция по шлюзу — Proxmox Mail Gateway.

Шаг 6. Опишите все легальные источники в SPF

SPF проверяет право узла отправлять от имени домена envelope sender, а не просто имя сотрудника в видимом From. Для домена должна быть одна применимая SPF-запись, начинающаяся с v=spf1; две параллельные записи не объединяются автоматически.

В первоначальной настройке Яндекс 360 приведён вариант:

v=spf1 redirect=_spf.yandex.net

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

• Авторизуйте необходимые сервисы, а не все серверы подряд.
• Не используйте +all: это разрешает любой источник.
• Учитывайте лимит DNS-проверок механизмов SPF; вложенные include также имеют значение.
• Проверяйте реальный envelope sender: «письмо пришло» не доказывает SPF pass для нужного домена.

Модель и ограничения описаны в RFC 7208. Поддержание перечня отправителей — постоянная задача: старый сервис следует выводить из схемы после завершения его использования.

Шаг 7. Включите DKIM на каждой отправляющей системе

DKIM добавляет подпись к письму; получатель проверяет её публичным ключом DNS. Закрытый ключ остаётся на стороне подписывающей системы. Он не публикуется в DNS и не передаётся в технический паспорт.

1. В кабинете провайдера включите подпись для своего домена.
2. Скопируйте точные selector, тип записи и публичное значение.
3. Опубликуйте запись на нужном DNS-хостинге и проверьте имя.
4. Дождитесь проверки провайдером и подтвердите подпись у внешнего получателя.
5. При ротации не удаляйте старый selector до завершения согласованного перехода.

Для Яндекс 360 официальный пример имени — mail._domainkey, но ключ берут только из кабинета вашей организации. Последовательность показана в инструкции DKIM. Другой поставщик может выдать другой selector или CNAME.

Если письма отправляют два независимых сервиса, у них могут быть разные selectors. Публикация ключа не заставляет приложение подписывать письма. Подпись также не доказывает безопасность вложения; назначение DKIM описано в RFC 6376.

Шаг 8. Введите DMARC с наблюдением и контролем изменений

DMARC связывает домен видимого From с успешной SPF- или DKIM-проверкой через alignment. Просто SPF pass либо DKIM pass от постороннего домена недостаточно. Для начала подготовьте действующий адрес сбора агрегированных отчётов и опубликуйте согласованную политику наблюдения.

Учебный домен: corp.example.net
Имя TXT:       _dmarc
Значение:      v=DMARC1; p=none; rua=mailto:dmarc@corp.example.net

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

После инвентаризации и проверки всех легальных отправителей планируйте переход к quarantine/reject. Учитывайте пересылки и изменения писем, отслеживайте отказы. Политика домена не гарантирует одинаковое решение всех получателей. Базовая модель — в RFC 7489; требования конкретных получателей проверяют отдельно.

SPF/DKIM/DMARC не защищают от домена-двойника, поддельного отображаемого имени или письма со взломанного настоящего ящика.

Шаг 9. Проверьте DNS снаружи, а не только зелёный статус панели

На Windows используйте PowerShell. Все имена ниже учебные; запросы ничего не изменяют.

$MailDomain = 'corp.example.net'
Resolve-DnsName -Name $MailDomain -Type NS
Resolve-DnsName -Name $MailDomain -Type MX
Resolve-DnsName -Name $MailDomain -Type TXT
Resolve-DnsName -Name ('mail._domainkey.' + $MailDomain) -Type TXT
Resolve-DnsName -Name ('_dmarc.' + $MailDomain) -Type TXT

Selector и тип DKIM замените на реальные. Если провайдер использует CNAME, проверьте соответствующую цепочку. Для сравнения запросите нужный сервер DNS явно:

$DnsServer = Read-Host 'Адрес согласованного DNS-сервера для проверки'
Resolve-DnsName -Name $MailDomain -Type MX -Server $DnsServer
Resolve-DnsName -Name $MailDomain -Type TXT -Server $DnsServer

Различайте авторитетную зону и кэш рекурсивного сервера. Исправление в панели не меняет уже закэшированный ответ мгновенно. Команда Resolve-DnsName проверяет DNS, но не создаёт ящик и не доказывает прохождение DMARC реальным письмом.

На Linux можно использовать dig:

dig NS corp.example.net
dig MX corp.example.net
dig TXT corp.example.net
dig TXT mail._domainkey.corp.example.net
dig TXT _dmarc.corp.example.net

Шаг 10. Подключите сотрудников и приложения разными способами

Пользователь открывает веб-почту или подключает поддерживаемое приложение. Сервер отправляет внешнюю почту отдельно. Типовые роли портов:

• 25/TCP: обмен SMTP между почтовыми серверами.
• 587/TCP с STARTTLS: submission пользователя или приложения, если поддерживается сервисом.
• 465/TCP: submission с неявным TLS, если поддерживается.
• 993/TCP: IMAP с TLS для работы с ящиком.
• 443/TCP: веб-почта и другие HTTPS-функции.

Точные имена, методы входа, порты и политики берут у выбранного поставщика. Не включайте устаревший открытый вход ради старого клиента. Где возможно, используйте поддерживаемую современную аутентификацию; пароли приложений — только если они предусмотрены и разрешены политикой. Общий подход TLS для доступа и submission описан в RFC 8314.

Для 1С, CRM и сканера выделите отдельный управляемый способ отправки. Не используйте пароль администратора почтовой организации. Определите разрешённый From, ограничения, владельца и отзыв доступа.

Проверка сертификата и SMTP — отдельный этап

На диагностическом Linux-узле с OpenSSL можно проверить TLS без отправки сообщения. Подставьте реальные hostname и поддерживаемый режим:

# Submission с STARTTLS
openssl s_client -starttls smtp -connect smtp.corp.example.net:587   -servername smtp.corp.example.net -verify_hostname smtp.corp.example.net   -verify_return_error </dev/null

# IMAP с неявным TLS
openssl s_client -connect imap.corp.example.net:993   -servername imap.corp.example.net -verify_hostname imap.corp.example.net   -verify_return_error </dev/null

-servername передаёт SNI, -verify_hostname проверяет имя, -verify_return_error не позволяет считать ошибку цепочки нормальным результатом. Синтаксис — в документации OpenSSL. Эти проверки не выполняют SMTP AUTH, не отправляют письмо и не подтверждают наличие прав Send As.

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

Если сервер собственный: DNS-записей недостаточно

• Доступен ли исходящий SMTP у хостера, нет ли блокировки порта 25.
• Есть ли выделенный пригодный IP и возможность задать PTR у владельца адреса.
• Согласованы ли прямое и обратное разрешение, SMTP-имя, сертификаты и фактический исходящий маршрут.
• Запрещён ли неавторизованный relay между внешними адресами.
• Кто обновляет ОС и почтовую платформу, отслеживает очередь, репутацию и заполнение дисков.
• Как проверяются резервные копии ящиков, конфигурации и ключей.

PTR настраивается у владельца IP, а не добавлением произвольного TXT в зоне компании. При SaaS за исходящие узлы отвечает провайдер; параметры клиентского подключения не обязательно совпадают с MX.

Крупные получатели имеют свои требования к отправителям, например Gmail sender guidelines. Корректная аутентификация — необходимая часть настройки, но не обещание попадания каждого письма во «Входящие».

Перенос существующей почты: подготовка, переключение, сверка

1. 1. Подготовить адреса и доступИнвентаризация, новые ящики, права и пилот.
2. 2. Перенести основную историюПисьма и папки; другие данные — отдельно.
3. 3. Переключить маршрут и клиентовMX, источники отправки и контроль обеих систем.
4. 4. Догрузить дельту и сверитьПисьма переходного периода, вложения и ошибки.
5. 5. Принять результатВывод старой системы по согласованному плану.

1. Составьте перечень ящиков, объёма, общих адресов и прав.
2. Сохраните исходные настройки и резервную копию согласно возможностям старой системы.
3. Создайте принимающую сторону и проверьте пилотный перенос.
4. Перенесите основную историю до смены MX, если это поддерживает выбранный инструмент.
5. Подготовьте клиентов, маршруты, SPF/DKIM и окно переключения. TTL снижайте заранее, учитывая старое значение и кэши.
6. Переключите MX по согласованному плану и наблюдайте обе стороны.
7. Выполните дельта-перенос новых писем и проверьте папки, даты, вложения и ошибки.
8. Проведите приёмку; только затем выводите старую систему из эксплуатации.

IMAP-перенос писем не означает перенос календарей, контактов, правил и делегирования. Для каждого типа данных нужен отдельный механизм и критерий проверки. Начальные этапы миграции показаны, например, в руководстве Яндекс 360.

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

Проверка доставки: принять сервером и увидеть в ящике — не одно и то же

Для согласованных тестов используйте свои контрольные адреса и внешних получателей, разрешивших проверку. Запишите время, отправителя, получателя и Message-ID; сопоставьте их с журналом или трассировкой сервиса.

• Внешнее письмо → персональный ящик, alias и общий адрес.
• Сотрудник → внешний адрес с проверкой From, SPF, DKIM и DMARC в заголовках получателя.
• Письмо из 1С, сайта, CRM и каждого отдельного отправляющего сервиса.
• Ответ от общего адреса с правами нужного сотрудника.
• Неизвестный адрес, заполненный ящик, недоступный получатель и обработка возврата.
• Вложения, кириллица, подпись и мобильное приложение — на согласованных примерах.

SMTP-ответ 250 после передачи сообщения подтверждает его принятие соответствующим сервером, но не гарантирует папку Inbox и прочтение. Временный отказ 4xx и окончательный 5xx требуют разной обработки. Основная модель SMTP — в RFC 5321.

Смотрите Authentication-Results, добавленный доверенной системой получателя, а не любой похожий заголовок внутри письма. Отдельно проверяйте карантин и правила: «отправка завершилась» в приложении не означает «бухгалтер получил счёт».

Спам-рейтинг письма: это оценка фильтра, а не универсальная отметка качества

У письма нет единого «рейтинга доставки», который одинаково видят все почтовые системы. Различайте балл конкретного сообщения, репутацию домена/IP отправителя и итоговое действие получателя: принять, поместить в спам, отправить в карантин или отклонить.

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

X-Spam-Status: Yes, score=6.4 required=5.0

В этом примере оценка 6,4 превысила порог 5,0. Это не 64% вероятности спама и не порог, обязательный для всех систем. Смотрите список сработавших правил и фактическое действие шлюза. Параметры описаны в SpamAssassin: scoring options.

В Microsoft 365 встречается SCL, но его нельзя напрямую приравнивать к баллам SpamAssassin. Более того, актуальная документация Microsoft предупреждает: в облаке один SCL не определяет окончательную категорию и действие. Разбирайте также verdict, категорию CAT, политики и трассировку сообщения.

Спуфинг: письмо выглядит знакомым, но отправитель может быть подменён

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

• Подставили знакомое имя: в интерфейсе видно «Генеральный директор», а полный адрес относится к чужому домену.
• Подделали точный домен From: проверяйте аутентификацию и alignment; SPF pass постороннего envelope-домена недостаточно.
• Использовали домен-двойник: у него могут успешно проходить собственные SPF/DKIM/DMARC. Проверка не доказывает, что это ваш контрагент.
• Изменили Reply-To: ответ уйдёт на другой адрес. Отличие бывает легальным, например у сервисов обращений, поэтому это повод проверить контекст, а не единственное доказательство атаки.
• Взломали настоящий ящик: техническая аутентификация может пройти; нужны анализ входов, правил пересылки, сессий и действий.

Учебный пример: сотрудник видит имя руководителя, но при раскрытии карточки отправителя обнаруживает адрес на example.org вместо согласованного домена компании. Даже безупречная подпись этого чужого домена не делает требование срочного платежа подлинным.

SPF, DKIM и DMARC помогают защищать доменную идентичность; дополняйте их антифишингом, MFA и контролем доступа. Для изменения платёжных реквизитов используйте отдельное подтверждение по заранее известному каналу, а не по телефону или ссылке из подозрительного письма. Подходы к подмене From и комплексной оценке описаны в руководстве Microsoft по anti-spoofing.

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

1. Сохраните исходное сообщение: полный EML/заголовки, время, Message-ID, отправителя и адресата. Скриншот темы не заменяет технические данные.
2. Найдите место решения: очередь отправителя, ответ принимающего SMTP, карантин шлюза или папка «Спам» в ящике.
3. Проверьте доверенные Authentication-Results: SPF, DKIM и DMARC с нужными доменами. Заголовок, вставленный самим отправителем, не является доказательством проверки.
4. Разберите фильтр: балл и сработавшие правила либо категорию/политику облачного сервиса. Не все сервисы раскрывают числовую оценку.
5. Проверьте легальный источник: IP, домен, PTR там, где он применим, разрешённый From, ссылки, вложения, объём отправки и жалобы.
6. Сравните конкретные маршруты: письмо сотрудника, отправка из 1С и рассылка сайта могут идти разными путями.
7. Исправьте причину и повторите согласованный тест: подтвердите не только SMTP-приём, но и конечную папку у получателя.

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

Не отключайте антиспам целиком и не разрешайте весь домен по одному отображаемому From. Если исключение действительно необходимо, ограничьте его проверяемыми признаками, владельцем и сроком, затем наблюдайте результат. Общие требования крупных получателей приведены в Gmail sender guidelines; правила поведения при подозрительных письмах — в справке Gmail.

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

Три прикладных ситуации после запуска

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

После запуска: сопровождение, защита и восстановление

• Контролируйте оплату домена, сервиса и свободное место.
• Проверяйте административные входы, подозрительные пересылки и новые приложения.
• Держите перечень отправляющих систем и актуализируйте SPF/DKIM при изменениях.
• Организуйте выдачу и отзыв прав, MFA и аварийный доступ.
• Заранее выясните срок и глубину восстановления удалённых сообщений.
• Отдельно определите резервирование и проверку восстановления критичной переписки.

Копии и retention у провайдера не обязательно заменяют независимый backup в вашей модели рисков. Антиспам и DMARC также не заменяют обучение сотрудников и контроль взломанного ящика. Расширенный обзор — системы защиты почты.

Два документа для запуска почты

Поможем запустить почту и поддерживать её работу

Частые вопросы