Собственный почтовый сервер: как развернуть почту компании за 8 шагов

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

Собственный почтовый сервер складывается из трёх обязательных компонентов: MTA (агент передачи сообщений), MDA (агент доставки) и службы, отвечающей за доступ по POP3 либо IMAP. Разворачивается такая конструкция на своей или арендованной машине, обладающей постоянным публичным адресом; далее её привязывают к домену и дополняют набором записей — A, MX, PTR, SPF, DKIM, DMARC.

Если вас интересует, как сделать свой почтовый сервер, то создание почтового сервера с нуля стартует с подготовки домена и площадки, тогда как настройка почтового сервера сводится к установке программной части. Последовательность действий такова: 

1. Домен и площадка;
2. Установка программной части (Postfix с Dovecot либо готовая сборка вроде Mailcow или iRedMail);
3. Сертификаты TLS;
4. Записи в DNS;
5. Ящики;
6. Фильтрация нежелательной корреспонденции;
7. Резервные копии;
8. Проверка доставляемости.

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

Что такое почтовый сервер и из чего он состоит

За приём электронной почты, её хранение и передачу между доменами отвечает сервер электронной почты — комплекс взаимодействующих служб, или служба почты-mail в пользовательской терминологии. Здесь важно не смешивать серверную часть с клиентской: клиент (Outlook, Thunderbird, мобильное приложение) запущен на устройстве пользователя, тогда как сервер круглосуточно доступен из сети и одновременно обслуживает всех сотрудников. Для изолированных систем локальная почта может работать без внешнего обмена.

Разберём, какие элементы образуют этот стек:

• MTA (Mail Transfer Agent) — получает сообщения по SMTP, а затем передаёт их дальше по маршруту;
• MDA (Mail Delivery Agent) — раскладывает поступившую корреспонденцию по ящикам, задействуя пользовательские фильтры;
• MUA (Mail User Agent) — программа на стороне сотрудника, в том числе email-клиент;
• служба IMAP/POP3 — предоставляет клиенту доступ к сохранённым сообщениям, POP в их числе;
• антиспам и антивирус — анализируют поступающий поток, отсекая вредоносные вложения;
• веб-интерфейс — позволяет работать с корреспонденцией из браузера без установки программ;
• база учётных записей — хранит псевдонимы, адреса, домены, пароли и квоты, что является ключевой частью эксплуатации.

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

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

Логика доставки одинакова для любой платформы. Понимание маршрута экономит часы при разборе инцидентов.

Маршрут выглядит так:

1. Клиент отправителя передаёт сообщение своему MTA по SMTP с обязательной аутентификацией;
2. MTA запрашивает у DNS запись MX домена получателя и определяет принимающий узел;
3. Сообщение передаётся между узлами по SMTP, попутно проверяются подписи и репутация;
4. Принимающая сторона отдаёт корреспонденцию агенту доставки, тот кладёт её в нужный ящик;
5. Адресат забирает сообщение клиентом по IMAP или POP3 либо открывает через браузер.

Если принимающая сторона недоступна или временно отвечает отказом, сообщение остаётся в очереди. MTA повторяет попытки по нарастающему интервалу и через несколько суток возвращает отправителю уведомление о неудаче. Растущая очередь — первый признак проблемы: закончилось место на диске, перестал работать DNS, адресат внёс отправителя в блокировку.

Протоколы SMTP, IMAP и POP3: чем отличаются и какие порты использовать

Протокол SMTP (СМТП) отвечает за отправку и передачу между узлами, IMAP и POP3 — за получение. Разница между двумя последними принципиальна: IMAP оставляет данные на стороне сервиса и синхронизирует папки между устройствами, POP3 скачивает корреспонденцию на одно устройство и в зависимости от настроек клиента может удалить копию на сервере.

Сводка по назначению и портам:

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

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

Уточняйте политику по 25-му порту до оплаты площадки. Часть недорогих провайдеров не открывает его даже по обращению в поддержку, и почта работает только на приём.

Что писать в полях «сервер входящей» и «сервер исходящей почты»

Оба поля обычно заполняются одинаковым именем вида mail.домен.ru. Это имя должно иметь A-запись в DNS и совпадать с именем в TLS-сертификате, иначе клиент выдаст предупреждение о недоверенном соединении.

При ручной настройке понадобится указать:

• Имя узла для входящих — mail.домен.ru, протокол IMAP;
• Имя узла для исходящих — SMTP, адрес тот же самый;
• Порты: чтение через 993, отправка через 587 либо 465;
• Тип шифрования — SSL/TLS или STARTTLS, что зависит от выбранного порта;
• Способ проверки подлинности — обычный пароль, передаваемый поверх шифрованного канала;
• Логин — не короткое имя, а полный адрес вместе с доменной частью.

Кому и зачем нужен собственный почтовый сервер

Формируют спрос на подобные проекты несколько сценариев:

• Первый связан с внутренними регламентами и требованиями службы безопасности: переписку с персональными данными приходится хранить в контролируемом контуре либо в заданной юрисдикции, а конкретные обязательства определяются статусом компании, целями обработки и применимыми нормами. Локализация при сборе персональных данных граждан РФ предусмотрена частью 5 статьи 18 152-ФЗ, однако форму владения инфраструктурой она не задаёт — норма касается расположения базы данных.
• Второй сценарий — адреса на корпоративном домене и единые правила хранения. Третий — интеграции: CRM-системы, кадровые и учётные системы отправляют уведомления через внутренний SMTP без внешних лимитов.

С 1 июля 2025 года правило стало строже: при сборе персональных данных граждан РФ в общем случае нельзя использовать базы данных за пределами страны для записи, систематизации, хранения, уточнения и извлечения. Минцифры разъяснило, что требование относится к операторам, которые собирают такие данные. Поэтому при выборе облачной площадки проверяют расположение базы и условия обработки, а не только факт аренды сервера.

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

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

Плюсы и минусы своего почтового сервера

Ещё до закупки оборудования обе стороны вопроса разумно оценить одновременно.

От читателей нередко звучит опасение, что письма начнут попадать в спам. На это сам факт размещения почты у себя не влияет. Определяющими оказываются четыре фактора: корректная обратная запись PTR, настроенные SPF и DKIM, чистая история адреса и адекватный объём отправки. Стоит провалить любой из них — и корреспонденция действительно уходит в нежелательную папку.

Варианты размещения: свой сервер в офисе, VPS, выделенный сервер, облако

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

Ниже сопоставлены четыре варианта.

Домашний почтовый сервер для внешней переписки обычно не подходит. Бытовые каналы часто работают через NAT, адрес может меняться, обратная запись зависит от провайдера, а исходящий порт 25 нередко ограничен. Результат предсказуем: корреспонденция либо не уходит, либо отклоняется принимающей стороной. Почтовый сервер в локальной сети — другой случай: если система обслуживает уведомления оборудования, промышленных установок или изолированного корпоративного контура без выхода наружу, локальный почтовый сервер полностью оправдан. Такая схема применяется на производственных предприятиях, в учреждениях с закрытым сегментом сети и в тестовых средах разработки; собственно, это отдельное отделение инфраструктуры, которое можно обслуживать локально.

Что подготовить до установки

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

Минимальный чек-лист готовности:

• доменное имя вместе с доступом к панели управления его зоной;
• статический публичный адрес, для которого можно прописать обратную запись;
• подтверждённое провайдером открытие требуемых портов: обмен между доменами идёт через 25, отправка клиентами — через 465 и 587, для IMAP нужны 143 и 993, при использовании POP3 — 110 и 995, а веб-интерфейс и выпуск сертификатов требуют 80 и 443;
• операционная система: Ubuntu Server, Debian или отечественный дистрибутив из реестра;
• корректное полное имя узла вида mail.домен.ru;
• синхронизация времени через ntp или chrony;
• сертификат TLS, выпущенный на это имя.

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

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

Как рассчитать ресурсы сервера

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

Дисковое пространство считают по формуле: число ящиков × средний объём × коэффициент запаса 1,3–1,5 на индексы и служебные данные. Для 300 ящиков по 20 ГБ это около 8–9 ТБ полезного места.

Учтите: антивирусный модуль и фильтр нежелательной корреспонденции потребляют память заметнее, чем сама доставка. При 8 ГБ на среднем объёме потока первым начинает тормозить именно антиспам.

Выбор программного обеспечения

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

Отбирать поставщика удобно по формальным критериям:

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

Открытые компоненты: Postfix, Exim, Dovecot и обвязка

Ручная сборка даёт максимум гибкости и требует максимум внимания. Логика конфигурации у двух популярных агентов различается: Postfix описывается набором параметров в main.cf и master.cf и ведёт себя предсказуемо, Exim строится на цепочках маршрутизаторов и транспортов, что позволяет описать сложные сценарии, но повышает порог входа. В отдельных конфигурациях дополнительно используется smtpd как демон, принимающий SMTP-соединения.

Типовой набор компонентов выглядит так:

• Postfix или Exim — приём и передача корреспонденции по SMTP;
• Dovecot — локальная доставка в ящики, а также доступ по IMAP и POP3;
• Rspamd — оценка сообщений и подпись DKIM; SpamAssassin — оценка сообщений;
• ClamAV — проверка вложений на вредоносный код;
• Sieve (Pigeonhole) — серверные правила фильтрации: переадресация, автоответ при отсутствии, автоматическая раскладка писем по папкам;
• Roundcube или RainLoop — работа с корреспонденцией из браузера через веб-интерфейс;
• PostfixAdmin — панель для управления псевдонимами, ящиками и доменами;
• MySQL, PostgreSQL или LDAP — здесь хранятся учётные данные.

Готовые сборки: Mailcow, iRedMail, Mailu, Mail-in-a-Box

Сборки автоматизируют то же самое: позволяют устанавливать агент передачи, службу доступа, фильтры, веб-почту и выпускать сертификаты. Платой за удобство становится меньшая гибкость — вы принимаете архитектуру проекта целиком, а нестандартные доработки делаются сложнее. Решения на Docker Compose дополнительно изолируют каждый компонент в отдельный контейнер: обновление стека выполняется одной командой без ручной правки конфигурационных файлов, а при аварии или переезде на новое железо воспроизвести конфигурацию можно за считаные минуты.

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

Коммерческие и отечественные решения для организаций

Долгое время отраслевым стандартом для корпоративной среды был Microsoft Exchange с его календарями, общими папками и связкой с Active Directory. 4 марта 2022 года Microsoft объявила о приостановке новых продаж продуктов и услуг в России.

На российском рынке доступно несколько платформ корпоративного класса:

• RuPost — решение группы «Астра», ориентированное на замену Exchange, с поддержкой почтовых клиентов и каталогов;
• TEGU — отечественная платформа с веб-интерфейсом, календарями и адресной книгой;
• «МойОфис Почта» — серверная часть коммуникационной платформы вендора, поставляется в составе продуктовых наборов;
• CommuniGate Pro — зрелая платформа с почтой, календарями и средствами связи;
• Zimbra — исторически популярная система совместной работы, поставки и поддержка в России зависят от актуального партнёра; условия поставки нужно проверять отдельно.

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

Пошаговое развёртывание почтового сервера

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

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

Шаг 1. Подготовка операционной системы

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

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

• 25 — пересылка корреспонденции между доменами;
• 465 и 587 — отправка на стороне клиентов;
• 143 и 993 — доступ по IMAP;
• 110 и 995 — доступ по POP3, если он вам нужен;
• 80 и 443 — веб-интерфейс, а также выпуск сертификатов.

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

Шаг 2. Настройка DNS-записей домена

Без корректной зоны корреспонденция не придёт и не уйдёт. Минимальный набор описан в таблице.

Для исходящей почты к этой зоне добавляют TXT-записи DKIM и DMARC: DKIM публикует открытый ключ домена, а DMARC задаёт политику для сообщений, не прошедших проверку SPF и DKIM, и собирает отчёты. Такой набор используется при настройке доменной почты; конкретные значения зависят от сервиса, который отправляет корреспонденцию.

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

Шаг 3. Установка и базовая конфигурация MTA

При установке Postfix мастер предложит выбрать тип конфигурации: для узла, работающего с внешним миром, подходит вариант Internet Site. В файле main.cf задаются myhostname (имя узла), mydomain (домен), mydestination (домены локальной доставки), ограничения на пересылку и предельный размер сообщения. Эти параметры можно делать частью шаблона, чтобы не повторять ручную настройку для каждого домена.

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

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

Шаг 4. Хранение писем и доступ по IMAP/POP3

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

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

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

Шаг 5. Сертификаты и шифрование соединений

Самоподписанный сертификат годится только для проверки конфигурации: клиенты будут ругаться, а часть мобильных приложений просто откажется подключаться. В эксплуатации используют бесплатный сертификат Let’s Encrypt с автоматическим продлением или коммерческий, если этого требует политика организации.

Шифрование включается в двух режимах: STARTTLS поверх обычного подключения (порты 587 и 143) и неявный TLS сразу при соединении (465 и 993). Самая частая эксплуатационная авария — истёкший сертификат: продление сломалось, никто не заметил, и клиенты перестают подключаться. Ставьте на срок действия отдельную проверку в мониторинге.

Шаг 6. Создание доменов, ящиков и алиасов

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

На этом же этапе задаются рабочие правила:

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

Шаг 7. Подключение почтовых клиентов и веб-почты

Пользователям доступны два пути: браузерный интерфейс по адресу вида https://mail.домен.ru и привычные приложения на компьютере (в пользовательских запросах — «комп») или телефоне. Автонастройку обеспечивают механизмы autodiscover — прежде всего в Outlook и решениях Microsoft/Exchange — и autoconfig в Thunderbird: при наличии нужных записей сотруднику достаточно ввести адрес и пароль, остальные параметры клиент определяет самостоятельно. Для autodiscover нужна запись CNAME для поддомена autodiscover.домен.ru, указывающая на ваш узел; для autoconfig — аналогичная запись CNAME для autoconfig.домен.ru. Готовые сборки настраивают эти маршруты автоматически; при ручной сборке их добавляют отдельно.

Типовые параметры для ручного ввода приведены ниже.

Шаг 8. Проверка работоспособности и тестовые отправки

Тестировать нужно оба направления и обязательно на внешних адресатах: внутренняя переписка проходит мимо большинства проверок и создаёт ложное ощущение готовности.

Что стоит проверить до ввода в эксплуатацию:

• отправку и приём внутри домена;
• отправку на крупные публичные сервисы и получение ответа от них;
• журналы на предмет ошибок доставки и отказов аутентификации;
• состояние очереди — она должна быть пустой в спокойном режиме;
• корректность записей через mxtoolbox и оценку сообщения через mail-tester;
• подключение клиента с телефона по мобильной сети, а не только из офиса;
• внешним тестом — что открытой пересылки нет.

Доставляемость: SPF, DKIM, DMARC и репутация отправителя

Три механизма дают ответ, когда принимающая сторона спрашивает, действительно ли домен ваш. SPF (Sender Policy Framework) размещает в зоне список адресов, которым разрешено отправлять от имени домена. DKIM (DomainKeys Identified Mail) сопровождает каждое сообщение криптографической подписью, а открытый ключ помещают в отдельную запись. DMARC (Domain-based Message Authentication, Reporting and Conformance) объединяет результаты обеих проверок, задаёт политику для несовпадений и собирает отчёты.

Порядок внедрения обычно такой: сперва SPF, следом DKIM, а DMARC подключают после того, как все легитимные отправители проверены. На старте последний держат в режиме наблюдения (p=none) с адресом для отчётов — так вы увидите, кто ещё отправляет от вашего имени, и не потеряете легитимные уведомления из CRM или биллинга. После периода наблюдения и анализа данных политику ужесточают до карантина, затем до отклонения. Фиксированный срок в две-три недели здесь не универсален: переход зависит от полноты отчётов и количества легитимных источников отправки.

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

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

Скажем честно: даже безупречная техническая настройка не гарантирует попадание во «Входящие» у крупных публичных провайдеров. Их алгоритмы учитывают поведение получателей, и на это администратор влияет лишь косвенно.

Безопасность почтового сервера

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

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

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

Риск не теоретический: отчёт «Лаборатории Касперского» показывает, что за девять месяцев 2025 года почтовыми киберугрозами столкнулись 81% российских компаний. В III квартале количество детектов атак шифровальщиками через корпоративную почту выросло на 45% год к году.

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

Проверять одни лишь заголовки и репутацию отправителя уже мало: как сообщила BI.Zone Mail Security, за 2025 год фишинговые письма злоумышленники рассылали втрое чаще против прошлого периода, поток нежелательной корреспонденции прибавил 46%, а вредоносного ПО — 15,6%. Вот почему фильтру стоит разбирать не только SPF и DKIM, но и само содержание письма.

Через год показатели поднялись ещё выше: по сведениям BI.ZONE Mail Security, за первое полугодие 2026 года на фишинг пришлось 90% нелегитимного почтового трафика — против 80,7% годом ранее. Спуфинг сократился на 49%, вредоносные вложения — на 44,4%, тогда как доля фишинга прибавила 11,6%. Как показывает подобное распределение, технические средства защиты полезно дополнять обучением сотрудников и разбором признаков социальной инженерии.

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

Минимальный мониторинг охватывает четыре метрики:

• длина очереди (растущая очередь — сигнал нарушения в доставке);
• свободное место на диске (почтовые данные растут непрерывно);
• срок действия TLS-сертификата (просроченный сертификат отключает всех клиентов одновременно);
• доступность служб снаружи.

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

Для организаций с требованиями к контролю утечек важен и исходящий поток: корпоративная почта оставалась одним из главных каналов утечки информации в 2025 году — её доля составила 23% по данным Solar JSOC. При миграции отдельно проверяют совместимость почтовой платформы с DLP и сохранение видимости трафика.

Резервное копирование и восстановление

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

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

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

Миграция почты с облачного сервиса на свой сервер

Перенос делается заранее и параллельно работе людей, а не в ночь переключения. Содержимое ящиков копируется по IMAP утилитой imapsync или аналогом: сообщения именно копируются, поэтому процесс можно повторять несколько раз.

Порядок этапов:

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

Риски известны заранее: облачные сервисы ограничивают скорость выгрузки, крупные ящики переносятся долго, часть структуры папок может исказиться. Календари и контакты по IMAP не передаются — их выгружают отдельно в форматах ICS и vCard. Забытый высокий TTL — причина того, что часть корреспонденции сутки уходит на старую площадку, поэтому уменьшайте его заблаговременно.

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

Сколько это стоит и когда выгоднее облако

Затраты складываются из инфраструктуры и труда. Облачная подписка растёт линейно от числа сотрудников, собственная система — ступенчато, при исчерпании ресурсов площадки. Инфраструктурную часть сметы мы обычно собираем по нашим обзорам IaaS-провайдеров: там сведены условия по виртуальным машинам, дисковому пространству, выделенным адресам и объектным хранилищам для резервных копий — то есть все строки таблицы ниже, кроме лицензий и часов инженера.

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

В расчётах, которые мы видим в обсуждениях с читателями, чаще всего забывают именно поддержку. Инфраструктуру считают аккуратно, а сопровождение записывают в «сделаем силами своих», хотя это регулярные часы конкретного специалиста.

Типичные ошибки при запуске собственной почты

Набор проблем повторяется из проекта в проект. Проверьте себя по списку до, а не после запуска:

• отсутствие обратной записи PTR — отклонение сообщений крупными провайдерами;
• открытая пересылка — попадание в списки блокировки за несколько часов;
• самоподписанный сертификат в эксплуатации — предупреждения и отказы клиентов;
• пропущенная подпись DKIM — падение доставляемости на деловой переписке;
• единственная копия данных на той же машине — полная потеря при отказе диска;
• бытовой канал с меняющимся адресом — блокировка на стороне получателей;
• отсутствие контроля очереди — проблема замечается только по жалобам сотрудников;
• слабые пароли пользователей — компрометация и рассылка от имени домена;
• смешивание массовых рассылок с корпоративной перепиской — испорченная репутация домена;
• непроверенное восстановление из копий — обнаружение неработающего процесса в момент аварии.

Половина пунктов относится к эксплуатации, а не к установке. Это ещё раз подтверждает: запуск — самая простая часть проекта.

Когда собственный сервер не нужен: альтернативы

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

Рабочие альтернативы:

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

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

Частые вопросы о собственном почтовом сервере (FAQ)

Ниже — короткие ответы на то, что осталось за рамками разделов, включая вопросы о создании почтового сервера и настройке почтового сервера.

Как узнать, какой узел обслуживает домен?

Запросите запись MX командой dig MX домен.ru или через любой веб-сервис проверки DNS. В ответе будет имя принимающего узла и его приоритет.

Можно ли поднять свой почтовый сервер на Windows?

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

Сколько ящиков выдержит одна машина?

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

Нужен ли отдельный домен для почты?

Нет, обычно используется основной домен компании, а узел получает поддомен вида mail. Отдельный домен или поддомен имеет смысл выделять под массовые рассылки.

Можно ли задействовать чужой SMTP при своём домене?

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

Нужен ли веб-интерфейс обязательно?

Формально нет: почта доступна через клиенты по протоколам IMAP, POP3 и SMTP. Из браузера с ним работать удобно, однако без него сотрудники по-прежнему пользуются настроенными приложениями.

Что такое личный почтовый сервер и нужен ли он?

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

Заключение

Главное, что мы считаем нужным подчеркнуть: собственная почта — это не разовая установка, а постоянная эксплуатация. Решение принимается по двум критериям: требования к месту хранения данных и наличие администратора, готового отвечать за очередь, обновления и резервные копии. Цена в этом списке стоит третьей, и сама по себе редко перевешивает.

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