Enviar correo desde apps autohospedadas sin servidor

Qué aplicaciones autohospedadas necesitan para enviar correo

Para enviar correo desde aplicaciones autohospedadas no necesita un servidor de correo. Necesita un relay: una cuenta SMTP autenticada, configurada una sola vez en el host, a la que todas las aplicaciones del equipo entregan el correo saliente. Ejecutar un buzón es el problema difícil, y es un problema diferente.

Recibir correo implica aceptar conexiones de todo Internet en el puerto 25, filtrar spam, almacenar y realizar copias de seguridad de los buzones, y proteger la reputación de una IP durante toda la vida del servidor. Esa tarea se ha vuelto realmente más difícil. Enviar correo implica enviar el restablecimiento de contraseña, la confirmación del registro, la alerta de «copia de seguridad fallida» y la notificación de respuesta en un foro. Son mensajes cortos, de poco volumen y que se envían de uno en uno. Un relay los gestiona, y configurarlo lleva una tarde.

Decida cuál de los dos problemas intenta resolver realmente. Si todavía merece la pena ejecutar su propio buzón es una pregunta real con una respuesta real y, para la mayoría de las personas, la respuesta es no. Si su respuesta es sí, un servidor de correo Mailcow completo en un VPS es el camino adecuado. La otra parte, el envío, es lo que casi todo el mundo necesita y casi nadie planifica.

Primero, dos términos. SMTP (simple mail transfer protocol) es el protocolo que utiliza cada parte de este sistema. Un relay, también llamado smarthost, es un servidor que acepta su correo autenticado y lo entrega mediante sus propias direcciones y su propia reputación.

Por qué su VPS no puede entregar correo en el puerto 25

Casi todos los proveedores de VPS bloquean de forma predeterminada el puerto TCP 25 saliente. El puerto 25 es el que usan los servidores de correo para comunicarse entre sí. Por eso, un VPS comprometido con el puerto 25 saliente abierto puede entregar spam directamente a cualquier servidor de correo receptor. Los proveedores descartan esos paquetes en lugar de rechazarlos. Por eso, el síntoma es una conexión que queda bloqueada y después agota el tiempo de espera, no un error.

Compruébelo desde el 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

Si el primer comando permanece bloqueado durante los cinco segundos completos y el segundo responde de inmediato, el bloqueo está confirmado. Algunos proveedores lo levantan después de revisar la cuenta. La mayoría no lo hace.

El bloqueo no es el motivo principal para usar un relay. Incluso con el puerto 25 abierto, el correo enviado directamente desde la dirección de un VPS nuevo termina en la carpeta de spam o se rechaza por completo. Esa dirección no tiene historial de envío y pertenece a un rango que los servidores receptores identifican como espacio de hosting. Las directrices de remitentes de Google requieren DNS directo e inverso válidos para la IP emisora. Además, muchas direcciones de VPS tienen un registro PTR (pointer) genérico que no puede cambiar. Un relay le proporciona direcciones que ya tienen historial.

Los puertos de submission son la solución. El puerto 587 usa STARTTLS: la sesión comienza en texto sin cifrar y después se actualiza. El puerto 465 usa TLS implícito (transport layer security): la sesión se cifra desde el primer byte. Ambos están destinados a clientes autenticados, ambos están abiertos en las redes de VPS y su relay admite al menos uno de ellos.

Elija un relay y un subdominio de envío

Hay muchos proveedores de correo transaccional y todos cumplen la misma función. Evalúelos según cuatro aspectos:

• un puerto de envío, 587 o 465, con SMTP AUTH
• firma DKIM con su propio dominio y su propio selector, no sólo con los del proveedor
• datos de rebotes y reclamaciones que pueda consultar mediante un panel o un webhook
• un nivel que se ajuste a su volumen. En agosto de 2026, varios proveedores todavía incluyen unos pocos miles de mensajes al mes sin coste, pero esas condiciones cambian con frecuencia. Consulte la página de precios actual en lugar de cualquier publicación de blog

Envíe el correo de las aplicaciones desde un subdominio. Use algo como notify.example.com en lugar de example.com. Los receptores evalúan la reputación por dominio, por lo que un envío problemático de sus aplicaciones no afecta al dominio desde el que envía las facturas y el correo de su equipo. Sea consciente de esta limitación: algunos receptores agregan las señales de los subdominios al dominio organizativo. Por tanto, un subdominio reduce el daño, pero no lo aísla por completo.

Configure el relay una sola vez para cada aplicación autohospedada

El enfoque más sencillo parece abrir la página de configuración de cada aplicación y pegar en ella el host SMTP, el nombre de usuario y la contraseña. Nextcloud, el foro, Grafana, Vaultwarden y el monitor de disponibilidad tienen ese formulario. Si lo hace, la credencial queda almacenada en seis lugares y en seis formatos. Varios de esos lugares están dentro de una base de datos que respalda como datos, no como configuración. Cuando cambie la contraseña, actualizará cinco de ellos. El sexto dejará de enviar y lo hará sin avisar, porque la mayoría de las aplicaciones registran el error SMTP en el servidor y aun así muestran al usuario una página de éxito.

Configúrelo una sola vez en el host y permita que las aplicaciones envíen localmente. Hay dos herramientas adecuadas para esto. La elección depende del uso de una cola.

msmtp es un cliente compatible con sendmail y no ejecuta ningún daemon. Se conecta, envía el mensaje y termina. No utiliza una cola. Si el relay no está disponible, el mensaje se pierde y la aplicación que lo invocó recibe un estado de salida distinto de cero.

Postfix configurado como satellite es un agente de transferencia de correo completo con una cola real. Acepta el mensaje de inmediato, reintenta el envío durante días si falla y mantiene la credencial del relay en un archivo accesible sólo por root. Úselo cuando perder una alerta durante una interrupción del relay sea importante o cuando varias aplicaciones se ejecuten con distintos usuarios del sistema.

msmtp, la opción pequeña

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

msmtp-mta instala el enlace simbólico /usr/sbin/sendmail. Así, cualquier programa que invoque sendmail llega a msmtp sin saber que existe.

Escriba /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 siempre establece una cabecera From y reemplaza cualquier cabecera existente. Por tanto, sustituye la dirección generada por la aplicación por la dirección de from. Sin esta opción, un trabajo de cron envía el mensaje como root@your-hostname, y el relay lo rechaza porque no es una dirección verificada por usted. syslog on envía el registro a través de syslog, por lo que puede leerlo con journalctl -t msmtp. Una ruta compartida en logfile es la alternativa, pero necesita permisos de escritura para cada usuario que envíe correo. Esto supone un riesgo en un sistema multiusuario.

Establezca los permisos manualmente. msmtp aplica los permisos a la configuración por usuario (~/.msmtprc), donde se niega a ejecutarse con contains secrets and therefore must have no more than user read/write permissions. No aplica ninguna comprobación a /etc/msmtprc, porque simplemente carga ese archivo si puede leerlo.

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 muestra toda la conversación SMTP, por lo que puede ver cada respuesta del relay. Un envío correcto termina con una respuesta 250 que acepta el mensaje. Una línea authentication failed significa que el nombre de usuario o la contraseña son incorrectos, o que el relay espera una API key en lugar de la contraseña de la cuenta.

Aquí está el inconveniente, y es la razón por la que muchas personas terminan usando Postfix. Con el modo 600 y el propietario root, sólo root puede enviar. Una aplicación que se ejecute como www-data no puede leer el archivo, msmtp lo omite y la aplicación falla con un error que indica que no se encontró la cuenta predeterminada. La solución es utilizar un grupo:

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

Esto significa claramente que cada miembro del grupo mail puede leer la contraseña del relay y enviar correo como su dominio desde ese sistema. En un VPS que administra usted solo, es aceptable. Cuando varias aplicaciones que no ha escrito usted se ejecutan con usuarios distintos, no lo es. En ese caso, Postfix es una mejor solución porque esas aplicaciones nunca ven la 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 es obligatorio. Sin él, Postfix registra warning: SASL authentication failure: No worthy mechs found porque las bibliotecas del mecanismo PLAIN y LOGIN no están instaladas en /usr/lib/sasl2.

Configure el resto con postconf -e. Este comando edita /etc/postfix/main.cf directamente:

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'

Los corchetes alrededor del hostname del relay impiden que Postfix busque un registro MX para ese nombre y hacen que se conecte directamente a él. Algunos hostnames de relay publican registros MX que apuntan a otro lugar. Sin los corchetes, el correo los seguirá hasta el servidor equivocado.

smtp_tls_security_level = encrypt hace obligatorio TLS, por lo que el mensaje nunca se envía en texto claro. No verifica el certificado. La documentación de Postfix lo indica explícitamente: en ese nivel, la entrega continúa aunque el certificado del servidor no sea de confianza o tenga un nombre incorrecto. Si quiere comprobar el certificado, use verify o secure y mantenga establecido smtp_tls_CAfile.

La credencial se almacena en un único archivo accesible sólo 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 genera la copia indexada que Postfix lee realmente. Si edita después el archivo de texto y olvida ejecutar postmap, Postfix seguirá usando la base de datos antigua y no habrá nada en el registro que se lo indique. En Postfix 3.9 y versiones posteriores, el tipo de mapa predeterminado es lmdb. Si prefiere usarlo, escriba lmdb: tanto en el parámetro como en el argumento postmap. Indicar el tipo en ambas líneas mantiene sus valores sincronizados.

Las aplicaciones siguen dirigiendo su correo a root@hostname. Reescriba el remitente:

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

Una tabla regexp: se lee directamente, por lo que no necesita postmap. Todos los mensajes saldrán con el mismo remitente del sobre y la misma cabecera From, que es lo que requiere el relay. El inconveniente es que todas las respuestas llegarán al mismo lugar. Configure una cabecera Reply-To dentro de cada aplicación para indicar a qué persona deben llegar las respuestas.

Envíe una prueba y lea el registro:

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

Un mensaje entregado registra status=sent seguido de la respuesta del propio relay entre corchetes. Cualquier otro resultado indica la causa. status=deferred con Connection timed out significa que algo sigue apuntando al puerto 25. Host or domain name not found. Name service error for name=smtp.relay.example type=A significa que el hostname del relay es incorrecto o que DNS no funciona en el sistema. mailq muestra los mensajes atascados y sudo postqueue -f los reintenta ahora.

Acceder al relay del host desde contenedores Docker

Un contenedor no puede ejecutar el sendmail del host porque el binario no está en la imagen y la cola no se comparte. Proporcione a los contenedores un destino de red. Postfix puede escuchar en la dirección del puente de 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

Lea la dirección del puente en su propio sistema a partir del primer comando, en lugar de copiar esta, porque un proyecto de Compose crea su propia red en una subred diferente y docker network inspect <name> la muestra. Use restart y no reload aquí: la documentación de Postfix indica que debe detener y volver a iniciar el servicio después de cambiar inet_interfaces, y que una recarga no aplicará el cambio. Cada aplicación debe usar el host SMTP 172.17.0.1, el puerto 25, sin autenticación y sin TLS, porque ese tráfico no sale del host. Si sus servicios están en una red de Compose, ejecutar Docker Compose en un VPS explica de dónde procede esa subred.

Este es el paso que puede causar problemas. Un Postfix que escucha en una dirección pública con un mynetworks permisivo es un relay abierto: terceros envían su correo a través de su cuenta de relay, el proveedor la suspende y la reputación de su dominio queda dañada durante meses. Compruebe ambos lados después de cada cambio.

ss -tlnp | grep ':25'

La salida sólo debe mostrar la dirección de loopback y la dirección del puente. Desde otra máquina, nc -vz your.server.ip 25 debe fallar.

SPF, DKIM y DMARC para el dominio de envío

Publique los tres registros antes del primer envío real. Son gratuitos, pertenecen a DNS y es lo primero que comprueban los servidores receptores.

SPF (sender policy framework) enumera quién puede colocar su dominio en el remitente del sobre. Publíquelo en el subdominio de envío:

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

Copie el valor de include: de la propia página de configuración de su relay, porque un include que no resuelve produce un error permanente en lugar de un pass. La evaluación de SPF se detiene después de diez mecanismos que realizan consultas DNS y devuelve permerror. Los servidores receptores lo tratan como un fallo, así que mantenga pocos includes. Publique exactamente un registro v=spf1 por nombre. Publicar dos también constituye un permerror.

DKIM (domainkeys identified mail) firma cada mensaje con una clave privada que conserva el relay. Los servidores receptores obtienen la clave pública correspondiente desde DNS. Su relay le proporciona un selector y un registro TXT o un CNAME para publicar:

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

DKIM es más importante que SPF porque sobrevive al reenvío. Cuando una lista de correo o una regla .forward reenvía su mensaje, este llega desde la dirección IP del reenviador. Por eso SPF falla, mientras la firma sigue verificándose.

DMARC (domain-based message authentication, reporting and conformance) indica a los servidores receptores qué deben hacer cuando ninguna de las dos comprobaciones coincide y les pide que envíen informes. Publíquelo en el dominio organizativo:

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

Empiece con p=none y revise los informes durante dos semanas. p=none no cambia la entrega. Sólo activa los informes, que permiten encontrar los sistemas que había olvidado que enviaban mensajes con su dominio. Después cambie a p=quarantine y, por último, a p=reject. Publicar p=reject el primer día es la forma de descubrir que el sistema de facturación enviaba mensajes con el dominio, gracias a un cliente que nunca recibió una factura.

Compruebe lo que ven los servidores de Internet, no lo que muestra su panel de DNS:

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

Una salida vacía significa que el registro aún no se ha propagado o que el nombre es incorrecto. Un registro que corrigió hace cinco minutos puede seguir siendo incorrecto en las cachés durante todo el TTL (time to live) anterior. Compruebe el TTL antes de sacar conclusiones.

Alinee From y Return-Path

Cada mensaje contiene dos direcciones de remitente, que se comprueban de forma distinta. El remitente del sobre se indica en el comando SMTP MAIL FROM y aparece en el mensaje entregado como Return-Path. La cabecera From es la dirección que ve el lector.

SPF comprueba el dominio del remitente del sobre frente a la dirección IP de conexión. DKIM informa del dominio que firmó el mensaje mediante d=. DMARC sólo se valida cuando al menos uno de esos dos dominios está alineado con el dominio de la cabecera From. Con la alineación relajada (adkim=r, aspf=r, que es la opción predeterminada), se acepta un subdominio, por lo que un remitente del sobre en notify.example.com está alineado con una cabecera From en example.com. Con la alineación estricta, no lo está.

La regla práctica es sencilla: use el mismo dominio para la cabecera From y el remitente del sobre, y el problema no se plantea. Eso es exactamente lo que hace set_from_header on en msmtp y lo que hace sender_canonical_maps en Postfix.

Lea el resultado en un mensaje entregado. En Gmail, «Mostrar original» muestra la cabecera que escribió el receptor:

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

Las tres comprobaciones se validan. Cualquier otro resultado indica qué comprobación falló y normalmente por qué. Es la información de depuración más rápida que obtendrá sobre este tema.

Rebotes y quejas antes de que llegue el volumen

Un rebote ocurre cuando el receptor rechaza el mensaje. Un rebote permanente no se puede corregir, y Gmail lo expresa como 550 5.1.1 The email account that you tried to reach does not exist. Un rebote temporal es transitorio: puede devolver un código 4xx por un buzón lleno o por greylisting, y el relay vuelve a intentarlo automáticamente.

Los relays miden la tasa de rebotes permanentes y suspenden las cuentas que siguen enviando a direcciones inexistentes, porque ese patrón se parece al de una lista comprada. Las quejas son más importantes. Una queja ocurre cuando una persona pulsa el botón de spam. Las directrices de Google para remitentes (consultadas en agosto de 2026) piden mantener la tasa de spam por debajo del 0.30%, según los datos de Postmaster Tools, y recomiendan mantenerse por debajo del 0.10%.

Debe tener estas cuatro cosas preparadas antes de que llegue el volumen:

• un webhook o una revisión semanal de la lista de supresión del relay, para detectar los rebotes
• una dirección From que corresponda a un buzón real que alguien lea, con Reply-To configurado para indicar dónde deben llegar las respuestas
• confirmación antes de añadir una dirección a cualquier lista, para no enviar nunca a una dirección que su propietario no haya introducido
• un límite de tasa en cualquier formulario que desencadene el envío de correo

Los dos últimos puntos son los primeros en los que suelen fallar las aplicaciones autohospedadas. Un formulario de registro sin protección permite que cualquiera introduzca la dirección de otra persona. El servidor envía la confirmación y esa persona marca el mensaje como spam. Detener el bombardeo de suscripciones en el formulario de registro es una tarea de entregabilidad tanto como de prevención del abuso.

Mantenga el correo masivo fuera de este flujo. Los boletines necesitan gestión de listas y cabeceras de cancelación de suscripción que el correo transaccional no necesita. Por eso, ejecútelos mediante una instancia autohospedada de Listmonk en su propio subdominio y con su propia reputación. El correo de notificaciones de un foro autohospedado queda en un punto intermedio: tiene una estructura transaccional, pero un volumen masivo. Normalmente es lo primero que muestra si la configuración funciona correctamente.

Como referencia, las reglas de Gmail para remitentes masivos se aplican por encima de 5,000 mensajes al día enviados a direcciones de Gmail. También exigen SPF, DKIM, DMARC y cancelación de suscripción con un clic en el correo de marketing. La mayoría de las aplicaciones autohospedadas nunca alcanza ese umbral. Aun así, todos los remitentes deben usar ya la mitad de autenticación.

Pruébelo antes de confiar en él

swaks es la herramienta adecuada para esto. Habla SMTP y muestra toda la conversación, por lo que puede ver qué paso falló.

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

Esto prueba las credenciales directamente contra el relay. Para probar la ruta que usan realmente sus aplicaciones, apunte al relay del host:

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

Después, compruebe el resultado de extremo a extremo, desde el servidor y con correo real. Nada de esto se puede demostrar sólo con los archivos de configuración, así que ejecútelo usted mismo:

• envíe un mensaje a un servicio de evaluación como mail-tester.com, que analiza sus registros SPF, DKIM y DMARC, además del contenido del mensaje, y explica las razones de la puntuación
• envíe un mensaje a un buzón de cada uno de los dos proveedores que usan realmente sus usuarios y lea Authentication-Results en el mensaje sin formato
• analice un mensaje con learndmarc.com cuando el resultado de la alineación no sea evidente
• inicie el envío desde la propia aplicación, no sólo desde la línea de comandos, porque la aplicación es la que establece la cabecera From

Una última advertencia importante. Un dominio nuevo con los tres registros correctos todavía puede acabar en spam, porque no tiene historial y los receptores desconfían de los dominios que aparecieron la semana pasada. Empiece con un volumen pequeño y envíe mensajes que los destinatarios esperan. La reputación se construye a partir de ahí y ninguna configuración puede evitar esa etapa.

FAQ

¿Por qué está bloqueado el puerto saliente 25 en mi VPS?

Casi todos los proveedores bloquean de forma predeterminada el puerto TCP saliente 25, porque un servidor comprometido con ese puerto abierto puede entregar spam directamente a los servidores de correo receptores. Los paquetes se descartan en lugar de rechazarse, por lo que el síntoma es una conexión que queda bloqueada y después agota el tiempo de espera, no un mensaje de error. Confírmelo ejecutando nc -vz -w 5 gmail-smtp-in.l.google.com 25 junto a nc -vz -w 5 smtp.relay.example 587: el primero queda esperando, mientras el segundo responde de inmediato. La solución no es pedir que retiren el bloqueo. Envíe el correo a través de un relay en el puerto de submission 587 o 465, que permanecen abiertos y están destinados a clientes autenticados.

¿Necesito SPF, DKIM y DMARC sólo para enviar unas pocas notificaciones de la aplicación?

Sí, y el volumen no cambia ese requisito. Los receptores aplican las mismas comprobaciones a un solo restablecimiento de contraseña que a una campaña de cincuenta mil mensajes. Sin SPF y DKIM, el correo no está autenticado, y las directrices actuales de Google para remitentes exigen al menos uno de ellos a todos los remitentes. Sin DMARC no recibe informes, por lo que la primera señal de un problema es que un usuario indique que el enlace de restablecimiento nunca llegó. Los tres son registros DNS, no tienen ningún coste y publicarlos lleva unos diez minutos.

¿Debo usar msmtp o Postfix como cliente relay?

Use msmtp cuando una sola persona administre el servidor y sea aceptable perder un mensaje durante una interrupción del relay. Consta de un único archivo de configuración y no utiliza un daemon. Como no pone los mensajes en cola, si el relay no está disponible el mensaje se pierde. Use Postfix como satellite cuando necesite una cola que reintente el envío durante días o cuando varias aplicaciones se ejecuten con usuarios del sistema distintos. Postfix guarda la contraseña del relay en un archivo accesible sólo para root que las aplicaciones nunca leen, mientras que msmtp necesita que su configuración sea legible para cada usuario que envía mensajes.

¿Por qué se rechaza el correo de mi aplicación porque procede de root?

Los trabajos de Cron y muchas aplicaciones construyen el remitente a partir del usuario local y el nombre de host, y producen algo como root@srv1.localdomain. Esa no es una dirección que haya verificado en el relay, por lo que este rechaza el mensaje con una respuesta 553 o 554 que indica la dirección del remitente. Corríjalo a nivel del host en lugar de hacerlo en cada aplicación: set_from_header on junto con una dirección from en /etc/msmtprc, o sender_canonical_maps con sender_canonical_classes = envelope_sender, header_sender en Postfix. Configure Reply-To dentro de cada aplicación si las respuestas deben llegar a una persona.

¿Protege realmente un subdominio independiente para el correo de las aplicaciones a mi dominio principal?

En parte, y aun así merece la pena hacerlo. Los receptores siguen la reputación por dominio, por lo que las quejas contra notify.example.com se mantienen en gran medida asociadas a notify.example.com, mientras el dominio principal sigue entregando mensajes. El límite es real: algunos receptores trasladan las señales de los subdominios al dominio organizativo, y una política DMARC publicada en el nivel organizativo se aplica a los subdominios salvo que configure sp= por separado. Considere el subdominio una medida para limitar el daño, no una garantía.