Корпоративная почта на домене: настройка с нуля 2026

Главная / Блог / Корпоративная почта
2 мая 2026 · Время чтения: 11 мин

Корпоративная почта на своём домене — это не просто красиво выглядящий адрес вида ivan@company.ru. Это доверие клиентов, защита от спама, контроль над перепиской сотрудников и куча других вещей, без которых нормальный бизнес сегодня просто не работает.

Зачем вообще нужна корпоративная почта на домене

Я регулярно вижу компании, которые до сих пор общаются с клиентами с адресов вида ooo.romashka@mail.ru или director.ivanov@gmail.com. Честно говоря, это убивает доверие моментально. Клиент видит такой адрес и думает: это гараж с двумя людьми или реальная компания? Даже если у вас штат 50 человек и оборот десятки миллионов — с mail.ru вы выглядите как ИП на коленке.

Но дело не только в имидже. Корпоративная почта даёт несколько конкретных технических преимуществ. Во-первых, вы контролируете все ящики — уволили сотрудника, закрыли его ящик, переадресовали письма. С gmail так не сделаешь. Во-вторых, нормально настроенная корпоративная почта с SPF, DKIM и DMARC куда реже попадает в спам, чем бесплатные сервисы. В-третьих, вы можете настроить общие ящики типа info@, support@, sales@ и маршрутизировать письма между отделами.

У меня был клиент — небольшое юридическое бюро, 8 человек. Они работали на yandex.ru-почтах с рабочими названиями. Когда один из партнёров ушёл, выяснилось, что вся переписка с ключевыми клиентами велась с его личного ящика, к которому компания не имеет доступа. Потеряли часть контактной базы. После этого случая я настроил им корпоративную почту за один день — и больше таких историй не было.

⚠️
Важно: Если сотрудники ведут деловую переписку с личных ящиков — вы теряете контроль над коммуникациями компании. При увольнении или конфликте эта переписка уходит вместе с человеком. Корпоративный ящик на вашем домене всегда остаётся в вашем распоряжении.

Выбор платформы: что использовать в 2026 году

Вариантов несколько, и у каждого своя ниша. Я разберу основные, с которыми сам работал.

Яндекс 360 для бизнеса

Самый популярный выбор для небольших российских компаний. Бесплатный тариф позволяет подключить до 5 пользователей, платные тарифы стартуют примерно от 159 рублей в месяц за пользователя. Интерфейс знакомый, мобильные приложения работают нормально, интеграция с Яндекс.Диском и Яндекс.Телемостом из коробки. Для малого бизнеса — однозначно стоит рассмотреть в первую очередь.

Google Workspace

Gmail с вашим доменом. Стоит от $6 за пользователя в месяц, оплата в валюте — это сейчас минус для многих российских компаний. Зато если ваши клиенты или партнёры работают с Google Meet, Google Docs, Google Drive — интеграция идеальная. По моему опыту, IT-компании и стартапы, которые работают с международными клиентами, выбирают именно Google Workspace.

Microsoft 365

Outlook + Exchange Online. Тариф Business Basic — $6 за пользователя в месяц. Если в компании уже используется Windows, Teams, Office — это логичный выбор. Настройка чуть сложнее, чем у Яндекса, но зато возможности корпоративного уровня: общие календари, делегирование доступа к ящикам, архивирование переписки.

Собственный почтовый сервер

Postfix + Dovecot на своём VPS. Это вариант для тех, кто хочет полный контроль и готов за него платить временем и экспертизой. Я настраивал такое для нескольких клиентов с жёсткими требованиями к конфиденциальности. Грубо говоря — если вы не готовы разбираться в MX-записях, DKIM-ключах и настройке антиспама вручную, забудьте про этот вариант. Облачные решения в 99% случаев лучше.

Mailcow или iRedMail

Готовые Docker-сборки почтового сервера. Mailcow — мой фаворит среди self-hosted решений. Поднимается на VPS от 2 ГБ RAM, имеет нормальный веб-интерфейс, SOGo для работы с почтой через браузер, встроенный антиспам на базе rspamd. Если клиент настаивает на своём сервере — я рекомендую именно Mailcow.

💡
Совет: Для компаний до 50 человек я рекомендую Яндекс 360 или Google Workspace. Не тратьте время на настройку собственного сервера — облако дешевле и надёжнее, когда считаешь полную стоимость владения с учётом времени на поддержку.

DNS-настройка: MX, SPF, DKIM, DMARC

Вот здесь большинство людей и спотыкается. Выбрать платформу — это полдела. Настроить DNS так, чтобы почта нормально доставлялась и не попадала в спам — это уже техническая работа. Я подробно разбирал все эти записи в статье Настройка почты для сайта: SPF, DKIM, DMARC, здесь дам выжимку с примерами.

MX-записи

MX (Mail Exchanger) — это запись в DNS, которая говорит всему интернету: "письма для этого домена отправляйте вот на этот сервер". Без неё почта просто не будет приходить. Для Яндекс 360 MX-записи выглядят так:

@ MX 10 mx.yandex.net.

Для Google Workspace нужно добавить несколько записей с разными приоритетами:

@ MX 1  aspmx.l.google.com.
@ MX 5  alt1.aspmx.l.google.com.
@ MX 5  alt2.aspmx.l.google.com.
@ MX 10 alt3.aspmx.l.google.com.
@ MX 10 alt4.aspmx.l.google.com.

Число после MX — это приоритет. Чем меньше число, тем выше приоритет. Если основной сервер недоступен, письмо пойдёт на следующий по приоритету. Это резервирование на уровне DNS.

SPF-запись

SPF (Sender Policy Framework) — говорит принимающим серверам, какие IP-адреса имеют право отправлять почту от имени вашего домена. Если письмо пришло с IP, которого нет в SPF — это сигнал спама. Для Яндекс 360:

@ TXT "v=spf1 include:_spf.yandex.net ~all"

Если вы используете несколько сервисов для отправки почты (например, основная почта на Яндексе, а транзакционные письма с сайта идут через SendGrid), SPF нужно объединить:

@ TXT "v=spf1 include:_spf.yandex.net include:sendgrid.net ~all"

Внимание: в домене может быть только одна SPF-запись. Если добавить две — они будут конфликтовать, и почта начнёт попадать в спам. Я видел такое несколько раз, когда к уже настроенной почте добавляли рассылочный сервис и создавали вторую TXT-запись вместо того, чтобы объединить её с существующей.

DKIM-подпись

DKIM (DomainKeys Identified Mail) — криптографическая подпись, которая подтверждает, что письмо действительно отправлено с вашего домена и не было изменено в пути. Каждый почтовый провайдер генерирует пару ключей — публичный публикуется в DNS, приватный хранится на почтовом сервере.

Для Яндекс 360 публичный DKIM-ключ выглядит примерно так в DNS:

mail._domainkey TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC5N..."

Конкретное значение ключа генерирует сам провайдер — вы его просто копируете из панели управления и вставляете в DNS. Длинные ключи (2048 бит) иногда приходится разбивать на две строки, потому что некоторые DNS-провайдеры ограничивают длину TXT-записи 255 символами. Это отдельный квест, который я однажды решал 40 минут, пока не разобрался в чём проблема.

DMARC-политика

DMARC (Domain-based Message Authentication, Reporting and Conformance) — это политика, которая говорит принимающим серверам, что делать с письмами, которые не прошли проверку SPF или DKIM. Минимальная запись для начала:

_dmarc TXT "v=DMARC1; p=none; rua=mailto:dmarc@company.ru"

Здесь p=none — политика мониторинга, письма доставляются, но вы получаете отчёты. Когда убедитесь, что всё настроено правильно, меняете на p=quarantine (подозрительные письма идут в спам) или p=reject (подозрительные письма отклоняются). Я всегда начинаю с none, жду 2-3 недели, смотрю отчёты, и только потом ужесточаю политику.

Пошаговая настройка на примере Яндекс 360

Разберём конкретный процесс на самом популярном в России варианте. Поехали по шагам.

Первый шаг — регистрация в Яндекс 360 для бизнеса. Заходите на 360.yandex.ru/business, регистрируетесь, добавляете домен. Яндекс попросит подтвердить владение доменом — можно через HTML-файл на сайте, через мета-тег или через TXT-запись в DNS. Я обычно использую TXT-запись — это работает даже если на домене пока нет сайта.

Второй шаг — после подтверждения домена меняете MX-записи. Это самый ответственный момент: если на домене уже работает почта (например, на хостинге), после изменения MX новые письма пойдут на Яндекс. Старые письма на хостинге останутся там. Поэтому сначала экспортируйте всё важное.

Третий шаг — добавляете SPF и DKIM в DNS. DKIM-ключ берёте в разделе "DNS" панели Яндекс 360. Там же есть удобная проверка — Яндекс сам скажет, правильно ли добавлены записи.

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

Пятый шаг — настраиваете почтовые клиенты. Для Thunderbird, Outlook или Apple Mail нужны параметры IMAP/SMTP. Для Яндекс 360:

IMAP-сервер: imap.yandex.ru, порт 993, SSL
SMTP-сервер: smtp.yandex.ru, порт 465, SSL
Логин: полный адрес почты (ivan@company.ru)
Пароль: пароль приложения (не основной пароль аккаунта!)

Обратите внимание на пароль приложения — это отдельный пароль, который генерируется в настройках безопасности Яндекс-аккаунта. Если у пользователя включена двухфакторная аутентификация, почтовый клиент не примет основной пароль. Только пароль приложения. Я всегда включаю двухфакторку для корпоративных ящиков — это базовая безопасность. Кстати, про двухфакторную аутентификацию в целом я писал отдельно: Двухфакторная аутентификация на сайте: настройка 2026.

Настройка отправки почты с сайта через корпоративный домен

Это отдельная история, которую часто упускают. У вас есть корпоративная почта — отлично. Но ваш сайт на WordPress или Битрикс всё равно отправляет письма через локальный sendmail или через какой-то дефолтный SMTP. И эти письма попадают в спам, потому что их IP не авторизован в SPF.

Правильное решение — настроить отправку писем с сайта через SMTP вашего почтового провайдера. Для PHP это выглядит так через PHPMailer:

<?php
use PHPMailer\PHPMailer\PHPMailer;
use PHPMailer\PHPMailer\SMTP;

$mail = new PHPMailer(true);

// Настройки SMTP для Яндекс 360
$mail->isSMTP();
$mail->Host       = 'smtp.yandex.ru';
$mail->SMTPAuth   = true;
$mail->Username   = 'noreply@company.ru';
$mail->Password   = 'пароль_приложения'; // Пароль приложения, не основной!
$mail->SMTPSecure = PHPMailer::ENCRYPTION_SMTPS;
$mail->Port       = 465;
$mail->CharSet    = 'UTF-8';

// Отправитель и получатель
$mail->setFrom('noreply@company.ru', 'Компания Ромашка');
$mail->addAddress('client@example.com', 'Иван Иванов');

// Содержимое
$mail->isHTML(true);
$mail->Subject = 'Ваш заказ #12345';
$mail->Body    = '<h1>Спасибо за заказ!</h1><p>Мы уже его обрабатываем.</p>';

$mail->send();

Для WordPress я обычно использую плагин WP Mail SMTP — он делает то же самое через удобный интерфейс, без написания кода. Главное — не используйте "маилер" хостинга, если хостинг не находится на IP, прописанном в вашем SPF. Иначе письма будут улетать в спам. По опыту — это причина #1 почему письма с сайтов не доходят до получателей.

Если у вас Битрикс, настройка SMTP делается в разделе "Настройки → Почтовые события → Почтовые сервисы". Там же можно настроить разные SMTP для разных типов писем — транзакционные через один сервис, маркетинговые через другой. Я обычно транзакционные (уведомления о заказах, сброс пароля) отправляю через SMTP корпоративного домена, а массовые рассылки — через отдельный ESP типа UniSender или Sendsay.

ℹ️
Про разделение потоков: Транзакционные и маркетинговые письма лучше отправлять с разных доменов или субдоменов. Например, транзакционные с noreply@company.ru, а рассылки с news@mail.company.ru. Тогда если рассылка получит жалобы на спам, это не убьёт репутацию основного домена.

Безопасность корпоративной почты

Корпоративная почта — цель номер один для атак. Фишинг, перехват сессий, брутфорс паролей — всё это реально. Я видел, как взломанный ящик директора использовался для отправки фишинговых писем контрагентам от его имени. Ущерб — потеря нескольких клиентов и несколько часов стресса.

Минимальный набор мер безопасности, который я настраиваю всегда:

Отдельно про фишинг. Настроенный DMARC с политикой reject защищает ваших клиентов и партнёров от поддельных писем якобы от вашего домена. Если мошенник попытается отправить письмо с адресом director@company.ru с чужого сервера — принимающий сервер его отклонит. Это реально работает. Подробнее о защите сайта и инфраструктуры — в статье Как защитить сайт от взлома: 10 правил безопасности.

Миграция со старых ящиков: как перенести историю переписки

Это самый болезненный этап при переходе на корпоративную почту. Сотрудники не хотят терять старую переписку, которая годами копилась на gmail или mail.ru.

Хорошая новость: большинство корпоративных платформ умеют импортировать почту. Google Workspace, например, имеет инструмент Data Migration Service — вы подключаете к нему исходные ящики по IMAP, и он постепенно переносит все письма. Процесс может занять несколько дней для больших ящиков, но работает в фоне и не мешает работе.

Для Яндекс 360 прямого инструмента миграции нет, но можно использовать Thunderbird с плагином ImportExportTools NG: экспортируете письма из старого ящика в формат MBOX, импортируете в новый. Немного дольше и ручнее, но работает.

Ещё один вариант — imapsync. Это консольная утилита, которая синхронизирует содержимое двух IMAP-ящиков. Я использовал её для переноса нескольких десятков ящиков при миграции клиента с хостинговой почты на Google Workspace:

imapsync \
  --host1 mail.old-host.ru \
  --user1 ivan@company.ru \
  --password1 'старый_пароль' \
  --host2 imap.gmail.com \
  --user2 ivan@company.ru \
  --password2 'пароль_приложения_google' \
  --ssl1 --ssl2 \
  --port1 993 --port2 993 \
  --automap \
  --exclude 'Spam' \
  --exclude 'Trash'

Ключи --exclude исключают папки со спамом и корзиной — их переносить не нужно. Флаг --automap автоматически сопоставляет папки между серверами (например, "Отправленные" и "Sent" — это одно и то же). Утилита показывает прогресс в реальном времени и логирует все операции.

Важный момент при миграции: не отключайте старые ящики сразу. Дайте переходный период 2-4 недели, когда письма идут на новые адреса, но на старых стоит автоответ с новым адресом и, желательно, пересылка. Это даёт время всем контрагентам обновить контакты.

Общие ящики, алиасы и маршрутизация писем

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

Алиасы (псевдонимы)

Алиас — это дополнительный адрес, который приходит в тот же ящик. Например, ceo@company.ru и director@company.ru оба приходят к одному человеку. Или info@company.ru, hello@company.ru, contact@company.ru — все в один ящик. Настраивается в 2 клика в любой корпоративной системе.

Общие ящики (shared mailboxes)

Ящик support@company.ru, к которому имеют доступ все сотрудники поддержки. Каждый видит всю переписку, может ответить от имени support@. Это куда лучше, чем пересылать письма вручную. В Google Workspace это реализуется через делегирование доступа. В Microsoft 365 — через Shared Mailbox. В Яндекс 360 — через общую почту с несколькими пользователями.

Группы рассылки

Письмо на sales@company.ru приходит сразу всем менеджерам по продажам. Никто не пропустит важный запрос. Настраивается как группа/рассылочный список в административной панели.

По опыту — правильно настроенные общие ящики и алиасы снимают кучу вопросов типа "а кто должен ответить на это письмо?". У одного клиента из строительной сферы я настроил такую схему: входящие на info@ автоматически распределяются по категориям через фильтры (ключевые слова в теме), и разные категории попадают в разные общие ящики — для проектного отдела, для снабжения, для бухгалтерии. Человеческий фактор в маршрутизации полностью исключён.

Проверка и диагностика: убеждаемся что всё работает

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

Инструменты, которые я использую постоянно:

Ещё один тест, который я всегда делаю — отправляю письмо с нового корпоративного ящика на gmail.com и смотрю заголовки полученного письма (в Gmail: "Показать оригинал"). В заголовках должно быть dkim=pass, spf=pass, dmarc=pass. Если что-то из этого fail — ищем проблему в соответствующей записи DNS.

Распространённые проблемы, с которыми я сталкивался:

Кстати, вопросы доставляемости почты тесно связаны с SSL-сертификатами и общей репутацией домена. Если у вашего сайта нет HTTPS — это дополнительный минус для репутации. Почитайте про SSL-сертификаты если ещё не разобрались с этой темой.

Стоимость и бюджет: сколько это реально стоит

Давайте с цифрами. Для компании из 10 человек в 2026 году:

Если хотите, чтобы всё настроил специалист — могу помочь в рамках поддержки Битрикс или поддержки WordPress. Настройка корпоративной почты с нуля для малой компании занимает у меня обычно 2-4 часа вместе с проверками.

Есть ещё скрытые затраты, которые часто забывают считать: время сотрудников на переход (обучение новому интерфейсу, настройка клиентов на всех устройствах), возможный простой почты во время переключения MX-записей (обычно 30-60 минут, но бывает и больше), и поддержка — если что-то сломается через месяц, кто будет разбираться?

По опыту, для большинства небольших российских компаний Яндекс 360 — оптимальный баланс цены, функций и простоты. Google Workspace выбирайте если работаете с международными клиентами или уже глубоко в экосистеме Google. Microsoft 365 — если у вас Windows-инфраструктура и активно используется Office.

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

Нужна помощь с настройкой корпоративной почты?

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

П
Павел
Веб-разработчик · 10+ лет опыта · Bitrix, WordPress, Laravel

Читайте также

Настройка автоматического резервного копирования сайтов 2026 → Настройка лимитов памяти PHP и MySQL на сайте в 2026 году → Как выбрать хостинг для сайта: на что обратить внимание →