Почтовый сервер для нескольких доменов: архитектура и затраты

Вы обслуживаете на одном почтовом сервере 30 клиентских доменов. Каждому нужны свои MX, ключ DKIM, запись SPF, политика DMARC, правила карантина и контроль репутации отправителя. Вопрос не в том, справится ли сервер: Postfix и Dovecot работают так уже два десятилетия. Важно другое: что произойдёт, когда рассылка одного клиента испортит репутацию общего IP-адреса.

Многодоменная архитектура подходит многим операторам. Но для тех, кто рассчитывает только на экономию по сравнению с готовым сервисом, собственный сервер может оказаться невыгодным. Разберём устройство системы, настройки разделения клиентов, три характерных сбоя изоляции и затраты, которые стоит сопоставить с тарифом вроде TrekMail Agency. Примеры конфигурации неполны и зависят от версий. Цены и возможности ниже относятся к сценарию статьи, а не гарантируют актуальные условия.

Что такое многодоменный почтовый сервер

Это единый набор компонентов, который принимает и отправляет почту нескольких доменов на общей инфраструктуре. Один экземпляр Postfix получает письма для client1.com, client2.com и client3.com; один Dovecot хранит ящики всех трёх с настроенными ограничениями доступа; общая исходящая очередь отправляет письма с DKIM-подписью соответствующего домена.

Это не совсем то же, что рекламное выражение «многодоменный почтовый хостинг»: обычно оно означает тариф, где несколько доменов добавляются в одну платёжную учётную запись. Сервер представляет собой техническую основу такого предложения, то есть реальные настройки Postfix и Dovecot. Его можно разместить на своём VPS или пользоваться провайдером вроде TrekMail Agency, который обслуживает общую платформу сам.

Три варианта архитектуры

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

Вариант 1: отдельный сервер для каждого домена

Самая простая схема: отдельный Postfix/Dovecot для каждого клиентского домена. Клиенты не делят эту почтовую систему, хотя риски общей среды виртуализации, ОС и административного доступа остаются. У каждого домена свой VPS, IP и управление репутацией. Это может подойти для 3-5 доменов, за которыми стоят самостоятельные значимые компании. При 20+ доменах обновления, мониторинг и продление сертификатов начинают почти линейно увеличивать нагрузку на администраторов.

Вариант 2: общий многодоменный сервер

Типичная схема агентства: одна связка Postfix + Dovecot обслуживает все домены через virtual_mailbox_domains, отдельные DKIM-ключи и настройки разделения клиентов в Dovecot. Администратор поддерживает одну инфраструктуру для N доменов. Ориентировочно экономический смысл может появиться около 10 доменов, а сложность стать существенной около 200. Затем часть операторов переходит на готовый сервис или распределяет домены по серверам с учётом нагрузки и репутационных рисков.

Вариант 3: готовая общая платформа, купить или построить

Поддержка собственной многодоменной почты может требовать серьёзной инженерной занятости и обходиться дороже готового тарифа. В сценарии статьи TrekMail Agency стоит $29 в месяц, или $23.25/месяц при годовой оплате, и рассчитан на 1,000 доменов с управлением DKIM, SPF/DMARC и исходящими очередями. Актуальный объём возможностей нужно проверить: очередь на учётную запись не означает отдельную очередь каждого домена или независимую IP-репутацию. Агентству не приходится настраивать Postfix, но пользователи, DNS и политики остаются его задачами. Сравнивайте годовые затраты на реально сэкономленные часы с годовой ценой сервиса; пример стоимости одного часа инженера сам по себе не устанавливает точку окупаемости.

Postfix + Dovecot: привычная связка

Для собственного сервера распространённая в 2026 связка включает Postfix для SMTP и Dovecot для IMAP, хранения и доставки через LMTP. Примеры ниже ориентированы на Debian или Ubuntu LTS. Принципы применимы и в других дистрибутивах, но пути, права и директивы следует сверять с используемыми версиями.

virtual_mailbox_domains и таблицы соответствий

Postfix поддерживает виртуальные домены через директиву virtual_mailbox_domains. Вместо списка прямо в main.cf можно использовать hash-таблицу, а при росте системы перейти на SQL или LDAP:

# /etc/postfix/main.cf
virtual_mailbox_domains = hash:/etc/postfix/vhosts
virtual_mailbox_maps    = hash:/etc/postfix/vmailbox
virtual_alias_maps      = hash:/etc/postfix/valias
virtual_transport       = lmtp:unix:private/dovecot-lmtp

В /etc/postfix/vhosts перечисляются принимаемые домены: в каждой строке домен служит ключом, за которым следует подходящее значение в формате hash-таблицы; одного имени домена недостаточно. /etc/postfix/vmailbox позволяет проверить существование виртуальных получателей. При таком транспорте LMTP значения этой таблицы сами по себе не определяют место хранения: конечный путь выбирает Dovecot. /etc/postfix/valias отвечает за псевдонимы, например info@client1.com → real-person@client1.com.

Каталоги Dovecot по доменам

Dovecot может хранить ящики в отдельных каталогах для каждого домена. Распространённая структура: /var/vmail/<domain>/<user>/. Пример настройки:

# /etc/dovecot/conf.d/10-mail.conf
mail_location = maildir:/var/vmail/%d/%n
mail_uid = vmail
mail_gid = vmail

%d обозначает доменную часть адреса, а %n локальную. Такое расположение удобно для резервного копирования и операций с отдельным клиентом: rsync может работать с конкретным каталогом. Но каталоги сами по себе не обеспечивают изоляцию. Нужно отдельно проверять права, аутентификацию, авторизацию и доступ процессов к хранилищу.

LMTP для передачи из Postfix в Dovecot

Современные системы часто используют LMTP, Local Mail Transfer Protocol, для передачи писем из Postfix в Dovecot. Это может уменьшить накладные расходы по сравнению с запуском dovecot-deliver для каждого письма и позволяет применять квоты получателей при соответствующей настройке. Dovecot должен слушать Unix-сокет, доступный Postfix с нужными правами.

SPF, DKIM и DMARC для каждого домена

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

SPF каждого домена

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

DKIM каждого домена, квартальная ротация как пример

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

Обработка отчётов DMARC

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

Три опасных сбоя разделения клиентов

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

Сбой 1: ухудшение репутации общего исходящего IP

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

Сбой 2: перегрузка общей очереди

Когда очередь Postfix растёт, например из-за многочисленных временных отказов 4xx для одного клиента, другим может не хватать общих ресурсов. Ограничения по назначениям не отменяют этой конкуренции. При 50 доменах рассылка на 500K писем может на несколько часов задержать транзакционные сообщения других клиентов, в зависимости от мощности сервера и настроенных ограничений.

Сбой 3: смешение учётных записей при аутентификации

Если база Dovecot непоследовательно учитывает домен, пользователь клиента A может сопоставиться с записью клиента B при совпадении имени. Домен должен учитываться во всей цепочке проверки. Значение auth_username_format %u, полный адрес, вместо %n, только локальная часть, может быть частью решения. Одной строки недостаточно: запросы к базе, нормализация имени, авторизация и доступ к ящику должны соблюдать те же границы. Полный перечень есть в статье о рисках многодоменного почтового хостинга.

Свой сервер или готовый сервис

Решение определяется реальной стоимостью вашего времени. Свой сервер кажется дешёвым, пока учитываются только VPS и трафик. Добавьте настройку Postfix, обращения по блокировкам, ротацию DKIM и инцидент доставки в 3 часа ночи, и сравнение изменится. Таблица показывает ориентировочные сценарии, а не универсальные пороги или коммерческие предложения.

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

Что может дать готовая многоклиентская платформа

Оцените четыре возможности: управление и журналирование ротаций DKIM по доменам; помощники SPF/DMARC с публикацией через DNS-интеграции, если они доступны и разрешены; мониторинг прогрева пула IP и репутации доменов; анализ агрегированных отчётов DMARC. Не каждый провайдер предлагает всё и в одинаковом объёме. Проверьте актуальные функции TrekMail Agency, сохраните доступ к DNS и проверяйте опубликованные записи. Готовые инструменты могут избавить от длительной разработки, но не от контроля отправителей и политик.

Сравнение многодоменных сервисов

TrekMail, Migadu и Workspace можно включить в оценку многодоменной почты, но ими рынок не ограничивается. Их модели различаются. Ниже сохранён пример статьи: 50 клиентских доменов с ~10 ящиками каждый, всего 500 ящиков. Прежде чем принимать решение, проверьте действующие цены, модель оплаты и административные границы.

Допущения таблицы дают разницу примерно в 13× относительно расчёта, приписанного Migadu, и 240× относительно Workspace. Это арифметика выбранных условий, а не проверенное сравнение текущих предложений, особенно модели Migadu. Фиксированная и поштучная оплата действительно могут сильно расходиться при росте масштаба. Но надо учитывать возможности и общую репутацию: ни одна из этих моделей сама по себе не означает выделенный IP каждому домену. Такие IP требуют управления и не гарантируют доставку. Несколько независимых доменов в одной организации Workspace также не обеспечивают автоматически нужные административные и информационные границы; проверьте владение доменами и требования каждого клиента.

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

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

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

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

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

Усиление безопасности многодоменного сервера

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

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

Ограничение исходящего потока может уменьшить ущерб от взломанного ящика, но не гарантирует сохранение IP-репутации за 20 минут. Нужны лимиты по ящику и часу, по учётной записи и дню, а также уведомления и оперативная реакция. Без ограничений украденный пароль может позволить отправить 100K спам-писем, в зависимости от ресурсов. В статье приведены примеры TrekMail: 1,000 писем на ящик в день и 6,000 на учётную запись в день для Starter, 50 отправок через SMTP в час для Nano. Сверьте актуальные значения и область применения: это ориентиры для защиты, а не гарантия от злоупотреблений.

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

Эксплуатационный чек-лист многодоменного сервера

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

Ежедневно: следите за размером очереди и отправкой каждого клиента. Рост в 10× относительно обычного уровня может означать запланированную кампанию или компрометацию; оба случая требуют проверки. Проверяйте блок-листы исходящих IP через MX Toolbox или аналогичные инструменты. Убедитесь, что ночные задания cron по ротации журналов, приёму DMARC-отчётов и резервному копированию выполнились без ошибок.

Еженедельно: просматривайте доступные DMARC-отчёты доменов. Подключение платформы рассылок, платёжного сервиса или инструмента продаж может добавить нового отправителя. Проверьте его SPF, DKIM и нужное выравнивание идентификаторов. Следите за ростом хранилища: ящик свыше 30 GB может потребовать архивирования или пересмотра ёмкости в зависимости от тарифа. Проверяйте счётчики IMAP-соединений Dovecot по клиентам: приближение к лимиту способно вызывать прерывистую синхронизацию и обращения в поддержку.

Ежеквартально: если вы выбрали такую политику, меняйте DKIM-ключи доменов. Пример последовательности: опубликовать селектор, подождать 48 часов, переключить подпись Postfix и оставить старый селектор ещё на 48 часов. Эти интервалы ничего не гарантируют сами по себе: учитывайте TTL, кеши и ещё доставляемые письма со старой подписью. Для 100 доменов статья оценивает трудозатраты в 8-12 часов за квартал, примерно 40 часов в год. Это ориентировочные оценки; автоматизацию сервиса вроде TrekMail Agency также нужно проверять и контролировать.

Ежегодно: пересматривайте процесс продления сертификатов SSL/TLS для SMTP и IMAP, используя современный TLS, а не устаревшие протоколы SSL. Не откладывайте реальные продления до годовой проверки. В статье используется пример Let's Encrypt со сроком 90 дней и автоматическим продлением; срок действия и работу автоматизации следует сверять и непрерывно отслеживать. Проверяйте резервные копии восстановлением почты одного клиента в чистом Dovecot и проводите аудит базы аутентификации. Ищите устаревшие записи, включая пользователей доменов, удалённых из Postfix, но всё ещё допускаемых к входу.

Что делать дальше

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

В сценарии статьи TrekMail Agency стоит $29 в месяц, $23.25/месяц при годовой оплате, для 1,000 доменов × 1,000 ящиков на домен с 200 GB общего хранилища почты и TrekMail Drive. Также описаны ротация DKIM, редактор Sieve, выделенная поддержка, 100 псевдонимов на ящик и загрузка 50 доменов одним CSV. Пробный период 14 дней требует карту в этом сценарии. Бесплатный Nano без карты и временного пробного периода описан для 10 доменов × 10 ящиков. Проверьте действующие цены, функции, требования и квоты, включая реальное влияние дополнения Drive на почтовое хранилище. Риски подробнее разобраны в нашем руководстве по многодоменной почте. Актуальные тарифы доступны на trekmail.net/pricing.