Корпоративный почтовый сервер принимает, отправляет и хранит письма на домене компании. Собственный сервер стоит разворачивать, когда нужны контроль над данными, особые интеграции или независимость от почтового сервиса и есть специалисты для сопровождения. Для большинства небольших компаний без такого специалиста удобнее облачная почта; для самостоятельного размещения сначала выбирают программную платформу, проверяют доступность порта 25 и возможность настройки PTR, затем рассчитывают хранилище и резервное копирование.
Что такое почтовый сервер и как он работает
Почтовые службы могут работать на физическом сервере, в виртуальной машине или на разных узлах. Их дополняют антиспам, антивирус, поиск и клиентский доступ - веб-интерфейс или IMAP\SMTP.
Путь письма: от клиента до ящика
Почтовые компоненты выполняют три роли:
- MUA — почтовый клиент: приложение или веб-интерфейс для работы с письмами.
- MTA — служба пересылки: принимает сообщения, определяет маршрут и управляет очередью.
- MDA — служба доставки: помещает письмо в ящик с учётом правил и ограничений.
В упрощённом виде, письмо на внешний домен проходит несколько этапов:
- Сотрудник подключается к серверу отправки и проходит аутентификацию.
- Сервер принимает письмо в очередь и запрашивает MX-записи домена получателя.
- MX указывает имя принимающего узла, а A или AAAA — его IP-адрес.
- Отправляющий сервер устанавливает SMTP-соединение с получателем.
- Принимающая сторона проверяет адрес, подлинность домена и признаки спама, затем сохраняет письмо в ящик.
Ответ SMTP «принято» не подтверждает попадание во «Входящие» или прочтение письма. При временной ошибке отправитель повторяет доставку из очереди; при постоянном отказе формируется уведомление о недоставке.
SMTP, IMAP и POP3: порты и шифрование
SMTP передаёт сообщения. IMAP синхронизирует письма и папки между устройствами. POP3 преимущественно используют для получения сообщений клиентом; хранение копий зависит от настроек, а возможности синхронизации ограничены, протокол считается устаревшим. Ниже приведено описание служб со стандартными портами (порты могут быть переназначены).
| Назначение | TCP-порт | Шифрование |
|---|---|---|
| SMTP между серверами, релеи | 25 | STARTTLS при поддержке сторон; строгая защита требует дополнительных политик |
| Отправка сотрудниками | 587 | STARTTLS с обязательным TLS перед передачей учётных данных |
| Отправка сотрудниками | 465 | TLS сразу при подключении |
| Доступ по IMAP | 143 / 993 | STARTTLS на 143, TLS сразу на 993 |
| Получение по POP3 | 110 / 995 | STLS на 110, TLS сразу на 995 |
Для новой системы обычно выбирают IMAP через 993 и отправку через 465 либо 587 с обязательным TLS. POP3 открывают по необходимости, веб-почту — через HTTPS на 443.
Пользовательские и межсерверные соединения различаются. Внешние серверы на порту 25 не имеют паролей вашей компании. Они должны отправлять письма вашим получателям без входа, но не использовать узел для произвольной пересылки.
Облачная почта или собственный сервер
Своя почта даёт контроль над данными, но требует навыков сопровождения, восстановления и работы с репутацией отправителя.
| Критерий | Облачная почта | Собственный сервер |
|---|---|---|
| Контроль | В пределах возможностей и договора сервиса | Над ОС, конфигурацией и размещением данных |
| Затраты | Плата за пользователей и дополнительные функции | Аренда или оборудование, лицензии, сопровождение |
| Администрирование | Управление доступом и настройками услуги | Обслуживание почты, ОС, DNS и резервных копий |
| Интеграции | Зависят от поставщика | Можно глубже связать с внутренними системами |
| Хранение в РФ | Зависит от услуги и условий обработки данных | Определяется площадками системы и её копий |
| Доставляемость | Репутацией инфраструктуры занимается поставщик | За репутацией IP и домена следит сама компания или подрядчик |
Своя почта оправданна конкретной задачей: изолированным контуром, особыми правилами архивирования или интеграциями, например со службой каталогов.
Какое ПО выбрать для почтового сервера
Фрагмент серверного оборудования в дата-центре. Фото: panumas nikhomkhai / Pexels.
Postfix, Dovecot, Exim и готовые сборки
В Linux распространена связка Postfix + Dovecot. Postfix принимает и отправляет сообщения, Dovecot предоставляет IMAP-доступ и доставляет письма в ящики через LMTP. Exim — альтернативная служба пересылки.
Дополнительные компоненты решают отдельные задачи:
- Rspamd или SpamAssassin оценивают признаки спама; Rspamd также проверяет и создаёт DKIM-подписи.
- ClamAV ищет известные вредоносные объекты во вложениях.
- Roundcube предоставляет веб-интерфейс к существующим ящикам, но не заменяет сервер.
- iRedMail и mailcow объединяют службы и упрощают первоначальное развёртывание.
Сборку устанавливают на поддерживаемую ОС, регулярно обновляют и резервируют.
Microsoft Exchange: возможности и поддержка
Exchange нужен, когда помимо почты важны общие календари, делегирование, адресные книги и интеграция с инфраструктурой Microsoft. Его требования нельзя приравнивать к небольшой установке Postfix.
Поддержка Exchange Server 2016 и 2019 завершилась 14 октября 2025 года. Для нового проекта рассматривают Subscription Edition; актуальные версии указаны в матрице поддержки Exchange Server.
Для SE нужны действующие права по подходящей подписке либо лицензии сервера и клиентского доступа с активным Software Assurance. Конкретная схема зависит от условий лицензирования. Покупка Office для каждого сотрудника не является универсальным требованием Exchange: права сервера, клиентский доступ и почтовое приложение учитываются отдельно.
Российские почтовые серверы
CommuniGate Pro объединяет почту и средства совместной работы. RuPost предлагает централизованное управление корпоративной почтой. Mailion использует микросервисную архитектуру и ориентирован в том числе на крупные внедрения.
Эти продукты представлены в реестре российского ПО; сведения о включении публикуют и разработчики. При закупке сверяют точное название, правообладателя и актуальную карточку: запись о клиенте не заменяет запись о серверной системе.
Сравнивают миграцию, интеграции и восстановление. Отечественное оборудование представлено в разделе российских серверов Сервер Молл. Совместимость оборудования с выбранным ПО определяют отдельно.
На каком железе развернуть почтовый сервер
VDS, выделенный сервер или собственная площадка
Для VDS нужны разрешённая почтовая нагрузка, постоянный публичный IP, настройка PTR и доступные порты. Важны предсказуемые задержки дисков.
Выделенный сервер даёт больше контроля над ресурсами. Собственный узел в офисе дополнительно требует устойчивого питания, охлаждения и связи; размещение в ЦОД снимает часть этих забот. При операторском NAT без подходящей схемы публикации входящие соединения работать не будут.
Почту можно разместить в виртуальной машине. При подборе серверов для виртуализации учитывают суммарную нагрузку хоста, выделяют ресурсы для пиков и предусматривают восстановление ВМ при отказе узла.
Расчёт ресурсов под число пользователей
Количество ящиков помогает оценить ёмкость, но не описывает нагрузку полностью. Важны одновременные соединения, вложения, антивирус и индексация для поиска.
В документации mailcow приведены ориентиры:
- минимум стандартной установки — 6 ГиБ памяти, 1 ГиБ подкачки и 20 ГиБ диска без писем;
- примерно для 5–10 пользователей рекомендуется 8 ГиБ памяти;
- для примера с 15 телефонами через Exchange ActiveSync и примерно 50 одновременными IMAP-соединениями — 16 ГиБ.
Это требования mailcow, а не универсальные нормы. Для роли Mailbox в Exchange SE Microsoft указывает минимально рекомендуемые 128 ГБ памяти. Потребности других систем определяют по их документации и измерениям.
Ёмкость рассчитывают отдельно. Например, 100 ящиков со средним фактическим объёмом 5 ГБ занимают около 500 ГБ. Рост на 30% даст 650 ГБ. Дополнительно нужны место под индексы, очередь, журналы и свободное пространство для обслуживания. Копии учитывают отдельно. Это пример расчёта объёма, а не конфигурация на 100 сотрудников.
Для подбора через конфигуратор серверов определяют рост переписки, поток писем, число соединений, необходимость поиска и антивируса, время восстановления.
Накопители, RAID и выбор платформы
HPE ProLiant DL380 Gen10 — пример стоечной платформы для корпоративных сервисов. Источник: HPE.
Почтовое хранилище выполняет множество небольших операций. SSD сокращают задержки; при выборе учитывают ресурс записи и защиту от потери питания. Для небольшого узла рассматривают зеркало, для интенсивной записи — RAID 10 с подходящим контроллером или программным массивом.
Очередь и хранилище при необходимости выносят на разные накопители: разделы одного массива не разделяют его производительность. Для Exchange учитывают требования к базам и журналам. RAID не восстанавливает удалённые или зашифрованные письма.
Среди стоечных серверов компактный узел можно построить на HPE ProLiant DL360 Gen10. Для большего запаса дисковых отсеков стоит сравнить HPE ProLiant DL380 Gen10. Пригодность определяется комплектацией и требованиями ПО, а не названием модели.
Различия платформ разобраны в статье Сервер Молл «HPE ProLiant DL380: сравнение поколений Gen9–Gen12».
Как поднять свой почтовый сервер
Домен, IP-адрес и доступность сети
Площадка должна разрешать входящие и исходящие соединения на TCP 25. Его часто открывают по заявке. Исходящий порт 587 не заменяет прямую доставку: он позволяет отправлять через внешний SMTP-посредник.
В примерах домен example.com, имя mail.example.com и IP 192.0.2.10 демонстрационные — их заменяют своими. В DNS в минимальной, но недостаточной конфигурации - об этом расскажем дальше - публикуют:
mail.example.com. IN A 192.0.2.10
example.com. IN MX 10 mail.example.com.
MX содержит имя с собственной адресной записью. AAAA добавляют только при работающем IPv6, включая почтовые соединения и обратную DNS-запись.
Для имени сервера выпускают доверенный TLS-сертификат с автоматическим продлением и перечитыванием службами. Домен ящика и имя сервера могут различаться.
Установка Postfix и Dovecot на Ubuntu 26.04
Ubuntu 26.04 использует Dovecot 2.4 с новым форматом конфигурации. Ниже — фрагменты для одного домена с системными пользователями Linux. Их добавляют в пакетную конфигурацию, сохраняя обязательные параметры версии и подключения файлов.
Устанавливают компоненты:
sudo apt update
sudo apt install postfix dovecot-core dovecot-imapd dovecot-lmtpd rspamd
В установщике Postfix выбирают прямую отправку через интернет и указывают почтовый домен. Базовые параметры /etc/postfix/main.cf:
myhostname = mail.example.com
mydomain = example.com
myorigin = $mydomain
inet_interfaces = all
inet_protocols = ipv4
mydestination = mydomain, localhost, $mydomain
mynetworks = 127.0.0.0/8
smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination
local_transport = lmtp:unix:private/dovecot-lmtp
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
smtpd_sasl_auth_enable = no
smtpd_tls_cert_file = /etc/letsencrypt/live/mail.example.com/fullchain.pem
smtpd_tls_key_file = /etc/letsencrypt/live/mail.example.com/privkey.pem
smtpd_tls_security_level = may
smtp_tls_security_level = may
IPv6 включают после подготовки сети и DNS. mynetworks ограничен локальным узлом: широкая доверенная сеть создаёт риск открытой ретрансляции для спама.
mydestination содержит локальный домен. Для виртуальных доменов нужна другая схема таблиц; один домен не объявляют одновременно локальным и виртуальным.
В /etc/postfix/master.cf редактируют службу submission для отправки через 587:
submission inet n - y - - smtpd
-o smtpd_tls_security_level=encrypt
-o smtpd_sasl_auth_enable=yes
-o smtpd_relay_restrictions=permit_sasl_authenticated,reject
На 587 обязательны авторизация и TLS. На 25 остаётся приём внешней почты своим получателям без пароля.
Хранение писем и аутентификация в Dovecot
В нашем примере системных пользователей Dovecot проверяет через PAM, сведения об учётных записях получает через passwd, хотя разумеется можно использовать и другие базы данных учётных записей, включая ldap. Основные настройки версии 2.4:
protocols {
imap = yes
lmtp = yes
}
mail_driver = maildir
mail_path = ~/Maildir
auth_username_format = %{user | username}
auth_allow_cleartext = no
ssl = required
ssl_server_cert_file = /etc/letsencrypt/live/mail.example.com/fullchain.pem
ssl_server_key_file = /etc/letsencrypt/live/mail.example.com/privkey.pem
passdb pam {
}
userdb passwd {
}
Здесь anna@example.com сопоставляется с системным пользователем anna. Для нескольких независимых доменов нужна база виртуальных пользователей с полными адресами.
Связь между службами обеспечивают локальные сокеты:
service lmtp {
unix_listener /var/spool/postfix/private/dovecot-lmtp {
mode = 0600
user = postfix
group = postfix
}
}
service auth {
unix_listener /var/spool/postfix/private/auth {
mode = 0660
user = postfix
group = postfix
}
}
LMTP доставляет письма, private/auth проверяет отправителей. Создают пользователей, настраивают PAM, права на каталоги и адреса postmaster и abuse. Доступ к командной оболочке пользователям почты не нужен.
Перед применением изменений проверяют синтаксис:
sudo postfix check
sudo doveconf -n
sudo systemctl restart dovecot postfix
После проверки синтаксиса проверяют вход и доставку. Отличия версий разобраны в руководстве по переходу на Dovecot 2.4.
Подключение Rspamd
Postfix передаёт сообщения Rspamd, как и другим агентам защиты, через интерфейс Milter. Если обработчик Rspamd слушает локальный порт 11332, добавляют:
smtpd_milters = inet:127.0.0.1:11332
non_smtpd_milters = $smtpd_milters
milter_protocol = 6
milter_default_action = tempfail
tempfail откладывает приём при отказе фильтра, поэтому его доступность контролируют. Порты Rspamd не публикуют в интернете. Антивирус и хранилище статистики подключают отдельно.
Microsoft Exchange
Для Exchange SE подбирают поддерживаемую Windows Server, готовят Active Directory и зависимости, устанавливают почтовые роли. Затем настраивают сертификаты, домены, соединители, базы и публикацию. Для DKIM и более гибкого антиспама может потребоваться отдельный шлюз или совместимое дополнение.
У альтернатив также проверяют ОС серверной части: наличие Windows-клиента не означает поддержку Windows Server.
SPF, DKIM, DMARC и PTR: настройка и проверка
SPF перечисляет разрешённых отправителей, DKIM подтверждает подпись письма, DMARC связывает проверку с видимым отправителем, PTR задаёт обратное соответствие IP имени. Они дополняют друг друга, но не гарантируют попадание во «Входящие». В современном мире отсутствие этих специальных записей практически гарантирует сбои при отправке почты на разные почтовые сервисы.
Как настроить SPF
Если письма отправляет только один узел, TXT-запись может выглядеть так:
example.com. IN TXT "v=spf1 ip4:192.0.2.10 -all"
-all даёт результат fail для остальных источников, ~all — более мягкий softfail. Перед строгой политикой учитывают отправку из других источников, например с сайта, CRM и сервиса рассылок. Для одного имени публикуют одну SPF-запись.
RFC 7208 ограничивает десятью число учитываемых механизмов и модификаторов, требующих DNS-поиска, включая вложенные include и redirect. Это не лимит количества IP в ip4 и ip6.
SPF проверяет домен технического адреса возврата MAIL FROM, а не просто поле «От». При пересылке меняется отправляющий IP, поэтому одного SPF недостаточно.
Как настроить DKIM
Сервер подписывает заголовки и тело письма закрытым ключом. Получатель проверяет подпись открытым ключом из DNS. DKIM не шифрует содержимое.
Ключ RSA длиной 2048 бит создают, например, средствами Rspamd:
sudo install -d -m 0750 /var/lib/rspamd/dkim
sudo rspamadm dkim_keygen -b 2048 -s mail2026 -d example.com \
-k /var/lib/rspamd/dkim/example.com.mail2026.key \
> /tmp/example.com.mail2026.txt
Публичную TXT-запись из файла .txt переносят в DNS. Закрытый .key оставляют на сервере; владельца и права каталога и ключа задают для чтения процессом Rspamd, ограничивая остальных пользователей.
В /etc/rspamd/local.d/dkim_signing.conf указывают:
domain {
example.com {
selector = "mail2026";
path = "/var/lib/rspamd/dkim/example.com.mail2026.key";
}
}
Селектор определяет имя mail2026._domainkey.example.com. В поле p= публикуют полный сгенерированный открытый ключ. Подписывают доверенную исходящую почту после входа пользователя или из явно разрешённых внутренних источников.
После sudo rspamadm configtest применяют настройки. Параметры описаны в документации Rspamd по DKIM. При ротации заранее публикуют ключ с новым селектором, затем переключают подпись. Старый открытый ключ сохраняют на время доставки ранее подписанных писем и действия кэша DNS.
Как проверить DKIM
Наличие ключа проверяют командами:
dig TXT mail2026._domainkey.example.com +short
nslookup -type=TXT mail2026._domainkey.example.com
В исходном тексте доставленного внешнему получателю письма находят DKIM-Signature: d=example.com обозначает домен, s=mail2026 — селектор. В Authentication-Results, добавленном доверенным сервером получателя, нужен результат dkim=pass. Само наличие подписи ничего не доказывает.
Причины ошибки обычно следующие:
- Ключ не найден: другой селектор или панель DNS дважды добавила домен к имени.
- Ключ не совпадает: сервер подписывает новым ключом, а DNS содержит старый.
- Повреждена TXT-запись: потеряны символы или добавлены лишние кавычки. Несколько корректных строк внутри одной TXT допустимы — они объединяются при чтении.
- Изменено письмо: шлюз или список рассылки переписал подписанные заголовки либо тело.
- Обойдена подпись: приложение отправило сообщение через другой узел.
Пересылка сохраняет DKIM, если подписанные части не изменены. Результат проверяют у нужного получателя.
Как настроить DMARC
Для успешного DMARC достаточно прошедшего SPF или DKIM с согласованием домена с видимым полем From. Подпись чужого домена сама по себе не обеспечивает dmarc=pass.
В мае 2026 года RFC 9989 заменил прежний RFC 7489. Наблюдение начинают с записи:
_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
Адрес отчётов должен существовать; для стороннего домена отчётности требуется дополнительное разрешение в DNS получателя отчётов. После разбора всех легитимных источников переходят от none к quarantine, затем к reject. Эти политики запрашивают соответственно наблюдение, обработку нарушителей как подозрительных и отказ; окончательное решение принимает получатель.
Как проверить PTR-запись
PTR настраивает владелец IP — хостер или провайдер. Обычной записи типа А в зоне домена недостаточно. Для выделенного исходящего адреса PTR указывает на mail.example.com, A-запись возвращает тот же IP, а сервер представляется этим именем в HELO/EHLO.
dig -x 192.0.2.10 +short
dig A mail.example.com +short
nslookup 192.0.2.10
Соответствие настраивают для каждого исходящего IP. PTR не заменяет SPF, DKIM и репутацию отправителя.
Безопасность и защита от спама
Защита почты включает несколько направлений:
- Шифрование. Для пользователей обязателен TLS. Межсерверную защиту усиливают политиками MTA-STS или DANE, если это предусмотрено проектом: одного STARTTLS недостаточно для гарантии шифрования.
- Защита входа. MFA включают в поддерживающих её панелях и интерфейсах. Обычный парольный вход IMAP и SMTP не получает второй фактор от настройки веб-почты.
- Ограничение доступа. Неиспользуемые службы отключают, управление закрывают VPN или доверенными сетями. Пароли администраторов отделяют от пользовательских.
- Контроль поведения. Ограничивают попытки входа и отправку, применяют fail2ban или аналог. Резкий рост исходящей почты может означать захват ящика.
- Сопровождение. Обновляют компоненты, контролируют журналы и изменения правил пересылки.
Антиспам оценивает совокупность признаков, включая содержание писем, DNS-записи и списки репутации адресов (RBL). Учитывают ложные срабатывания и, как правило, предоставляют пользователям работу с карантином. Массовые рассылки желательно отделять от обычной переписки по инфраструктуре, во избежание попадания в спам и потери репутации основным почтовым сервисам..
Отказоустойчивость и резервное копирование
Резервный MX принимает письма при недоступности основного узла и удерживает их в очереди. Он не копирует ящики и не даёт сотрудникам доступ к старой переписке. Проверка получателей и фильтрация должны быть согласованы с основным сервером, иначе запасной маршрут станет обходом защиты.
Для доступности ящиков нужна отдельная архитектура. В Exchange применяют группы доступности баз — DAG. В Dovecot CE 2.4 удалён replicator: старую схему автоматической репликации из версии 2.3 использовать нельзя. Общее хранилище требует собственного резервирования и правильной работы блокировок.
Репликация может повторить удаление или повреждение данных. Поэтому резервные копии хранят отдельно, с независимыми правами и защитой от изменения. Сохраняют письма, конфигурацию, базы учётных записей, правила и DKIM-ключи.
Частоту и срок хранения определяют допустимой потерей переписки и временем восстановления. Заранее отрабатывают возврат отдельного письма, ящика и всей системы. Снимок ВМ без согласованной процедуры не гарантирует корректность прикладных данных.
Подбор оборудования раскрыт в статье «Сервер для резервного копирования: как выбрать оборудование». Авария почтового узла не должна уничтожать одновременно его копии.
Как проверить почтовый сервер
Доступность служб и доставка
TLS проверяют без передачи пароля:
openssl s_client -connect mail.example.com:587 \
-starttls smtp -servername mail.example.com \
-verify_hostname mail.example.com -verify_return_error
openssl s_client -connect mail.example.com:993 \
-servername mail.example.com \
-verify_hostname mail.example.com -verify_return_error
Соединение позволяет оценить доступность и сертификат, но не доставляемость. Для неё отправляют письма в несколько внешних систем и обратно, разбирают ответы и заголовки. Внешний клиент без входа не должен пересылать через ваш узел письма между двумя чужими доменами.
Очередь и события смотрят командами:
postqueue -p
sudo journalctl -u postfix -u dovecot -u rspamd --since "1 hour ago"
В зависимости от настройки часть событий записывается в /var/log/mail.log. Контролируют рост очереди, свободное место, ошибки входа и сроки сертификатов. Причины задержки ищут в ответах получателя: это могут быть DNS, сеть, подпись или репутация.
Для внешней диагностики подходят такие сервисы, как mail-tester, MXToolbox и проверки IP по спискам блокировок RBL. Балл сервиса не гарантирует доставку; значение имеют правила конкретного получателя.
Как узнать адрес и IP почтового сервера
Принимающие узлы домена показывает MX:
dig MX example.com +short
nslookup -type=MX example.com
Меньшее число означает более высокий приоритет. IP узла определяют через dig A имя-сервера +short и dig AAAA имя-сервера +short. Узлов и адресов может быть несколько.
MX описывает входящую доставку. Имя IMAP или сервера отправки сотрудников может отличаться — его узнают у администратора. Для подключения используют доменное имя, соответствующее сертификату.
Частые вопросы
Для чего нужен собственный почтовый сервер?
Для контроля над данными, интеграциями и локальной обработкой сообщений. Почту на своём домене можно получить и в облаке.
Можно ли развернуть почтовый сервер на VDS?
Да, если хватает ресурсов, разрешена почтовая нагрузка, доступны постоянный IP и настройка PTR. Для прямого обмена нужен порт 25. Если ограничена исходящая доставка, возможен разрешённый SMTP-посредник; входящий маршрут проектируют отдельно.
Сколько пользователей выдержит сервер?
Это зависит от ПО, активности сотрудников, объёма ящиков, поиска, антивируса и накопителей. Конфигурацию выбирают по требованиям продукта и уточняют измерениями. Количества зарегистрированных ящиков без потока сообщений и числа соединений недостаточно.
Почему письма уходят в спам при правильном DKIM?
Получатель также учитывает DMARC, репутацию IP и домена, жалобы и содержимое. Причиной бывает посторонний источник с подписью другого домена. Разбирают заголовки конкретного письма и ответы получателя, а не только наличие ключа в DNS.
Надёжная почта требует устойчивой сети, подходящего хранилища и работающего восстановления. После установки служб нужен ответственный за сопровождение, чтобы доставка и сохранность переписки не зависели от случайных сбоев.