Как настроить отправку почты из self-hosted приложений

Какие self-hosted приложения должны отправлять почту

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

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

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

Сначала определим два термина. SMTP (simple mail transfer protocol) — это протокол, который используется на всех этапах этого процесса. Релей, также называемый smarthost, — это сервер, который принимает вашу аутентифицированную почту и доставляет ее дальше, используя свои собственные адреса и свою собственную репутацию.

Почему ваш VPS не может отправлять почту через 25 порт

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

Проверьте это с сервера:

sudo apt update && sudo apt install -y netcat-openbsd
nc -vz -w 5 gmail-smtp-in.l.google.com 25
nc -vz -w 5 smtp.relay.example 587

Если первая команда «висит» все пять секунд, в то время как вторая отвечает мгновенно, блокировка подтверждена. Некоторые провайдеры снимают её после проверки аккаунта. Большинство — нет.

Блокировка — не главная причина использовать релей. Даже с открытым 25 портом почта, отправленная напрямую с адреса нового VPS, попадает в спам или отклоняется сразу, так как у этого адреса нет истории отправки, а сам он находится в диапазоне, который получатели считают хостинговым пространством. Руководство Google для отправителей требует наличия корректных прямых и обратных DNS-записей для IP-адреса отправителя, а многие адреса VPS имеют общую PTR-запись, которую нельзя изменить. Релей предоставляет адреса, у которых уже есть история.

Порты для отправки (submission ports) — это выход. Порт 587 поддерживает STARTTLS, где сессия начинается в открытом виде и затем переходит в защищённый режим. Порт 465 использует неявный TLS (transport layer security), где сессия шифруется с первого байта. Оба порта предназначены для аутентифицированных клиентов, оба открыты в сетях VPS, и ваш релей поддерживает как минимум один из них.

Выбор релея и поддомена для отправки

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

• наличие порта для отправки, 587 или 465, с поддержкой SMTP AUTH;
• подпись DKIM с использованием вашего собственного домена и селектора, а не только домена провайдера;
• доступность данных о недоставленных письмах (bounces) и жалобах (complaints) через дашборд или вебхуки;
• тарифный план, соответствующий вашим объемам. По состоянию на август 2026 года несколько провайдеров всё ещё предоставляют возможность отправки нескольких тысяч сообщений в месяц бесплатно. Эти условия часто меняются, поэтому изучайте актуальную страницу с ценами, а не сторонние статьи.

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

Настройка реле для каждого self-hosted приложения

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

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

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

Postfix, настроенный как сателлит, — это полноценный агент передачи почты (MTA) с настоящей очередью. Он мгновенно принимает сообщение, повторяет попытки в течение нескольких дней в случае сбоя и хранит учетные данные реле в файле, доступном только пользователю root. Используйте его, если потеря уведомления во время сбоя реле критична или если несколько приложений запущены от имени разных системных пользователей.

msmtp, компактный вариант

sudo apt update
sudo apt install -y msmtp msmtp-mta ca-certificates

msmtp-mta устанавливает символическую ссылку /usr/sbin/sendmail, поэтому всё, что вызывает sendmail, попадает в msmtp, даже не подозревая о его существовании.

Создайте /etc/msmtprc:

defaults
auth            on
tls             on
tls_trust_file  /etc/ssl/certs/ca-certificates.crt
syslog          on

account         relay
host            smtp.relay.example
port            587
from            apps@notify.example.com
set_from_header on
user            <relay username>
password        <relay password>

account default : relay

set_from_header on всегда устанавливает заголовок From и перезаписывает любой существующий, поэтому он заменяет всё, что сгенерировало приложение, адресом из from. Без этого задания cron будут отправлять почту от имени root@your-hostname, а реле отклонит её, так как это не подтвержденный вами адрес. syslog on отправляет лог через syslog, поэтому вы можете прочитать его с помощью journalctl -t msmtp. Альтернатива — общий путь logfile, но он требует прав на запись для каждого пользователя, отправляющего почту, что является ловушкой на многопользовательской системе.

Установите права доступа самостоятельно. msmtp принудительно проверяет права на конфигурацию пользователя (~/.msmtprc), отказываясь работать при contains secrets and therefore must have no more than user read/write permissions. Он ничего не проверяет для /etc/msmtprc, так как просто загружает этот файл, если он доступен для чтения.

sudo chown root:root /etc/msmtprc
sudo chmod 600 /etc/msmtprc
printf 'Subject: relay test\n\nsent from the host\n' | sudo sendmail -v you@example.com

-v выводит весь SMTP-диалог, чтобы вы видели каждый ответ от реле. Успешная отправка заканчивается ответом 250 с подтверждением приема сообщения. Строка authentication failed означает, что имя пользователя или пароль неверны, либо реле ожидает API-ключ вместо пароля учетной записи.

Теперь о подвохе, из-за которого многие переходят на Postfix. При режиме 600 и владельце root отправлять почту может только root. Приложение, запущенное от имени www-data, не может прочитать файл, msmtp пропускает его, и приложение выдает ошибку о том, что учетная запись по умолчанию не найдена. Решение — группа:

sudo chgrp mail /etc/msmtprc
sudo chmod 640 /etc/msmtprc
sudo usermod -aG mail www-data

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

Postfix как сателлит

sudo debconf-set-selections <<'EOF'
postfix postfix/main_mailer_type select Satellite system
postfix postfix/mailname string notify.example.com
postfix postfix/relayhost string [smtp.relay.example]:587
EOF
sudo DEBIAN_FRONTEND=noninteractive apt install -y postfix libsasl2-modules

libsasl2-modules обязателен. Без него Postfix записывает в лог warning: SASL authentication failure: No worthy mechs found, так как библиотеки механизмов PLAIN и LOGIN не установлены в /usr/lib/sasl2.

Настройте остальное с помощью postconf -e, который редактирует /etc/postfix/main.cf на месте:

sudo postconf -e 'relayhost = [smtp.relay.example]:587'
sudo postconf -e 'smtp_sasl_auth_enable = yes'
sudo postconf -e 'smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd'
sudo postconf -e 'smtp_sasl_security_options = noanonymous'
sudo postconf -e 'smtp_tls_security_level = encrypt'
sudo postconf -e 'smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt'
sudo postconf -e 'inet_interfaces = loopback-only'

Квадратные скобки вокруг имени хоста реле запрещают Postfix искать MX-запись для этого имени и заставляют его подключаться напрямую. Некоторые хосты реле публикуют MX-записи, указывающие на другие серверы, и без скобок ваша почта уйдет не на тот сервер.

smtp_tls_security_level = encrypt делает TLS обязательным, поэтому сообщение никогда не передается в открытом виде. Он не проверяет сертификат. Документация самого Postfix прямо говорит об этом: на этом уровне доставка продолжается, даже если сертификат сервера не является доверенным или содержит неверное имя. Если вы хотите проверять сертификат, используйте verify или secure и оставьте smtp_tls_CAfile включенным.

Учетные данные хранятся в одном файле, доступном только root:

echo '[smtp.relay.example]:587 relay-username:relay-password' | sudo tee /etc/postfix/sasl_passwd
sudo chmod 600 /etc/postfix/sasl_passwd
sudo postmap hash:/etc/postfix/sasl_passwd
sudo systemctl restart postfix

postmap создает индексированную копию, которую Postfix читает на самом деле. Если вы отредактируете текстовый файл и забудете про postmap, Postfix продолжит использовать старую базу данных, и в логах не будет ничего, что могло бы вас предупредить. В Postfix 3.9 и новее типом карты по умолчанию является lmdb, поэтому пишите lmdb: как в параметре, так и в аргументе postmap, если предпочитаете этот формат. Указание типа в обеих строках позволяет им оставаться синхронизированными.

Приложения по-прежнему адресуют свою почту как root@hostname. Перепишите отправителя:

echo '/.+/    apps@notify.example.com' | sudo tee /etc/postfix/sender_canonical
sudo postconf -e 'sender_canonical_classes = envelope_sender, header_sender'
sudo postconf -e 'sender_canonical_maps = regexp:/etc/postfix/sender_canonical'
sudo systemctl reload postfix

Таблица regexp: читается напрямую, поэтому postmap не требуется. Теперь каждое сообщение уходит с одним и тем же отправителем конверта и заголовком From, что и требуется реле. Минус в том, что все ответы приходят в одно место, поэтому установите заголовок Reply-To внутри каждого приложения, если ответы должны доходить до человека.

Отправьте тестовое письмо и прочитайте лог:

printf 'Subject: postfix relay test\n\nsent through the queue\n' | sendmail you@example.com
sudo tail -n 20 /var/log/mail.log

Доставленное сообщение записывается как status=sent, за которым следует ответ самого реле в скобках. Всё остальное указывает на причину ошибки. status=deferred с Connection timed out означает, что что-то всё еще пытается использовать порт 25. Host or domain name not found. Name service error for name=smtp.relay.example type=A означает, что имя хоста реле неверно или на сервере проблемы с DNS. mailq перечисляет застрявшие сообщения, а sudo postqueue -f немедленно повторяет попытку их отправки.

Доступ к реле хоста из контейнеров Docker

Контейнер не может вызвать sendmail хоста, так как бинарный файл отсутствует в образе, а очередь не является общей. Предоставьте контейнерам сетевую цель. Postfix может прослушивать адрес моста Docker.

ip -4 addr show docker0
sudo postconf -e 'inet_interfaces = 127.0.0.1, 172.17.0.1'
sudo postconf -e 'mynetworks = 127.0.0.0/8 172.17.0.0/16'
sudo systemctl restart postfix

Узнайте адрес своего моста с помощью первой команды, вместо того чтобы копировать эту, так как проект Compose создает собственную сеть в другой подсети, а docker network inspect <name> выводит её. Используйте restart, а не reload: в документации Postfix указано, что после изменения inet_interfaces необходимо остановить и запустить службу, так как перезагрузка (reload) не применит изменения. Каждое приложение затем получает SMTP-хост 172.17.0.1, порт 25, без аутентификации и без TLS, так как этот трафик не покидает пределы хоста. Если ваши сервисы находятся в сети Compose, в разделе запуск Docker Compose на VPS описано, откуда берется эта подсеть.

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

ss -tlnp | grep ':25'

Вывод должен содержать только адрес loopback и адрес моста. С другой машины команда nc -vz your.server.ip 25 должна завершаться ошибкой.

SPF, DKIM и DMARC для домена отправителя

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

SPF (sender policy framework) определяет, кто имеет право использовать ваш домен в поле отправителя (envelope sender). Опубликуйте эту запись для поддомена, с которого ведется отправка:

notify.example.com.  IN  TXT  "v=spf1 include:_spf.relay.example -all"

Скопируйте значение include: со страницы настроек вашего реле, так как неразрешаемый include приводит к постоянной ошибке вместо успешной проверки. Проверка SPF прекращается после 10 DNS-запросов и возвращает permerror, что получатели интерпретируют как сбой, поэтому используйте минимум include. Опубликуйте ровно одну запись v=spf1 для каждого имени: наличие двух записей также является permerror.

DKIM (domainkeys identified mail) подписывает каждое сообщение закрытым ключом, который хранится на реле, а получатели запрашивают соответствующий открытый ключ через DNS. Ваш реле предоставит вам селектор и TXT-запись или CNAME для публикации:

sel1._domainkey.notify.example.com.  IN  CNAME  sel1.dkim.relay.example.

DKIM важнее, чем SPF, так как подпись DKIM сохраняется при пересылке. Когда список рассылки или правило .forward пересылают ваше сообщение, оно приходит с IP-адреса пересылающего сервера, поэтому SPF не проходит, а подпись остается валидной.

DMARC (domain-based message authentication, reporting and conformance) указывает получателям, что делать, если ни одна из проверок не подтвердилась, и запрашивает отчеты. Опубликуйте эту запись для основного домена:

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com; adkim=r; aspf=r"

Начните с p=none и анализируйте отчеты в течение двух недель. p=none не меняет доставку, а лишь включает отправку отчетов, что позволяет обнаружить системы, о которых вы забыли, и которые отправляют почту от имени вашего домена. Затем перейдите к p=quarantine, а после — к p=reject. Публикация p=reject в первый же день — это способ узнать, что ваша система выставления счетов отправляла письма от имени домена, только после того, как клиент не получил счет.

Проверяйте то, что видит внешний мир, а не то, что отображается в вашей панели управления DNS:

dig +short TXT notify.example.com
dig +short TXT sel1._domainkey.notify.example.com
dig +short TXT _dmarc.example.com

Пустой вывод означает, что запись еще не распространилась или имя указано неверно. Запись, которую вы исправили пять минут назад, может оставаться неверной в кэшах в течение времени, равного предыдущему TTL (time to live), поэтому проверяйте TTL, прежде чем делать выводы.

Синхронизация адресов From и Return-Path

Каждое сообщение содержит два адреса отправителя, которые проверяются по-разному. Адрес отправителя конверта (envelope sender) передается в команде SMTP MAIL FROM и отображается в доставленном сообщении как Return-Path. Заголовок From — это адрес, который видит получатель.

SPF проверяет домен отправителя конверта на соответствие IP-адресу, с которого пришло соединение. DKIM сообщает домен, который подписал сообщение, через тег d=. DMARC считается пройденным только в том случае, если хотя бы один из этих двух доменов совпадает с доменом в заголовке From. При мягком соответствии (adkim=r, aspf=r, что является настройкой по умолчанию) учитывается и поддомен, поэтому отправитель конверта в notify.example.com соответствует заголовку From в example.com. При строгом соответствии это не так.

Практическое правило простое: используйте один и тот же домен для заголовка From и отправителя конверта, тогда этот вопрос не возникнет. Именно это делает set_from_header on в msmtp и sender_canonical_maps в Postfix.

Проверьте вердикт в доставленном сообщении. В Gmail функция "Show original" выводит заголовки, которые зафиксировал получатель:

Authentication-Results: mx.google.com;
       dkim=pass header.i=@notify.example.com;
       spf=pass (google.com: domain of apps@notify.example.com designates 198.51.100.25 as permitted sender) smtp.mailfrom=apps@notify.example.com;
       dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=example.com

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

Отказы и жалобы до начала массовой рассылки

Отказ (bounce) — это ситуация, когда получатель отклоняет ваше сообщение. Hard bounce является постоянным, и Gmail обозначает его как 550 5.1.1 The email account that you tried to reach does not exist. Soft bounce — это временная проблема, код 4xx для переполненного почтового ящика или greylisting, при которой ретранслятор (relay) повторит попытку самостоятельно.

Ретрансляторы отслеживают уровень hard bounce и блокируют учетные записи, которые продолжают отправлять письма на несуществующие адреса, так как это типичный признак использования купленных баз. Жалобы имеют большее значение. Жалоба — это нажатие пользователем кнопки «Спам». Согласно рекомендациям Google для отправителей (проверено в августе 2026 года), отправителям следует поддерживать уровень жалоб на спам ниже 0.30% согласно данным Postmaster Tools, а рекомендуется — ниже 0.10%.

Четыре вещи, которые должны быть настроены до начала массовой рассылки:

• webhook или еженедельная проверка списка подавления (suppression list) на ретрансляторе, чтобы вы видели отказы
• адрес отправителя (From), который является реальным почтовым ящиком, где кто-то читает письма, с настроенным Reply-To для ответов
• подтверждение перед добавлением любого адреса в базу, чтобы вы никогда не отправляли письма на адрес, который владелец не вводил сам
• ограничение частоты запросов (rate limit) для любой формы, инициирующей отправку почты

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

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

Для справки: правила Gmail для массовых отправителей применяются при отправке более 5,000 сообщений в день на адреса Gmail и требуют наличия SPF, DKIM, DMARC и возможности отписки в один клик для маркетинговых писем. Большинство self-hosted приложений никогда не достигают этого порога. Однако аутентификация сейчас ожидается от любого отправителя в любом случае.

Проверка перед использованием

swaks — подходящий инструмент для этой задачи. Он использует протокол SMTP и выводит весь диалог, что позволяет увидеть, на каком этапе произошел сбой.

sudo apt install -y swaks
swaks --to you@example.com --from apps@notify.example.com --server smtp.relay.example --port 587 --tls --auth-user '<relay username>' --auth-password '<relay password>'

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

swaks --to you@example.com --from apps@notify.example.com --server 127.0.0.1

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

• отправьте письмо на сервис оценки, например mail-tester.com, который анализирует SPF, DKIM, DMARC и содержимое сообщения, предоставляя подробный отчет о полученных баллах;
• отправьте письмо на почтовые ящики двух провайдеров, которыми пользуются ваши клиенты, и изучите Authentication-Results в исходном коде сообщения;
• проанализируйте письмо через learndmarc.com, если результат проверки выравнивания (alignment) неочевиден;
• инициируйте отправку непосредственно из приложения, а не только из командной строки, так как именно приложение формирует заголовок From.

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

FAQ

Почему на моем VPS заблокирован исходящий порт 25?

Почти все провайдеры блокируют исходящий TCP-порт 25 по умолчанию, так как скомпрометированный сервер с открытым портом может рассылать спам напрямую на почтовые серверы получателей. Пакеты отбрасываются, а не отклоняются, поэтому симптомом является зависание соединения с последующим таймаутом, а не сообщение об ошибке. Проверьте это, выполнив nc -vz -w 5 gmail-smtp-in.l.google.com 25 рядом с nc -vz -w 5 smtp.relay.example 587: первая команда будет ожидать ответа, вторая ответит мгновенно. Решение заключается не в просьбе снять блокировку. Отправляйте почту через релей на порту 587 или 465, которые остаются открытыми и предназначены для аутентифицированных клиентов.

Нужны ли мне SPF, DKIM и DMARC только для отправки нескольких уведомлений от приложения?

Да, и объем отправки здесь не играет роли. Получатели применяют одни и те же проверки как к одному письму со сбросом пароля, так и к рассылке из пятидесяти тысяч сообщений. Без SPF и DKIM ваша почта не аутентифицирована, а текущие требования Google к отправителям обязывают использовать хотя бы один из этих механизмов. Без DMARC вы не получите отчетов, поэтому первым признаком проблемы станет жалоба пользователя на то, что письмо со ссылкой для сброса пароля не пришло. Все три записи являются DNS-записями, они бесплатны, а их публикация занимает около десяти минут.

Что использовать в качестве клиента-релея: msmtp или Postfix?

Используйте msmtp, если сервером управляет один человек и потеря сообщения во время сбоя релея допустима. Это один файл конфигурации без демона, и поскольку он не использует очередь, недоступность релея означает потерю сообщения. Используйте Postfix в режиме satellite, если вам нужна очередь с повторными попытками доставки в течение нескольких дней или если на сервере работают несколько приложений от разных системных пользователей. Postfix хранит пароль от релея в файле, доступном только пользователю root, который приложения не читают, в то время как конфигурация msmtp должна быть доступна для чтения каждому пользователю, отправляющему почту.

Почему почта моего приложения отклоняется из-за того, что она отправлена от root?

Cron-задачи и многие приложения формируют адрес отправителя на основе локального имени пользователя и имени хоста, создавая что-то вроде root@srv1.localdomain. Это не тот адрес, который вы подтвердили на релее, поэтому релей отклоняет сообщение с ответом 553 или 554, указывающим на адрес отправителя. Исправьте это на уровне хоста, а не в каждом приложении: используйте set_from_header on вместе с адресом from в /etc/msmtprc или sender_canonical_maps с sender_canonical_classes = envelope_sender, header_sender в Postfix. Установите Reply-To внутри каждого приложения, если ответы должны доходить до человека.

Действительно ли отдельный поддомен для почты приложения защищает мой основной домен?

Отчасти, и это все равно стоит делать. Получатели отслеживают репутацию для каждого домена, поэтому жалобы на notify.example.com в основном остаются привязанными к notify.example.com, в то время как ваш основной домен продолжает доставлять почту. Ограничение реально: некоторые получатели суммируют сигналы поддоменов до уровня основного домена, а политика DMARC, опубликованная на уровне организации, применяется к поддоменам, если вы не установите sp= отдельно. Рассматривайте поддомен как способ ограничения ущерба, а не как гарантию.