Como enviar correio de apps autoalojadas sem servidor SMTP

Que aplicações autoalojadas precisam de enviar correio

Para enviar correio a partir de aplicações autoalojadas, não precisa de um servidor de correio. Precisa de um relay: uma conta SMTP autenticada, configurada uma vez no host, à qual todas as aplicações do servidor entregam o correio de saída. Gerir uma caixa de correio é o problema difícil, e é um problema diferente.

Receber correio significa aceitar ligações de toda a Internet na porta 25, filtrar spam, armazenar e criar cópias de segurança das caixas de correio e defender a reputação do endereço IP enquanto o servidor existir. Esse trabalho tornou-se realmente mais difícil. Enviar correio significa enviar a reposição da palavra-passe, a confirmação do registo, o alerta de "cópia de segurança falhou" e a notificação de resposta num fórum. Estas mensagens são curtas, têm baixo volume e são enviadas uma de cada vez. Um relay trata delas, e a sua configuração demora uma tarde.

Decida qual dos dois problemas está realmente a tentar resolver. Saber se ainda vale a pena gerir a sua própria caixa de correio é uma questão real com uma resposta real e, para a maioria das pessoas, a resposta é não. Se a sua resposta for sim, um servidor de correio Mailcow completo num VPS é o caminho honesto. A outra parte, o envio, é aquilo de que quase toda a gente precisa e para o qual quase ninguém se prepara.

Primeiro, dois termos. SMTP (simple mail transfer protocol) é o protocolo usado por todas as partes deste processo. Um relay, também chamado smarthost, é um servidor que aceita o seu correio autenticado e entrega-o usando os seus próprios endereços e a sua própria reputação.

Por que o seu VPS não consegue enviar email pela porta 25

Quase todos os provedores de VPS bloqueiam por padrão a porta TCP 25 de saída. A porta 25 é usada pelos servidores de email para se ligarem uns aos outros. Por isso, um VPS comprometido com a porta 25 de saída aberta pode enviar spam diretamente para todos os servidores de email recetores. Os provedores descartam esses pacotes em vez de os recusarem. Por isso, o sintoma é uma ligação que fica pendurada e depois expira, e não um erro.

Teste a partir do servidor:

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

Se o primeiro comando permanecer bloqueado durante os cinco segundos completos e o segundo responder imediatamente, o bloqueio está confirmado. Alguns provedores removem-no depois de analisarem a conta. A maioria não o faz.

O bloqueio não é a principal razão para usar um relay. Mesmo com a porta 25 aberta, o email enviado diretamente a partir de um endereço VPS novo vai parar ao spam ou é recusado sem mais, porque esse endereço não tem histórico de envio e pertence a uma faixa que os servidores recetores tratam como espaço de alojamento. As orientações de envio da Google exigem DNS direto e reverso válidos para o IP de envio. Muitos endereços VPS têm um registo PTR (pointer) genérico que não pode ser alterado. Um relay fornece endereços que já têm histórico.

As portas de submissão são a solução. A porta 587 transporta STARTTLS. A sessão começa em texto simples e é atualizada para TLS. A porta 465 transporta TLS implícito (transport layer security). A sessão é encriptada desde o primeiro byte. Ambas destinam-se a clientes autenticados. Ambas estão abertas nas redes VPS. O seu relay suporta pelo menos uma delas.

Escolha um relay e um subdomínio de envio

Existem muitos fornecedores de correio transacional, e todos desempenham a mesma função. Avalie-os com base em quatro aspetos:

• uma porta de submissão, 587 ou 465, com SMTP AUTH
• assinatura DKIM com o seu próprio domínio e o seu próprio selector, não apenas com os do fornecedor
• dados de bounces e reclamações que possa consultar, através de um dashboard ou de um webhook
• um escalão adequado ao seu volume. Em agosto de 2026, vários fornecedores ainda incluem alguns milhares de mensagens por mês sem custos, mas estas condições mudam frequentemente. Consulte a página de preços atual em vez de qualquer publicação de blog

Envie o correio das aplicações a partir de um subdomínio. Use algo como notify.example.com em vez de example.com. Os recetores atribuem uma reputação a cada domínio, por isso um envio problemático das suas aplicações não afeta o domínio usado pelas suas faturas e pelo correio da sua equipa. Seja realista quanto a esta limitação: alguns recetores agregam os sinais dos subdomínios no domínio organizacional. Por isso, um subdomínio reduz o impacto, mas não o isola completamente.

Configure o relay uma vez para cada aplicação self-hosted

A abordagem tentadora é abrir a página de definições de cada aplicação e inserir nela o host SMTP, o nome de utilizador e a palavra-passe. Nextcloud, o fórum, Grafana, Vaultwarden e o monitor de disponibilidade têm todos esse formulário. Se fizer isso, a credencial passa a existir em seis locais e em seis formatos. Em vários deles, fica dentro de uma base de dados que é salvaguardada como dados, e não como configuração. Quando alterar a palavra-passe, atualizará cinco desses locais. O sexto deixa de enviar, sem indicar claramente o motivo, porque a maioria das aplicações regista o erro SMTP no servidor e continua a mostrar ao utilizador uma página de sucesso.

Configure-a uma vez no host e permita que as aplicações submetam as mensagens localmente. Há duas ferramentas adequadas para isso. A escolha entre elas depende do funcionamento da fila.

msmtp é um cliente compatível com sendmail, sem daemon. Liga-se, envia a mensagem e termina. Não tem fila. Se o relay estiver inacessível, a mensagem perde-se e a aplicação que fez a chamada recebe um estado de saída diferente de zero.

O Postfix configurado como satellite é um agente de transferência de correio completo, com uma fila real. Aceita a mensagem imediatamente, tenta reenviá-la durante dias quando ocorre uma falha e mantém a credencial do relay num ficheiro acessível apenas por root. Use-o quando for importante não perder um alerta durante uma interrupção do relay ou quando várias aplicações forem executadas com utilizadores de sistema diferentes.

msmtp, a opção simples

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

msmtp-mta instala o symlink /usr/sbin/sendmail. Assim, qualquer programa que chame sendmail chega ao msmtp sem saber que ele está instalado.

Escreva /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 define sempre um cabeçalho From e substitui qualquer cabeçalho existente. Assim, substitui o valor produzido pela aplicação pelo endereço definido em from. Sem essa opção, uma tarefa cron envia como root@your-hostname, e o relay recusa o envio porque esse não é um endereço que tenha verificado. syslog on envia o log através do syslog, para que o possa consultar com journalctl -t msmtp. Um caminho logfile partilhado é a alternativa. Nesse caso, é necessária permissão de escrita para todos os utilizadores que enviam correio, o que cria um problema num servidor com vários utilizadores.

Defina as permissões manualmente. O msmtp aplica as permissões a uma configuração por utilizador (~/.msmtprc) e recusa-se a executar com contains secrets and therefore must have no more than user read/write permissions. Não aplica essa verificação a /etc/msmtprc, porque simplesmente carrega esse ficheiro se ele puder ser lido.

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 mostra toda a conversação SMTP, para que possa ver cada resposta do relay. Um envio bem-sucedido termina com uma resposta 250 a aceitar a mensagem. Uma linha authentication failed significa que o nome de utilizador ou a palavra-passe está errada, ou que o relay espera uma chave de API em vez da palavra-passe da conta.

Agora surge o problema, e é por isso que muitas pessoas acabam por usar o Postfix. Com o modo 600 e o proprietário root, apenas root pode enviar. Uma aplicação executada como www-data não consegue ler o ficheiro, o msmtp ignora-o e a aplicação falha com um erro que indica que a conta predefinida não foi encontrada. A solução é usar um grupo:

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

Isto significa claramente que todos os membros do grupo mail podem ler a palavra-passe do relay e enviar correio em nome do seu domínio a partir desse servidor. Num VPS que administra sozinho, isso pode ser aceitável. Quando várias aplicações que não escreveu são executadas com utilizadores diferentes, não é aceitável. Nesse caso, o Postfix é a melhor opção, porque essas aplicações nunca têm acesso à credencial.

Postfix como satellite

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 é obrigatório. Sem ele, o Postfix regista warning: SASL authentication failure: No worthy mechs found, porque as bibliotecas dos mecanismos PLAIN e LOGIN não estão instaladas em /usr/lib/sasl2.

Defina as restantes opções com postconf -e. Esse comando edita /etc/postfix/main.cf diretamente:

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'

Os parênteses retos em redor do nome do relay impedem que o Postfix procure um registo MX para esse nome e fazem com que se ligue diretamente a ele. Alguns nomes de relay publicam registos MX que apontam para outro local. Sem os parênteses retos, o correio segue esses registos para o servidor errado.

smtp_tls_security_level = encrypt torna o TLS obrigatório. Assim, a mensagem nunca é enviada em texto simples. Essa opção não verifica o certificado. A documentação do Postfix é explícita sobre este comportamento: nesse nível, a entrega continua mesmo que o certificado do servidor não seja fidedigno ou tenha um nome incorreto. Para verificar o certificado, use verify ou secure e mantenha smtp_tls_CAfile definido.

A credencial fica num único ficheiro acessível apenas por 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 cria a cópia indexada que o Postfix lê efetivamente. Se editar o ficheiro de texto mais tarde e se esquecer de executar postmap, o Postfix continuará a usar a base de dados antiga. Nada no log indicará essa situação. No Postfix 3.9 e posteriores, o tipo de mapa predefinido é lmdb. Se preferir esse tipo, escreva lmdb: tanto no parâmetro como no argumento postmap. Indicar o tipo nas duas linhas mantém ambas as definições sincronizadas.

As aplicações continuam a endereçar o correio como root@hostname. Reescreva o remetente:

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

Uma tabela regexp: é lida diretamente, por isso não precisa de postmap. Todas as mensagens passam a sair com o mesmo remetente do envelope e o mesmo cabeçalho From, que é o formato esperado pelo relay. A desvantagem é que todas as respostas chegam ao mesmo local. Por isso, defina um cabeçalho Reply-To dentro de cada aplicação, indicando para onde as respostas devem ser enviadas.

Envie uma mensagem de teste e consulte o log:

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

Uma mensagem entregue regista status=sent, seguido da resposta do próprio relay entre parênteses retos. Qualquer outro resultado indica o motivo da falha. status=deferred com Connection timed out significa que ainda há algo configurado para usar a porta 25. Host or domain name not found. Name service error for name=smtp.relay.example type=A significa que o nome do relay está errado ou que o DNS está a falhar no servidor. mailq lista as mensagens pendentes e sudo postqueue -f tenta enviá-las novamente agora.

Aceder ao relay do host a partir de contentores Docker

Um contentor não pode chamar o sendmail do host, porque o binário não está na imagem e a fila não é partilhada. Forneça aos contentores um destino de rede. O Postfix pode escutar no endereço da bridge 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

Leia o endereço da sua própria bridge a partir do primeiro comando, em vez de copiar este valor, porque um projeto Compose cria a sua própria rede numa sub-rede diferente, e docker network inspect <name> apresenta esse valor. Use restart e não reload aqui: a documentação do Postfix indica que é necessário parar e iniciar o serviço depois de alterar inet_interfaces, e um reload não aplica a alteração. Cada aplicação usa depois o host SMTP 172.17.0.1, a porta 25, sem autenticação e sem TLS, porque esse tráfego não sai do host. Se os seus serviços estiverem numa rede Compose, executar Docker Compose num VPS explica de onde vem essa sub-rede.

Este é o passo que pode causar problemas. Um Postfix a escutar num endereço público com um mynetworks permissivo é um open relay: terceiros enviam mensagens através da sua conta de relay, o fornecedor suspende-a e a reputação do seu domínio fica prejudicada durante meses. Verifique ambos os lados depois de cada alteração.

ss -tlnp | grep ':25'

O resultado deve mostrar apenas o endereço de loopback e o endereço da bridge. A partir de outra máquina, nc -vz your.server.ip 25 deve falhar.

SPF, DKIM e DMARC para o domínio de envio

Publique os três registos antes do primeiro envio real. São gratuitos, ficam no DNS e são o primeiro elemento que os servidores recetores verificam.

O SPF (sender policy framework) lista quem pode colocar o seu domínio no remetente do envelope. Publique-o no subdomínio de envio:

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

Copie o valor de include: da própria página de configuração do seu relay, porque um include que não resolva gera um erro permanente em vez de um pass. A avaliação do SPF para depois de dez mecanismos que consultem o DNS e devolve permerror, que os servidores recetores tratam como uma falha. Mantenha poucos includes. Publique exatamente um registo v=spf1 por nome: dois registos também constituem um permerror.

O DKIM (domainkeys identified mail) assina cada mensagem com uma chave privada que o relay mantém, e os servidores recetores obtêm a chave pública correspondente no DNS. O seu relay fornece um seletor e um registo TXT ou CNAME para publicar:

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

O DKIM é mais importante do que o SPF porque sobrevive ao reencaminhamento. Quando uma lista de correio ou uma regra .forward reencaminha a sua mensagem, ela chega a partir do endereço IP do servidor que a reencaminhou. Nesse caso, o SPF falha, mas a assinatura continua a ser validada.

O DMARC (domain-based message authentication, reporting and conformance) indica aos servidores recetores o que fazer quando nenhuma das verificações está alinhada e pede-lhes que enviem relatórios. Publique-o no domínio organizacional:

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

Comece por p=none e leia os relatórios durante duas semanas. p=none não altera a entrega. Apenas ativa os relatórios, que permitem descobrir os sistemas que se esqueceu de configurar e que estão a enviar mensagens como o seu domínio. Depois avance para p=quarantine e, por fim, para p=reject. Publicar p=reject no primeiro dia é uma forma de descobrir que o sistema de faturação estava a enviar mensagens como o domínio, através de um cliente que nunca recebeu uma fatura.

Verifique o que é visível na Internet, não apenas o que o seu painel DNS mostra:

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

Uma saída vazia significa que o registo ainda não foi propagado ou que o nome está errado. Um registo corrigido há cinco minutos pode continuar incorreto nas caches durante o período correspondente ao TTL anterior (time to live). Verifique o TTL antes de tirar qualquer conclusão.

Manter From e Return-Path alinhados

Todas as mensagens transportam dois endereços de remetente, que são verificados de formas diferentes. O remetente do envelope é indicado no comando SMTP MAIL FROM e aparece na mensagem entregue como Return-Path. O cabeçalho From é o endereço que o leitor vê.

O SPF verifica o domínio do remetente do envelope em relação ao endereço IP de ligação. O DKIM indica o domínio que assinou a mensagem, como d=. O DMARC só passa quando pelo menos um desses dois domínios está alinhado com o domínio do cabeçalho From. Com alinhamento relaxado (adkim=r, aspf=r, que é o padrão), um subdomínio é considerado válido. Assim, um remetente do envelope em notify.example.com fica alinhado com um From de cabeçalho em example.com. Com alinhamento estrito, isso não acontece.

A regra prática é simples: use o mesmo domínio no cabeçalho From e no remetente do envelope. Assim, a questão não se coloca. É exatamente isso que set_from_header on faz no msmtp e que sender_canonical_maps faz no Postfix.

Leia o resultado numa mensagem entregue. No Gmail, "Show original" apresenta o cabeçalho que o recetor escreveu:

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

As três verificações passam nesse caso. Qualquer outro resultado indica a verificação que falhou e, normalmente, o motivo. Esta é a informação de depuração mais rápida que obterá sobre este tema.

Bounces e reclamações antes de o volume chegar

Um bounce ocorre quando o destinatário recusa a sua mensagem. Um hard bounce é permanente, e o Gmail descreve-o como 550 5.1.1 The email account that you tried to reach does not exist. Um soft bounce é temporário, um código 4xx causado por uma caixa de correio cheia ou por greylisting, e o relay tenta enviar novamente por conta própria.

Os relays medem a sua taxa de hard bounce e suspendem contas que continuam a enviar mensagens para endereços inexistentes, porque esse padrão é semelhante ao de uma lista comprada. As reclamações são mais importantes. Uma reclamação ocorre quando uma pessoa seleciona o botão de spam. As orientações do Google para remetentes (verificadas em agosto de 2026) pedem que os remetentes mantenham a taxa de spam abaixo de 0.30%, conforme apresentada no Postmaster Tools, e recomendam mantê-la abaixo de 0.10%.

Quatro elementos devem estar preparados antes de o volume chegar:

• um webhook ou uma consulta semanal à lista de supressão do relay, para conseguir ver os bounces
• um endereço From que seja uma caixa de correio real e monitorizada por alguém, com Reply-To definido para indicar o destino das respostas
• confirmação antes de adicionar qualquer endereço, para nunca enviar mensagens para um endereço que o respetivo proprietário não introduziu
• um limite de taxa no formulário que desencadeia o envio de mensagens

Os dois últimos pontos são aqueles em que as aplicações self-hosted falham primeiro. Um formulário de inscrição sem proteção permite que qualquer pessoa introduza o endereço de outra pessoa. O seu servidor envia a confirmação, e essa pessoa marca-a como spam. Impedir o subscription bombing no formulário de inscrição é uma tarefa de deliverability tanto quanto de prevenção de abuso.

Mantenha o correio em massa fora deste caminho. Os newsletters precisam de gestão de listas e de cabeçalhos de cancelamento de subscrição que o correio transacional não utiliza. Por isso, execute-os através de uma instância self-hosted do Listmonk no seu próprio subdomínio, com a sua própria reputação. O correio de notificações de um fórum self-hosted fica entre os dois casos: tem estrutura transacional e volume de correio em massa. Normalmente, é o primeiro elemento a mostrar se a sua configuração funciona de forma consistente.

Para referência, as regras do Gmail para remetentes de correio em massa aplicam-se acima de 5,000 mensagens por dia para endereços do Gmail e exigem SPF, DKIM, DMARC e cancelamento de subscrição com um clique nas mensagens de marketing. A maioria das aplicações self-hosted nunca atinge esse limite. Atualmente, todos os remetentes devem ter a parte da autenticação, independentemente do volume.

Teste antes de confiar

swaks é a ferramenta certa para isso. Ela fala SMTP e mostra toda a conversa, para que possa ver em que etapa ocorreu a falha.

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>'

Isto testa as credenciais diretamente no relay. Para testar o caminho que as suas aplicações usam efetivamente, aponte-a para o relay do host:

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

Depois, verifique o resultado de ponta a ponta, a partir do servidor, com correio real. Nada disto pode ser comprovado apenas pelos ficheiros de configuração, por isso faça o teste:

• envie para um serviço de avaliação, como mail-tester.com, que analisa o seu SPF, DKIM, DMARC e o conteúdo da mensagem e indica as razões da pontuação
• envie para uma mailbox em cada um dos dois fornecedores usados pelos seus utilizadores e leia Authentication-Results na mensagem em bruto
• analise uma mensagem com learndmarc.com quando o resultado do alinhamento não for evidente
• inicie um envio a partir da própria aplicação, e não apenas pela linha de comandos, porque é a aplicação que define o cabeçalho From

Termino com um aviso importante. Um domínio novo, mesmo com os três registos corretos, pode acabar ocasionalmente na pasta de spam, porque ainda não tem histórico e os recetores são cautelosos com domínios que surgiram na semana passada. Comece com um volume reduzido e envie mensagens que as pessoas esperam receber. A reputação constrói-se a partir daí, e nenhuma configuração elimina essa etapa.

FAQ

Por que a porta de saída 25 está bloqueada no meu VPS?

Quase todos os provedores bloqueiam a porta TCP 25 de saída por padrão, porque um servidor comprometido com essa porta aberta pode entregar spam diretamente aos servidores de correio dos destinatários. Os pacotes são descartados em vez de recusados. Por isso, o sintoma é uma conexão que fica pendurada e depois expira, não uma mensagem de erro. Confirme executando nc -vz -w 5 gmail-smtp-in.l.google.com 25 junto com nc -vz -w 5 smtp.relay.example 587: o primeiro fica aguardando, enquanto o segundo responde imediatamente. A solução não é pedir a remoção do bloqueio. Envie por um relay na porta de submissão 587 ou 465. Essas portas permanecem abertas e destinam-se a clientes autenticados.

Preciso de SPF, DKIM e DMARC para enviar apenas algumas notificações da aplicação?

Sim. O volume não altera isso. Os servidores destinatários aplicam as mesmas verificações a uma única redefinição de senha e a uma campanha com cinquenta mil mensagens. Sem SPF e DKIM, o seu correio não é autenticado, e as orientações atuais do Google para remetentes exigem pelo menos um dos dois para cada remetente. Sem DMARC, você não recebe relatórios. Assim, o primeiro sinal de um problema pode ser um usuário informar que o link de redefinição nunca chegou. Os três são registros DNS, não têm custo, e a publicação leva cerca de dez minutos.

Devo usar msmtp ou Postfix como cliente do relay?

Use msmtp quando uma única pessoa administra o servidor e for aceitável perder uma mensagem durante uma indisponibilidade do relay. Ele usa um único arquivo de configuração e não tem daemon. Como não mantém uma fila, um relay inacessível faz com que a mensagem seja perdida. Use o Postfix como satellite quando precisar de uma fila que tente reenviar durante dias ou quando várias aplicações forem executadas por usuários de sistema diferentes. O Postfix mantém a senha do relay em um arquivo acessível apenas por root, que as aplicações nunca leem. O msmtp precisa que a configuração possa ser lida por todos os usuários que enviam mensagens.

Por que o correio da minha aplicação é rejeitado porque vem de root?

Tarefas do cron e muitas aplicações montam o remetente a partir do usuário local e do hostname, produzindo algo como root@srv1.localdomain. Esse não é um endereço que você verificou no relay. Por isso, o relay recusa a mensagem com uma resposta 553 ou 554 que identifica o endereço do remetente. Corrija isso no nível do host, em vez de configurar cada aplicação: set_from_header on junto com um endereço from em /etc/msmtprc, ou sender_canonical_maps com sender_canonical_classes = envelope_sender, header_sender no Postfix. Defina Reply-To dentro de cada aplicação se as respostas precisarem chegar a uma pessoa.

Um subdomínio separado para o correio das aplicações realmente protege o meu domínio principal?

Em parte, e ainda vale a pena fazer isso. Os servidores destinatários acompanham a reputação por domínio. Assim, as reclamações contra notify.example.com permanecem em grande parte associadas a notify.example.com, enquanto o seu domínio principal continua entregando mensagens. A limitação é real: alguns servidores destinatários agregam os sinais dos subdomínios ao domínio organizacional, e uma política DMARC publicada no nível organizacional aplica-se aos subdomínios, a menos que você defina sp= separadamente. Considere o subdomínio uma forma de limitar os danos, não uma garantia.