Почтовый сервер для транзакционных писем: рабочие приёмы

Интернет-магазин может отправить письмо о заказе за миллисекунды, но это не означает, что клиент его получит. Для транзакционной почты нужны отдельный адрес отправителя, корректные SPF и DKIM, понятная политика DMARC, очередь повторных попыток и мониторинг отказов. Ниже — практическая схема для Postfix 3.8+ и приложений, которым важна доставка писем, а не сам факт вызова SMTP.

Сначала выберите схему доставки

У транзакционной почты есть три рабочих варианта. Они отличаются не столько скоростью, сколько ответственностью за репутацию IP-адреса, настройку DNS и обработку отказов.

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

Надёжная отправка — это не SMTP-ответ 250 от соседнего сервера, а управляемый путь от события в приложении до финального статуса доставки.

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

Отделите письмо от бизнес-запроса

Приложение не должно ждать, пока удалённый SMTP-сервер примет сообщение. Если отправка выполняется внутри HTTP-запроса, временный сетевой сбой превращается в ошибку оформления заказа, а медленный сервер увеличивает время ответа пользователю.

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

• Сохраняйте уникальный идентификатор события и не создавайте новое письмо при каждом повторе запроса.
• Разделяйте типы писем: пароль, заказ, чек и системное предупреждение не должны использовать одну и ту же логику приоритета.
• Записывайте время постановки в очередь, время передачи, SMTP-код и причину окончательного отказа.
• Не отправляйте пароль и секретные данные в теле письма. Для сброса пароля используйте одноразовую ссылку с ограниченным сроком действия.

Настройте Postfix как исходящий релей

Ниже приведён фрагмент для Postfix 3.8+ при отправке через SMTP-провайдера на порту 587. Названия параметров стабильны, но пути к сертификатному хранилищу и расположение файлов отличаются между Debian, Ubuntu, RHEL и производными системами.

relayhost = [smtp.example.net]:587
smtp_tls_security_level = encrypt
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous

Квадратные скобки вокруг имени реле отключают поиск MX для этого узла. Это важно: Postfix должен подключаться именно к SMTP-провайдеру, а не искать почтовый сервер домена.

Файл с учётными данными должен быть доступен только пользователю и группе Postfix. В примере ниже нет настоящего пароля; замените заглушку значением из панели провайдера и не добавляйте файл в Git.

[smtp.example.net]:587 YOUR_API_KEY

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

postmap /etc/postfix/sasl_passwd
postfix check
postfix reload

Проверка пройдена, если postfix check не выводит ошибок, а тестовое письмо появляется в очереди или в журнале с ответом SMTP-реле. Не считайте письмо доставленным только потому, что команда завершилась без ошибки: окончательный результат нужно проверить по журналу и по фактическому ящику получателя.

Соберите DNS-политику, а не набор записей

SPF, DKIM и DMARC решают разные задачи. SPF проверяет разрешённые серверы для envelope-from, DKIM подписывает содержимое письма, а DMARC связывает результат проверки с доменом в видимом поле From.

SPF

Опубликуйте одну TXT-запись SPF для домена отправителя. В ней должны быть только реальные источники отправки: SMTP-релей, ваш сервер или механизм, который рекомендует провайдер. Две независимые SPF-записи для одного домена — ошибка, а не резервный вариант: получатели могут считать SPF недействительным.

DKIM

Подпись должна создаваться на вашем Postfix или у SMTP-провайдера. Если письмо проходит через несколько систем, заранее определите, где оно подписывается и не изменяется ли после этого. Подпись проверяют по публичному ключу в DNS; имя селектора и точное значение записи берите из конфигурации выбранного инструмента, а не копируйте из случайного примера.

DMARC

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

Не смешивайте адреса отправителя

Для транзакционных писем используйте отдельный поддомен, например notify.example.org, а не тот же домен, с которого идут маркетинговые кампании. Это упрощает анализ репутации и позволяет отдельно менять DNS-политику.

Поле From должно быть понятным человеку, а envelope-from — доступным для обработки возвратов. Ответы пользователей можно направлять через Reply-To, но это не заменяет отдельный адрес для отказов. Обязательно обрабатывайте коды 4xx и 5xx: временный отказ требует повторной попытки, постоянный — удаления адреса или расследования причины.

Что ломается на практике

• Письма уходят в спам. Проверьте SPF, DKIM и DMARC именно для фактического домена From, а не только для домена SMTP-провайдера. Затем посмотрите содержимое письма: массовые ссылки, вложения и несуществующий адрес ответа ухудшают результат даже при правильном DNS.
• В журнале появляется timeout. Проверьте исходящие соединения на порт 587, DNS и правила сетевого экрана. Не увеличивайте тайм-аут бесконечно: письмо должно остаться в очереди и получить следующую попытку.
• Провайдер отвечает authentication failed. Проверьте формат имени узла с портом в карте паролей, права на файл и то, разрешён ли SMTP-доступ для этой учётной записи. После изменения карты снова запустите postmap.
• Письмо дублируется. Обычно приложение повторяет бизнес-запрос после тайм-аута, не зная, успело ли первое сообщение попасть в очередь. Добавьте идемпотентный идентификатор события и храните его статус.
• После изменения DNS всё ещё старое поведение. Учитывайте TTL и кэширование DNS. Проверяйте записи с нескольких резолверов и не меняйте сразу SPF, DKIM и DMARC: иначе невозможно понять, какая правка помогла.

Когда выбирать прямую доставку

Прямой исходящий Postfix даёт контроль над очередью и не привязывает систему к API провайдера. Но IP-адрес становится вашей зоной ответственности: нужны PTR-запись, корректный HELO, TLS, DKIM, обработка жалоб, мониторинг блокировок и постепенный рост объёма. У облачного SMTP-реле меньше инфраструктурной работы, зато есть лимиты, стоимость и зависимость от политики поставщика.

Критерий простой: если отказ почты не должен останавливать продукт, выбирайте релей и инвестируйте в наблюдаемость. Если у вас стабильный большой поток, выделенная инфраструктура и команда, которая умеет вести репутацию IP, прямой Postfix может быть оправдан.

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

Сначала отправьте тестовые письма на несколько почтовых провайдеров и сохраните заголовки. Затем проверьте выравнивание доменов SPF, DKIM и DMARC, измерьте долю временных и постоянных отказов, а также возраст самого старого сообщения в очереди. На проде полезнее всего следить не за числом отправленных писем, а за временем до передачи, долей 4xx/5xx и количеством повторов. Инвалидация и очистка старых сообщений — отдельная тема; здесь важнее не оставлять очередь без владельца.

¹ Envelope-from — технический адрес SMTP-конверта, который используется серверами для возвратов и служебных уведомлений. Он может отличаться от адреса, который получатель видит в поле From.