Postfix multi‑instance: отдельные очереди и исходящие IP для управляемой доставляемости

Когда одного экземпляра Postfix становится мало — например, нужно разделить исходящий трафик по клиентам, доменам или типам писем, — на помощь приходит multi‑instance. Несколько инстансов Postfix на одной машине дают независимые очереди, логи, параметры отдачи, собственные smtp_helo_name и — что критично — привязку к разным исходящим IP. Это помогает изолировать репутацию, прогревать новые адреса, выдерживать требования крупных провайдеров и реализовать разные политики для транзакционного и маркетингового трафика.

Зачем поднимать Postfix multi‑instance

Ключевые преимущества отдельного инстанса вместо монолитного MTA:

• Изоляция очередей: задержки, ретраи и «замусоривание» одного потока не тянут за собой остальные.
• Разные исходящие IP: независимая репутация, постепенный прогрев, гибкая смена адресов при деградации deliverability.
• Пер‑инстансовые политики: иные лимиты на конкарренси и скорость, другие smtp_tls_* настройки, отдельные smtp_helo_name и myhostname.
• Удобная маршрутизация: можно отправлять письма в нужный инстанс по отправителю, домену или типу контента (через transport_maps или sender_dependent_relayhost_maps).
• Управляемые окна обслуживания: перезапуск/релоад одного инстанса не трогает остальные.

Multi‑instance — не «серебряная пуля». Deliverability по‑прежнему зависит от валидной DNS‑зоны, SPF/DKIM/DMARC, PTR и аккуратных объёмов. Но архитектурно вы получаете инструмент тонкой сегментации, без которой масштабировать outbound сложно.

Архитектура: варианты раскладки

Вариант A: отдельные публичные IP с приёмом и отдачей

Каждый инстанс слушает свой публичный IP на порту 25/587, принимает входящие (если нужно) и отправляет исходящие, используя тот же IP через smtp_bind_address и (при наличии IPv6) smtp_bind_address6. Для каждого инстанса задаются свои myhostname и smtp_helo_name, соответствующие обратным PTR.

Вариант B: outbound‑инстансы только для отдачи

Один «внешний» инстанс принимает почту (25/587/465), а несколько «внутренних» работают только на отправку, слушая локальные порты (например, 127.0.0.1:2525, 127.0.0.1:2526). Главный инстанс маршрутизирует исходящие в нужный outbound‑инстанс по домену или отправителю. Публичные IP привязаны к outbound‑инстансам через smtp_bind_address. Такая схема часто удобнее: упрощается брандмауэр, логика безопасности и масштабирование. Если нужны дополнительные адреса и ресурсы — чаще всего удобнее сразу развернуть отправку на VDS с выделенными IP.

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

Планирование IP и DNS

• На каждый outbound‑инстанс выделяйте отдельный FQDN. Обычно это что‑то вроде mx-out1.example.com, mx-out2.example.com.
• PTR должен указывать на FQDN инстанса, а smtp_helo_name — совпадать с PTR. Несоответствия — быстрый триггер для фильтров.
• При наличии IPv6 не забывайте smtp_bind_address6 и AAAA/PTR для него.
• Разделите домены (SPF, DKIM, DMARC) так, чтобы каждая «линия» отправки (транзакционная, рассылки) имела понятную идентичность.

Если домена ещё нет, пригодится регистрация доменов и делегирование зоны. Для сложных зон с разными ответами по сетям может пригодиться подход с split‑horizon — см. материал Split‑horizon в BIND: практические сценарии. DNSSEC повышает доверие к зоне и корректность записей — подробнее в статье Ротация KSK/ZSK в DNSSEC.

Подготовка окружения

Ниже пример для Debian/Ubuntu (systemd). Предполагается, что Postfix уже установлен и базовый инстанс работает. Покажем схему с одним входящим инстансом и двумя outbound‑инстансами (loopback‑порт, привязка к своим исходящим IP).

Директории и включение multi‑instance

# создать конфигурации дополнительных инстансов
sudo mkdir -p /etc/postfix-out1 /etc/postfix-out2

# объявить их в базовом инстансе
echo "multi_instance_directories = /etc/postfix-out1 /etc/postfix-out2" | sudo tee -a /etc/postfix/main.cf

# скопировать стартовую конфигурацию
tar -C /etc/postfix -cf - . | sudo tar -C /etc/postfix-out1 -xvf -
tar -C /etc/postfix -cf - . | sudo tar -C /etc/postfix-out2 -xvf -

# отдельные очереди
sudo mkdir -p /var/spool/postfix-out1 /var/spool/postfix-out2
sudo chown -R postfix:postfix /var/spool/postfix-out1 /var/spool/postfix-out2

# базовый инстанс перечитает main.cf
sudo postfix reload

В каждом дополнительном каталоге пропишем уникальные параметры. Начнём с /etc/postfix-out1/main.cf:

# обязательные путевые настройки
queue_directory = /var/spool/postfix-out1
command_directory = /usr/sbin
daemon_directory = /usr/lib/postfix
config_directory = /etc/postfix-out1
multi_instance_name = out1

# слушаем только loopback, приём только от локального MTA
inet_interfaces = 127.0.0.1

# исходящая привязка к своему IP
smtp_bind_address = 203.0.113.10
# при наличии IPv6
# smtp_bind_address6 = 2001:db8::10

# идентичность и HELO
your_domain = example.com
myhostname = mx-out1.${your_domain}
smtp_helo_name = mx-out1.${your_domain}

# политика TLS (пример)
smtp_tls_security_level = may
smtp_tls_loglevel = 1

# базовые лимиты (примерные пресеты для тёплого IP)
smtp_destination_concurrency_limit = 10
smtp_destination_rate_delay = 1s
anvil_rate_time_unit = 60s

# логи с понятным префиксом
syslog_name = postfix/out1

И аналогично для /etc/postfix-out2/main.cf (своё имя, очередь, IP и FQDN):

queue_directory = /var/spool/postfix-out2
command_directory = /usr/sbin
daemon_directory = /usr/lib/postfix
config_directory = /etc/postfix-out2
multi_instance_name = out2
inet_interfaces = 127.0.0.1
smtp_bind_address = 203.0.113.11
myhostname = mx-out2.example.com
smtp_helo_name = mx-out2.example.com
smtp_tls_security_level = may
smtp_tls_loglevel = 1
smtp_destination_concurrency_limit = 10
smtp_destination_rate_delay = 1s
syslog_name = postfix/out2

Минимальный master.cf для outbound‑инстанса

Чтобы принять письма от входящего инстанса, откроем внутренний порт и не будем слушать публичный. В /etc/postfix-out1/master.cf добавим строку для локальной точки входа и оставим стандартные сервисы очереди:

# локальный SMTP только на loopback
127.0.0.1:2525 inet n - n - - smtpd
  -o syslog_name=postfix/out1-2525
  -o smtpd_discard_ehlo_keywords=chunking
  -o receive_override_options=no_header_body_checks

pickup    fifo  n       -       y       60      1       pickup
cleanup   unix  n       -       y       -       0       cleanup
qmgr      unix  n       -       n       300     1       qmgr
rewrite   unix  -       -       y       -       -       trivial-rewrite
bounce    unix  -       -       y       -       0       bounce
scache    unix  -       -       y       -       1       scache
smtp      unix  -       -       y       -       -       smtp

Аналогично в /etc/postfix-out2/master.cf, но с портом 2526:

127.0.0.1:2526 inet n - n - - smtpd
  -o syslog_name=postfix/out2-2526

pickup    fifo  n - y 60 1 pickup
cleanup   unix  n - y - 0 cleanup
qmgr      unix  n - n 300 1 qmgr
smtp      unix  - - y - - smtp

Старт дополнительных инстансов

# запустить с указанием каталога конфигурации
sudo postfix -c /etc/postfix-out1 set-permissions
sudo postfix -c /etc/postfix-out1 start

sudo postfix -c /etc/postfix-out2 set-permissions
sudo postfix -c /etc/postfix-out2 start

# проверить список (postmulti покажет все)
sudo postmulti -l

Если postmulti ещё не включён, убедитесь, что в базовом main.cf задан multi_instance_directories, затем используйте postmulti -l и postmulti -i out1 -x reload для управления. Управление через postfix -c тоже валидно.

Маршрутизация из входящего инстанса в outbound‑инстансы

Есть два паттерна, оба рабочие:

1) transport_maps по домену назначения

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

# /etc/postfix/transport
example.org     smtp:[127.0.0.1]:2525
marketing.tld   smtp:[127.0.0.1]:2526

# скомпилировать и включить
postmap /etc/postfix/transport
echo "transport_maps = hash:/etc/postfix/transport" | sudo tee -a /etc/postfix/main.cf
sudo postfix reload

Так письма на адреса домена example.org уйдут в инстанс out1, а на marketing.tld — в out2.

2) sender_dependent_relayhost_maps по отправителю

Если разделение нужно по отправителю (клиенту/сервису), используем:

# /etc/postfix/sender_relay
noreply@example.com    [127.0.0.1]:2525
*@billing.example.com  [127.0.0.1]:2526

postmap /etc/postfix/sender_relay
echo "sender_dependent_relayhost_maps = hash:/etc/postfix/sender_relay" | sudo tee -a /etc/postfix/main.cf
sudo postfix reload

Комбинировать оба подхода можно через правила приоритета и чёткую политику.

Политики и лимиты: управляем скорость и параллелизм

В multi‑instance логично задавать разные профили:

• Прогрев IP: консервативные конкарренси и задержки, например smtp_destination_concurrency_limit = 5, smtp_destination_rate_delay = 2s.
• Транзакционные: более агрессивные, но без спайков; общий лимит на домен получателя через smtp_destination_concurrency_limit и «напор» через smtp_destination_rate_delay.
• Маркетинговые: жёсткие ограничения, расписания, больший TTL очередей и аккуратные ретраи.

Полезные параметры на outbound‑инстанс:

• smtp_destination_concurrency_limit — параллелизм на домен назначения.
• default_destination_concurrency_limit — общий дефолт.
• smtp_destination_rate_delay — пауза между письмами в одном домене.
• smtp_tls_security_level, smtp_tls_policy_maps — политика TLS по доменам.
• smtp_connect_timeout, smtp_helo_timeout, smtp_tls_loglevel — диагностируем проблемы с TLS и рукопожатиями.

Для входящих сессий лимиты и фильтры задаёт smtpd_*, которые на outbound‑инстансе не играют роли, если вы принимаете только от локального MTA на loopback.

Логи и отладка

С пер‑инстансовым syslog_name в журналах сразу видно, какой поток отвечает за сообщение. Для просмотра очередей и управления ими указывайте конфиг‑каталог:

# просмотр очереди
postqueue -c /etc/postfix-out1 -p
postqueue -c /etc/postfix-out2 -p

# повторная отправка всей очереди
postqueue -c /etc/postfix-out1 -f

# точечная очистка (пример: удалить замершие)
postsuper -c /etc/postfix-out2 -d ALL deferred

Для онлайн‑диагностики соединений полезно поднять уровень логирования TLS (smtp_tls_loglevel = 1 или 2 на время) и смотреть рукопожатия крупных провайдеров. Не забывайте возвращать настройки к штатным после отладки.

Безопасность и сеть

• Ограничьте доступ к внутренним портам (2525/2526) только с 127.0.0.1 через брандмауэр.
• Если используется NAT, убедитесь, что egress действительно идёт с нужного адреса и не переписывается SNAT, иначе теряется смысл smtp_bind_address.
• Система имен: myhostname и PTR должны совпадать; smtpd_banner у входящего инстанса должен отражать корректный FQDN.
• Ротация логов и лимиты systemd на дескрипторы/процессы для каждого инстанса — во избежание неожиданных потолков.

Надежные SSL-сертификаты

Мы предлагаем широкий спектр SSL-сертификатов от GlobalSign по самым низким ценам. Поможем с покупкой и установкой SSL бесплатно!

Подробнее

Обслуживание и обновления

# перезапуск одного инстанса
postfix -c /etc/postfix-out1 reload

# через postmulti на всех сразу
postmulti -x reload

# список всех инстансов и их статус
postmulti -l

Обновления Postfix обычно затрагивают все инстансы одновременно (общие бинарники), но перезапуски удобнее проводить пошагово: сначала менее критичные, наблюдать метрики, затем — остальные.

Тонкие места и типовые ошибки

• Одинаковый HELO: два разных IP с одинаковым smtp_helo_name и несовпадающим PTR — частая причина баллов в спам‑фильтрах.
• Смешанные очереди: не забывайте уникальные queue_directory на каждом инстансе, иначе конфликт файлов и непредсказуемое поведение.
• Слишком агрессивные лимиты: высокий конкарренси на «холодном» IP даёт всплески 421/451. Начинайте осторожно, наращивайте постепенно.
• NAT и egress: если гейтвей делает SNAT, получатель увидит не тот IP, к которому вы привязываетесь. Проверяйте трассу и iptables/nftables.
• Смешение ролей: если outbound‑инстанс начинает слушать внешний 25 порт, возможна конкуренция с входящим. Держите строгую изоляцию интерфейсов.

Расширения и дальнейшие шаги

• Пер‑инстансовые ACL/политики через внешние policy‑сервисы для гибких rate‑лимитов по доменам и провайдерам.
• Разные профили TLS: требование шифрования для транзакционных и «мягкий» режим для рассылок, где важнее доставляемость. Для MTA потребуется валидный сертификат — смотрите SSL-сертификаты.
• Тонкая маршрутизация: смешанный подход с sender_dependent_relayhost_maps, transport_maps и префиксами для «служебных» доменов.
• Мониторинг: экспорт статистики очередей и статусов в метрики, алерты на рост deferred в разрезе инстансов.

Итоги

Postfix multi‑instance — зрелый и предсказуемый способ сегментировать SMTP‑трафик. Разделяя очереди, IP и политики на уровне инстансов, вы получаете управляемый outbound: прогрев адресов без риска для основного трафика, разные профили лимитов, быструю локализацию проблем и безопасные релоды. Начните с минимальной схемы: один входящий инстанс и пара outbound‑инстансов на loopback с разными IP. Как только отработаете маршрутизацию и наблюдение, масштабирование станет просто добавлением очередного конфиг‑каталога и IP, без сложных миграций.