Correo: relay autenticado vs envío directo — elige el enfoque que no te bloquee

La decisión: envío directo vs relay autenticado

Envío directo (tu MTA entrega directamente al MX del destinatario)

En un modelo de envío directo, tu servidor ejecuta un MTA (Postfix/Exim/etc.) y se conecta con los intercambiadores de correo (MX) del destinatario en Internet. Controlas toda la sesión SMTP, la cola, los reintentos, la política TLS y el rendimiento. También asumes toda la carga de la reputación y la ingeniería de entregabilidad.

Usa envío directo cuando:

• Puedes comprometerte a operar el correo como un servicio de producción (monitorización, gestión de abusos, manejo de reputación).
• Necesitas alto control sobre el enrutamiento, reintentos, políticas personalizadas y afinamiento por dominio.
• Tienes volumen de envío estable y puedes calentar las IP correctamente.
• Puedes asignar una IP dedicada limpia (o un pool gestionado cuidadosamente) con rDNS correcto.

Evita el envío directo cuando:

• Estás en instancias en la nube con IPs que cambian frecuentemente.
• No controlas rDNS/PTR (común en planes VPS de consumo y algunas redes internas).
• Envías bajo volumen pero necesitas alta entregabilidad (la reputación nunca “se asienta”).
• No tienes un plan para quejas de spam, rebotes y bucles de feedback.

Relay autenticado (tu servidor envía el correo a un proveedor)

En un modelo de relay autenticado, tus sistemas envían correo a un smarthost mediante la sumisión SMTP (usualmente puerto 587, a veces 465) con autenticación (SASL) y TLS. El proveedor de relay luego se encarga de la entrega hacia los MX de destino. Ese proveedor puede ser un ESP (servicio de correo transaccional), tu suite corporativa (Microsoft 365 / Google Workspace) o una capa interna de relays.

Usa relay autenticado cuando:

• Quieres entregabilidad sin convertirte en una compañía de entregabilidad de correo.
• Necesitas conectividad saliente predecible desde redes muy cerradas (587 funciona donde el 25 está bloqueado).
• Quieres que la reputación la gestione un tercero que tenga personal dedicado a ello.
• Necesitas auditoría consolidada, limitación de tasa, detección de abuso y procesamiento de rebotes.

Evita el relay autenticado cuando:

• No puedes tolerar la dependencia de una infraestructura de envío de terceros.
• Tienes restricciones estrictas de residencia de datos y el relay no puede cumplirlas.
• Necesitas ciertos comportamientos SMTP que el relay no permitirá (raro, pero sucede).

Mi sesgo operacional

Si gestionas un producto SaaS típico, notificaciones internas, restablecimientos de contraseña, facturas y alertas: usa un relay autenticado. Es aburrido. Reduce el radio de impacto. Evita que acabes en listas de bloqueo cuando algún becario decide “probar” enviando la tabla de clientes dos veces.

El envío directo es para equipos que eligen explícitamente hacerse cargo del correo como infraestructura, incluidos todos los casos límite desagradables. Se puede hacer bien. Pero si lo tratas como “solo otro demonio”, te tratará como “solo otro spammer”.

Hechos e historia que aún importan en 2026

• SMTP precede al spam como problema industrial. El SMTP temprano asumía pares cooperativos; los filtros modernos asumen que podrías estar mintiendo hasta que demuestres lo contrario.
• El bloqueo de salida por el puerto 25 se volvió común cuando los ISPs lucharon contra botnets. Muchas redes aún bloquean el 25 saliente; los puertos de sumisión (587/465) son la vía pragmática.
• SPF apareció porque falsificar el remitente del sobre era trivial. Es un parche de la era DNS que sigue importando porque los receptores lo usan para modelar intención y responsabilidad.
• DKIM se creó para proteger cabeceras y cuerpo y demostrar responsabilidad del dominio. No es cifrado; es una firma que sobrevive el reenvío (a veces).
• DMARC existe porque SPF y DKIM por sí solos no eran suficientes. Alineación y política permiten que un dominio diga “rechaza esto si no somos realmente nosotros”.
• Los remitentes masivos impulsaron sistemas de reputación sofisticados. La idea de “la IP es buena/mala” evolucionó hacia reputación de dominio, reputación de contenido, señales de interacción y tasas de queja.
• rDNS/PTR sigue siendo un filtro contundente pero eficaz. Un PTR faltante no siempre te bloqueará, pero a menudo degrada la confianza y aumenta la colocación en spam.
• TLS se volvió una expectativa y luego una señal. STARTTLS oportunista es la línea base; algunos receptores ahora te puntúan por cifrados modernos y comportamiento TLS estable.
• Greylisting entrenó a los MTAs a reintentar correctamente. El comportamiento de reintentos descuidado sigue siendo un signo de infraestructura de baja calidad y puede dañar la entregabilidad.

Modelos de entrega y dónde falla cada uno

Modelo A: App → MTA local → directo al MX del destinatario

Este es el clásico. Tu app habla SMTP a localhost, Postfix hace cola, Postfix realiza búsquedas DNS para MX y luego entrega hacia afuera. Los puntos de fallo incluyen DNS, conectividad saliente, reputación, rDNS, negociación TLS y límites de tasa en el receptor.

Modo de fallo que reconocerás: funciona con dominios pequeños, falla con los grandes. Eso ocurre porque los proveedores principales tienen los sistemas de reputación más estrictos y la mejor telemetría.

Modelo B: App → MTA local → smarthost autenticado

Tu app aún habla SMTP localmente, pero Postfix reenvía todo a un proveedor con AUTH y TLS. Los puntos de fallo se trasladan de “¿podemos alcanzar todos los MX del mundo?” a “¿podemos autenticarnos, cumplir límites del proveedor y alinear la identidad?”.

El fallo engañoso: el relay acepta el correo pero nunca llega. Aquí necesitas entender que “aceptado” no es “entregado”. Es “encolado en otra parte”. Necesitas IDs de mensaje y una forma de correlacionar eventos.

Modelo C: App → API del proveedor (HTTP) → el proveedor entrega

No es el tema principal, pero importa porque los equipos a menudo derivan hacia ello. Enviar por API elimina tu MTA local pero aumenta el acoplamiento con el proveedor. Puede ser excelente. También puede fallar de maneras extrañas cuando tu app despliega una plantilla nueva que activa filtros de contenido.

Realidad híbrida

La mayoría de las empresas acaban híbridas:

• Correo transaccional vía relay autenticado (restablecimientos de contraseña, recibos).
• Alertas internas vía envío directo al MX corporativo (o relay interno).
• Correo de marketing vía una canalización ESP dedicada.

Esa separación es saludable. También significa que debes ser explícito sobre qué ruta usa cada mensaje. Si no, accidentalmente enrutarás restablecimientos de contraseña a través de la IP de marketing y aprenderás nuevos significados de la palabra “incidente”.

Identidad: SPF, DKIM, DMARC, alineación y por qué “pass” puede aún fallar

SPF: autorización para el remitente del sobre

SPF comprueba si la IP remitente está autorizada a enviar en nombre del dominio en RFC5321.MailFrom (envelope-from). Se evalúa mediante registros TXT en DNS.

Qué hace bien SPF: evita la suplantación casual y da a los receptores una señal limpia cuando tu infraestructura es estable.

Qué hace mal SPF: el reenvío. Si un mensaje se reenvía a través de otro servidor, SPF puede fallar porque la IP del reenvío no está en tu registro SPF.

DKIM: firma para cabeceras/cuerpo del mensaje

DKIM firma cabeceras seleccionadas y el cuerpo con una clave privada; los receptores verifican mediante una clave pública en DNS. Sobrevive el reenvío mejor que SPF porque la firma sigue siendo verificable, a menos que el mensaje sea modificado.

Trampa operativa común: un sistema aguas abajo modifica el mensaje (inyección de pie de página, ajuste de líneas, conversión MIME), rompiendo la firma DKIM. El receptor ve “DKIM fail”, y tu historia de alineación DMARC se pone fea.

DMARC: alineación y política

DMARC pregunta: ¿el dominio en la cabecera From visible se alinea con SPF o DKIM (o ambos), y qué debemos hacer si no? La política se expresa como none/quarantine/reject.

La alineación es donde los equipos se sorprenden. Puedes tener SPF pass y DKIM pass, y aún fallar DMARC si no están alineados con el dominio From. No es que el receptor sea antipático. Es que tu configuración es incoherente.

El relay autenticado cambia quién “posee” la IP de envío

Con envío directo, la IP de tu servidor se evalúa frente al SPF de tu dominio. Con un relay autenticado, importan las IPs del proveedor de relay, y tu SPF debe autorizarlas. DKIM puede ser firmado por ti (preferido) o por el proveedor (aceptable si se alinea correctamente).

Una cita para tener en una nota adhesiva

“La esperanza no es una estrategia.” — General Gordon R. Sullivan

La entregabilidad del correo es el libro de texto donde esto aplica. Si “esperas” que tu IP en la nube sea confiable, estás eligiendo tiempo de inactividad vía carpeta de spam.

Realidad de la infraestructura: reputación de IP, rDNS, TLS, colas, límites de tasa

La reputación de IP no es un juicio moral, es un modelo estadístico

Los receptores puntúan tu IP (y dominio) según tasas de queja, tasas de rebote, hits a trampas de spam, patrones de envío y señales de contenido. Envío directo significa que cargas esa puntuación. Relay autenticado significa que pides prestado el modelo de puntuación de otro—y sus restricciones.

El envío directo también significa heredar los pecados del pasado de tu IP. En entornos en la nube, la reutilización de IP es real. Puedes conseguir una IP con historial, y tu primer correo será tratado como un invitado que rompió los muebles la vez anterior.

Reverse DNS (PTR) es higiene básica

Muchos receptores esperan que una IP tenga un registro PTR que coincida con un registro DNS directo (A/AAAA) y que parezca razonable. No necesita ser poético. Debe ser consistente y estar bajo control.

TLS: no necesitas perfección, necesitas consistencia

TLS oportunista es la línea base. Algunos receptores penalizan un “TLS raro”, como cadenas rotas, nombres de host que no coinciden o suites de cifrado débiles. Al usar un relay autenticado, normalmente obtienes TLS moderno por defecto y menos razones para depurar OpenSSL a las 3 a.m.

Colas y reintentos son parte de la entrega

Un MTA que reintenta correctamente y retrocede inteligentemente parece infraestructura legítima. Un MTA que reintenta agresivamente parece una botnet. Uno de estos entrega. El otro es bloqueado.

La limitación de tasa no es personal

Los grandes proveedores limitan la tasa de nuevos o bajos en reputación. Tu trabajo no es “luchar” contra los límites; es diseñar alrededor de ellos:

• Encola y reintenta con gracia.
• Envía primero el correo crítico (restablecimientos, alertas de inicio de sesión).
• Calienta IPs y dominios en lugar de volcar volumen de golpe.

Broma corta #1: La entregabilidad de correo es como salir en pareja—si te presentas de forma inesperada desde una dirección sospechosa, no te sorprendas si te ignoran.

Tres mini-historias corporativas (realistas, anonimizadas, dolorosas)

Mini-historia 1: El incidente causado por una suposición equivocada

El equipo ejecutaba una pequeña flota de servidores de aplicación y decidió “mantenerlo simple”: Postfix en cada nodo, envío directo a Internet, misma configuración en todos lados. Usaron las IPs de salida por defecto del proveedor en la nube. Nadie poseía rDNS. Nadie gestionaba la reputación. Pero los correos de staging llegaban, y también la primera semana de producción, así que parecía estar bien.

Luego, un evento de escalado reemplazó un montón de nodos. Esas réplicas vinieron con IPs diferentes. De la noche a la mañana, los correos de restablecimiento de contraseña empezaron a rebotar para proveedores de buzones importantes con difusos deferidos 4xx y reversiones 5xx ocasionales. Soporte vio un pico: los usuarios no podían iniciar sesión, no podían restablecer contraseñas y culpaban “la app”. La app estaba inocente. El camino del correo no lo estaba.

La suposición equivocada era sutil: “una IP es una IP”. En email, una IP es un objeto de reputación con historial. Las IPs nuevas significaron reputación nueva, y la reputación era fría o mala. El comportamiento de envío de la flota cambió de estable a caótico, y los sistemas receptores reaccionaron como siempre lo hacen: proteger a los usuarios primero.

La solución fue operativa, no heroica. Pasaron a un relay autenticado con IPs de envío estables, añadieron autorización SPF para el relay, activaron DKIM firmado alineado con el dominio From y dejaron de fingir que el autoscaling en la nube es compatible con la entregabilidad DIY por defecto. El envío directo podría haber funcionado, pero habría requerido IPs de egreso dedicadas, control de rDNS, warming, monitorización y a alguien a cargo. No lo tenían, así que no debían haber elegido ese modelo.

Mini-historia 2: La optimización que salió mal

Otra compañía usaba un relay autenticado, pero querían reducir latencia en su canal de notificaciones. Alguien notó que cada servidor de app establecía nuevas sesiones TLS al relay con frecuencia. Así que “optimizaron” aumentando la reutilización de conexiones, incrementando concurrencia y agrupando más correos por conexión.

Funcionó—hasta que no. El proveedor de relay empezó a aplicar throttling. No porque el volumen total fuera mayor, sino porque el patrón de envío cambió: ráfagas, picos y comportamientos de conexión que parecían automatización abusiva. Algunos mensajes empezaron a encolarse en el lado del proveedor y luego a entregarse tarde. La app seguía devolviendo “enviado” porque el relay aceptó la sumisión. Los usuarios experimentaron retrasos y duplicados cuando la app reintentó en la capa equivocada.

El contragolpe fue clásico: optimizar para micro-latencia sin entender el contrato macro del sistema. La sumisión SMTP no es un RPC de baja latencia. Es una canalización de almacenar-y-reenviar con políticas y controles de reputación. Sobreajustar el comportamiento de conexión cambió la huella del remitente y activó las salvaguardas.

La recuperación implicó reducir la concurrencia a las guías del proveedor, añadir semántica de reintento correcta (no reintentar si ya obtuviste un 250 + ID de cola) e implementar idempotencia en la capa de aplicación para que el mismo evento no se convirtiera en múltiples correos durante un throttling transitorio.

Mini-historia 3: La práctica aburrida pero correcta que salvó el día

Una organización orientada a finanzas enviaba facturas y avisos de cuentas. Usaban un relay autenticado para correo saliente, pero también ejecutaban una pequeña instancia Postfix interna como puerta de sumisión para aplicaciones. La puerta hacía una cosa poco sexy extremadamente bien: etiquetaba cada mensaje con una cabecera de correlación y registraba la relación entre el ID de solicitud de la app, el ID de cola SMTP y el ID de mensaje del proveedor de relay.

Un martes, un gran proveedor de buzones empezó a deferir correos desde el pool compartido del proveedor de relay debido a un problema localizado de reputación que afectaba a muchos clientes. No era culpa de la organización y no podían arreglarlo. Pero podían explicarlo. En minutos, el on-call sacó una lista de IDs de mensaje afectados, extrajo códigos de respuesta SMTP y produjo una actualización de estado orientada al cliente que fue específica: “Mensajes enviados entre la hora A y la hora B están retrasados debido a deferidos 4xx; no hay pérdida de datos; reintentos en curso”.

Soporte dejó de adivinar. Producto dejó de culpar al “correo inestable”. Liderazgo no exigió cambios de configuración aleatorios. El proveedor resolvió el problema de reputación y la entrega se reanudó. La única razón por la que fue tranquilo es que la organización trató el correo como una canalización de producción: trazabilidad, logs y límites de reintento claros.

Broma corta #2: Nada genera confianza como una cola bien etiquetada—sin ella, solo gritas al vacío SMTP.

Tareas prácticas con comandos: comprobar, probar, decidir

Estas son tareas que realmente ejecuto durante incidentes. Cada una incluye: un comando, un fragmento de salida realista, qué significa y la decisión que tomas a continuación.

Task 1: Confirmar qué ruta estás usando (directa vs relay)

cr0x@server:~$ postconf -n | egrep '^(relayhost|smtp_sasl_auth_enable|myhostname|myorigin|mydestination)'
relayhost = [smtp.relay.example]:587
smtp_sasl_auth_enable = yes
myhostname = app-01.prod.example.net
myorigin = /etc/mailname
mydestination = localhost

Significado: relayhost está configurado a un endpoint de sumisión en 587 y SASL está habilitado. Estás relaying, no entregando directo.

Decisión: Depura throttling/auth/TLS del proveedor y alineación de identidad, no la conexión saliente por puerto 25 hacia MX arbitrarios.

Task 2: Si es envío directo, confirma que el puerto 25 saliente no esté bloqueado

cr0x@server:~$ nc -vz gmail-smtp-in.l.google.com 25
Connection to gmail-smtp-in.l.google.com 25 port [tcp/smtp] succeeded!

Significado: La red permite TCP/25 saliente hacia al menos un MX importante.

Decisión: Si la entrega aún falla, pivota a reputación/TLS/rDNS/contenido en lugar de conectividad básica.

Task 3: Probar la sumisión al relay con STARTTLS y capacidad AUTH

cr0x@server:~$ openssl s_client -starttls smtp -connect smtp.relay.example:587 -servername smtp.relay.example -crlf
...
250-smtp.relay.example
250-PIPELINING
250-SIZE 52428800
250-STARTTLS
250-AUTH PLAIN LOGIN
250 HELP

Significado: El relay soporta STARTTLS y métodos AUTH. Buen baseline.

Decisión: Si Postfix no puede autenticarse, probablemente sea credenciales/config SASL, no que el relay esté caído.

Task 4: Verificar DNS para SPF en el dominio From

cr0x@server:~$ dig +short TXT example.com
"v=spf1 include:_spf.relay.example -all"
"google-site-verification=..."

Significado: SPF autoriza al proveedor de relay mediante include y usa -all (fallo duro para IPs no autorizadas).

Decisión: Si envías directamente desde tus propias IPs, este SPF está mal; añade tus IPs o cambia a relay intencionalmente.

Task 5: Validar que exista el registro público de la clave DKIM

cr0x@server:~$ dig +short TXT s1._domainkey.example.com
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtu6..."

Significado: El selector DKIM s1 está publicado.

Decisión: Si los receptores muestran DKIM=fail, revisa si el sistema de firmado está usando el mismo selector y dominio, y si algún middleware modifica el mensaje.

Task 6: Inspeccionar la política DMARC y el modo de alineación

cr0x@server:~$ dig +short TXT _dmarc.example.com
"v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; adkim=s; aspf=r; pct=100"

Significado: DMARC está forzando cuarentena. La alineación DKIM es estricta (adkim=s), SPF está relajado (aspf=r).

Decisión: La alineación DKIM estricta significa que el dominio d= del DKIM debe coincidir exactamente con el dominio From. Si tu relay firma con un d= distinto, fallarás DMARC.

Task 7: Verificar reverse DNS (PTR) de tu IP de envío (ruta directa)

cr0x@server:~$ dig +short -x 203.0.113.10
mailout-01.example.net.

Significado: PTR existe y apunta a un hostname.

Decisión: Confirma que el DNS directo de ese hostname resuelve a la misma IP; si no, corrige la discrepancia o espera penalizaciones de entregabilidad.

Task 8: Verificar que el DNS directo coincida con PTR (sanidad básica)

cr0x@server:~$ dig +short mailout-01.example.net A
203.0.113.10

Significado: Reverse-confirmed forward DNS (FCrDNS) pasa.

Decisión: Si no coincide, arregla DNS antes de debatir cualquier otra cosa. Esto es requisito básico para envío directo.

Task 9: Comprobar si tu IP está listada en listas negras DNS comunes (señal, no evangelio)

cr0x@server:~$ for z in zen.spamhaus.org bl.spamcop.net b.barracudacentral.org; do ip=203.0.113.10; rev=$(echo $ip | awk -F. '{print $4"."$3"."$2"."$1}'); echo "Query $z:"; dig +short ${rev}.${z} A; done
Query zen.spamhaus.org:
Query bl.spamcop.net:
Query b.barracudacentral.org:

Significado: No se devolvió un registro A, por lo que no está listado en estas tres en el momento de la consulta.

Decisión: Si está listado, deja de enviar directo desde esa IP hasta entender por qué; cambia a relay autenticado o a una IP limpia mientras remediar.

Task 10: Inspeccionar la profundidad de la cola de Postfix (¿estás atascado localmente?)

cr0x@server:~$ mailq | head -n 20
-Queue ID-  --Size-- ----Arrival Time---- -Sender/Recipient-------
A1B2C3D4E5     1823 Mon Jan  4 09:12:10  alerts@example.com
                                         user@gmail.com
                                         (connect to gmail-smtp-in.l.google.com[142.250.102.27]:25: Connection timed out)

Significado: El correo está en cola local debido a timeouts de conexión al MX del destinatario.

Decisión: Revisa firewall saliente, enrutamiento y si el destinatario está deferiendo vía tarpitting. Si es generalizado, sospecha bloqueo de salida por 25 o cambios en ACL de red.

Task 11: Rastrear un mensaje específico en los registros (encontrar la respuesta SMTP)

cr0x@server:~$ grep -R "A1B2C3D4E5" /var/log/mail.log | tail -n 5
Jan  4 09:12:10 app-01 postfix/qmgr[1187]: A1B2C3D4E5: from=<alerts@example.com>, size=1823, nrcpt=1 (queue active)
Jan  4 09:12:12 app-01 postfix/smtp[2214]: A1B2C3D4E5: to=<user@gmail.com>, relay=gmail-smtp-in.l.google.com[142.250.102.27]:25, delay=2.1, delays=0.1/0/2/0, dsn=4.4.1, status=deferred (connect to gmail-smtp-in.l.google.com[142.250.102.27]:25: Connection timed out)

Significado: DSN 4.4.1 indica una falla temporal de red; Postfix reintentará.

Decisión: Si el DSN es 5.x.x (permanente), deja de reintentar y arregla identidad/contenido/reputación. Si es 4.x.x, arregla la conectividad o espera a que pasen los límites según el texto del mensaje.

Task 12: Verificar que Postfix use el relay y no filtre envíos directos

cr0x@server:~$ grep -E "relay=" /var/log/mail.log | tail -n 3
Jan  4 10:02:41 app-01 postfix/smtp[4021]: 9F8E7D6C5B: to=<user@outlook.com>, relay=smtp.relay.example[198.51.100.20]:587, delay=1.2, dsn=2.0.0, status=sent (250 2.0.0 queued as 7c9f1a2b-1234-5678-9012-acdeffedcba0)
Jan  4 10:02:42 app-01 postfix/smtp[4021]: 1A2B3C4D5E: to=<user@gmail.com>, relay=smtp.relay.example[198.51.100.20]:587, delay=0.9, dsn=2.0.0, status=sent (250 2.0.0 queued as 0d1e2f3a-aaaa-bbbb-cccc-112233445566)

Significado: Los mensajes salen vía relayhost en 587 y son encolados por el proveedor (tienes IDs de cola del proveedor).

Decisión: Si algunas líneas muestran relay=recipient-mx:25, tienes rutas mezcladas. Corrige transport maps o restricciones de relay antes de depurar entregabilidad—no puedes depurar dos sistemas a la vez.

Task 13: Comprobar política TLS y si estás fallando la negociación TLS

cr0x@server:~$ postconf -n | egrep '^(smtp_tls_security_level|smtp_tls_CAfile|smtp_tls_loglevel|smtp_tls_policy_maps)'
smtp_tls_security_level = may
smtp_tls_loglevel = 1

Significado: TLS oportunista está habilitado (may). El nivel de logs es bajo pero está presente.

Decisión: Si ves fallos TLS en los logs, incrementa temporalmente smtp_tls_loglevel para depurar. Si requieres TLS (encriptado), configura security_level=encrypt solo si sabes que los destinatarios lo soportan o tienes policy maps.

Task 14: Probar cómo era el mensaje realmente en la red (cabeceras)

cr0x@server:~$ sed -n '1,60p' /var/spool/postfix/deferred/A/A1B2C3D4E5
From: "Example Alerts" <alerts@example.com>
To: user@gmail.com
Subject: Your login code
Date: Mon, 04 Jan 2026 09:12:09 +0000
Message-ID: <20260104091209.12345@app-01.prod.example.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8

Significado: Esto muestra las cabeceras almacenadas del mensaje (no las cabeceras finales recibidas). Útil para verificar dominio From, dominio del Message-ID y tipo de contenido.

Decisión: Si la alineación DMARC es estricta y ves From: usa un dominio pero DKIM firma otro (o Message-ID confunde a los receptores), estandariza los dominios en las cabeceras.

Task 15: Confirmar que tu app no está eludiendo el MTA y usando librerías SMTP directas

cr0x@server:~$ ss -tpn | egrep ':25 |:587 ' | head
ESTAB 0 0 10.0.1.10:49822 198.51.100.20:587 users:(("master",pid=1123,fd=24))
ESTAB 0 0 10.0.1.10:50112 142.250.102.27:25 users:(("python3",pid=9981,fd=8))

Significado: Postfix usa el relay en 587, pero un proceso python se conecta directamente a un MX de destinatario en 25.

Decisión: Caza ese proceso. Obliga una única ruta de salida de correo. “Parte por relay, parte directo” es cómo acabas con la reputación de tu dominio atada al caos.

Task 16: Comprobar desfase horario del sistema (DKIM y TLS pueden comportarse mal con relojes desincronizados)

cr0x@server:~$ timedatectl
               Local time: Mon 2026-01-04 10:15:22 UTC
           Universal time: Mon 2026-01-04 10:15:22 UTC
                 RTC time: Mon 2026-01-04 10:15:21
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Significado: El reloj está sincronizado; bien.

Decisión: Si no está sincronizado, arregla NTP. Algunos receptores son tolerantes; otros tratan firmas con desfase temporal y sesiones TLS con sospecha.

Guía rápida de diagnóstico

Esta es la secuencia “dejar de agitarse”. Ejecútala en orden. Intentas localizar el cuello de botella: app, MTA local, proveedor de relay, receptor o DNS/autenticación.

Primero: Determina dónde termina “enviado”

1. ¿La app está entregando correo a algo? Busca logs de la app con IDs de mensaje o códigos de respuesta SMTP. Si la app nunca hizo el handoff, tienes un bug de aplicación, no de entregabilidad.
2. ¿La cola de Postfix crece? mailq. Si la cola local crece, tu sistema no puede entregar (red, auth, DNS, outage del relay).
3. ¿Los logs muestran 250 queued en un relay? Si es así, tu problema se movió corriente abajo. Deja de culpar a Postfix.

Segundo: Revisa identidad y alineación, no solo “pasa”

1. Registro SPF existe y autoriza al sistema de envío (tu IP o relay).
2. DKIM está presente y verificable; el selector existe en DNS.
3. La política DMARC no te está rechazando; la alineación coincide con el dominio From.

Tercero: Comprueba reputación y señales básicas de confianza

1. Si es directo: PTR existe y coincide con A (FCrDNS).
2. Si es directo: revisa señales de listas negras y si la IP es nueva/rotativa.
3. Si es relay: comprueba el estado del proveedor, límites de tasa y si excediste cuotas.

Cuarto: Verifica feedback del lado receptor (rebotes, deferidos, colocación en spam)

1. Analiza códigos de respuesta SMTP desde logs o eventos del proveedor.
2. Busca patrones por dominio (gmail vs outlook vs yahoo).
3. Identifica si es rechazo (5xx), deferido (4xx) o colocación en spam (aceptado pero no en bandeja).

Errores comunes: síntoma → causa raíz → solución

1) “Funciona en staging, falla en producción”

Síntoma: Los correos de prueba llegan; los correos de producción a grandes proveedores rebotan o desaparecen.

Causa raíz: Producción envía desde IPs distintas (autoscaling, NAT, múltiples rutas de egreso) con reputación fría/mala y PTR faltante.

Solución: Usa un relay autenticado o fija IPs de salida dedicadas con rDNS controlado; fuerza una única ruta de egreso de correo; calienta gradualmente.

2) “SMTP dice 250 OK pero los usuarios no ven el correo”

Síntoma: Logs muestran 250 queued en relay/proveedor; los destinatarios dicen que no llegó nada.

Causa raíz: Aceptado en la cola del proveedor; luego descartado/throttled; o entregado a spam/cuarentena debido a contenido/alineación DMARC.

Solución: Correlaciona IDs de cola del proveedor, inspecciona logs de eventos del proveedor y valida SPF/DKIM/DMARC. Implementa procesamiento de rebotes y monitorización de quejas.

3) “Pico repentino de rebotes tras un deploy”

Síntoma: Rechazos empiezan justo después de desplegar un cambio de plantilla.

Causa raíz: Filtros de contenido activados (patrones de URL, MIME roto, falta de List-Unsubscribe para bulk, codificación rara). O DKIM se rompe porque el middleware modifica el cuerpo.

Solución: Restaura la plantilla, compara MIME bruto, asegura que la canonicalización DKIM se ajuste a las transformaciones y evita patrones de contenido arriesgados.

4) “Algunos destinatarios reciben, otros no”

Síntoma: Gmail bien, Outlook bloqueado (o al revés).

Causa raíz: Puntuación de reputación específica por proveedor; incompatibilidad TLS/cipher; includes SPF inconsistentes; problemas en la ruta IPv6.

Solución: Segmenta por dominio destinatario, revisa transcripciones SMTP y códigos de respuesta, desactiva el envío IPv6 roto si está mal configurado y afina políticas por dominio si envías directo.

5) “Reportes DMARC muestran fallos pero juramos que configuramos SPF y DKIM”

Síntoma: Los reportes agregados muestran fallos DMARC en alto porcentaje.

Causa raíz: Desalineación: el dominio From difiere del dominio d= de DKIM o del dominio MailFrom de SPF. O terceros envían como tú sin autorización.

Solución: Alinea From con el dominio que firma DKIM; usa un subdominio dedicado para remitentes terceros; actualiza includes SPF; aplica DMARC con mayor restricción conforme ganes confianza.

6) “Añadimos más servidores para enviar más rápido y la entregabilidad empeoró”

Síntoma: Mayor throughput, peor colocación en bandeja de entrada y más throttling.

Causa raíz: Ráfagas de volumen y cambios de concurrencia alteraron la huella del remitente; la reputación por IP se diluyó; la tasa de queja subió por falta de throttling.

Solución: Centraliza el envío mediante un relay autenticado o una capa de envío controlada; aplica límites de tasa; calienta IPs; prioriza mensajes.

7) “Los rebotes son altos y soporte dice que las direcciones son válidas”

Síntoma: Picos de 550 user unknown.

Causa raíz: Problema de higiene de listas, datos antiguos, errores tipográficos o abuso de registro generando direcciones inválidas.

Solución: Implementa manejo de rebotes y supresión; valida direcciones en el registro cuidadosamente (sin molestar a usuarios legítimos); limita fuentes de registro sospechosas.

Listas de verificación / plan paso a paso

Checklist A: Si eliges relay autenticado (recomendado para la mayoría de equipos)

1. Elige la identidad de envío: Decide el dominio From y si usarás un subdominio operativo (por ejemplo, mail.example.com) para separación operativa.
2. Publica SPF: Autoriza al proveedor de relay (include o rangos de IP explícitos). Mantén bajo 10 búsquedas DNS.
3. Habilita DKIM con tu dominio: Prefiere firmar con tu dominio From o un subdominio alineado. Rota claves periódicamente.
4. Publica DMARC: Empieza con p=none para observar, luego pasa a quarantine/reject cuando hayas eliminado remitentes no autorizados.
5. Configura la sumisión Postfix al relay: 587 con STARTTLS y SASL auth. Usa credenciales estables y gestión de secretos.
6. Establece límites de reintento claros: Si el relay devuelve 250 queued, no reintentes en la capa de aplicación.
7. Implementa manejo de rebotes: Analiza DSNs y eventos del proveedor; suprime rebotes persistentes automáticamente.
8. Monitorea señales de entregabilidad: tasas de deferidos, quejas de spam, rechazos por dominio.

Checklist B: Si eliges envío directo (ahora operas un sistema de correo)

1. IPs de egreso estables: Sin IPs rotativas. Sin sorpresas de autoscaling. IPs dedicadas si es posible.
2. Control de rDNS/PTR: PTR existe, forward coincide, hostname es sensato.
3. SPF autoriza tus IPs: Mantén el registro estricto; no abuses de “~all” para evitar ambigüedad eterna.
4. DKIM firmado en todo el saliente: Asegura que sistemas intermedios no rompan firmas.
5. Política DMARC: Alinea From con SPF/DKIM y avanza hacia aplicación de políticas.
6. Afinamiento de colas y límites: Límites de concurrencia por dominio, backoff sensato, evita picos.
7. Gestión de abusos: Quejas, bajas, listas de supresión y un proceso humano real.
8. Monitorización: Profundidad de cola, deferidos por dominio, códigos de rebote, chequeos de listas negras, errores TLS.
9. Plan de warming: Incrementa volumen gradualmente; empieza con destinatarios comprometidos y tráfico transaccional crítico.

Paso a paso: migrar de envío directo a relay autenticado sin caos

1. Inventario de remitentes: Encuentra cada sistema que envía correo (apps, cron jobs, impresoras, servidores legacy). Sí, impresoras.
2. Centraliza la sumisión: Obliga a todos los remitentes a someterse a un MTA local o a una puerta de relay.
3. Configura relayhost: Actualiza relayhost de Postfix y ajustes SASL; prueba con un flujo de correo de bajo riesgo.
4. Actualiza SPF/DKIM: Autoriza el relay y asegura que DKIM se alinee con el From visible.
5. Habilita reportes DMARC: Observa quién aún envía directo o te suplanta.
6. Cutover por clase de mensaje: Restablecimientos de contraseña primero, luego notificaciones, luego bulk. No cambies todo a la vez salvo que disfrutes la adrenalina.
7. Elimina el egreso directo: Bloquea el 25 saliente desde redes de aplicaciones para evitar bypass.
8. Rastrea IDs de mensaje de extremo a extremo: Correlaciona app request ID → local queue ID → provider queue ID.

Preguntas frecuentes

1) Si uso un relay autenticado, ¿sigo necesitando SPF/DKIM/DMARC?

Sí. El relay resuelve transporte y reputación infraestructural, no identidad. Los receptores siguen evaluando la autenticación y alineación de tu dominio. Sin ello, caerás en spam o te rechazarán bajo ecosistemas DMARC estrictos.

2) ¿El envío directo siempre es peor para la entregabilidad?

No. El envío directo puede ser excelente si tienes IPs estables, DNS correcto, envío disciplinado y monitorización real. Lo que ocurre es que muchos equipos lo eligen accidentalmente y lo operan de forma casual, y así empeora.

3) ¿Por qué mis mensajes se aceptan (250) pero nunca aparecen?

Porque la aceptación SMTP significa “encolado”, no “en la bandeja de entrada”. Después de la aceptación, filtros de contenido, reputación y políticas aún deciden la colocación. Necesitas visibilidad de eventos downstream (eventos del proveedor o rebotes receptor) para saber qué pasó.

4) ¿Debo enviar transaccional y marketing desde el mismo dominio/IP?

Mejor separarlos. Usa subdominios o pools de IP separados. El tráfico de marketing tiene dinámica de quejas diferente y puede arrastrar la reputación del correo transaccional, que es el flujo que no puedes permitirte perder.

5) ¿IPv6 ayuda o perjudica?

PUEDE ayudar si se configura correctamente (IPv6 estable, rDNS adecuado, includes SPF y envío consistente). Puede perjudicar si accidentalmente comienzas a enviar desde una dirección IPv6 inruteable o sin reputación que nadie calentó. Si no estás seguro, desactiva IPv6 saliente para SMTP hasta validarlo.

6) ¿Puedo omitir rDNS si uso un relay?

Normalmente sí, porque los receptores ven la IP y rDNS del relay, no la tuya. Pero tu entorno local aún necesita DNS sensato para su propio hostname y operaciones TLS; no operes con DNS roto y esperes estabilidad.

7) ¿Qué política DMARC debería empezar?

Empieza con p=none para recopilar reportes y descubrir quién envía como tu dominio. Pasa a quarantine y luego a reject una vez que hayas alineado remitentes legítimos y eliminado los no autorizados.

8) ¿Cuál es la configuración más simple “para no ser bloqueado” para una pequeña app de producción?

Relay autenticado en 587 con TLS y AUTH, SPF autorizando el relay, DKIM firmando alineado con tu dominio From y un registro DMARC. Añade supresión de rebotes. Mantén tu dominio From estable y evita cambiarlo cada semana.

9) ¿Cómo sé si me están limitando la tasa o me están bloqueando?

Mira los códigos de respuesta SMTP. Los deferidos suelen ser 4xx con texto sobre throttling o límites temporales. Los bloqueos suelen ser 5xx con pistas sobre política o reputación. De cualquier forma, registra y analiza por dominio destinatario.

10) ¿Aún es útil ejecutar Postfix local si uso un relay?

Sí. Un MTA local te da buffering, reintentos y una interfaz de sumisión limpia para apps. También te proporciona logs que controlas. Simplemente mantenlo simple: reenvía todo; no permitas que las apps “vayan directas” por el lado.

Conclusión: qué hacer a continuación, en términos de producción

Si quieres el enfoque que no te bloquee, elige relay autenticado a menos que tengas una razón específica y recursos para operar envío directo. No es cobardía; es control de costes. El trabajo de entregabilidad es trabajo real.

Próximos pasos que dan resultados inmediatos:

1. Elige una ruta de egreso por cada clase de correo (transaccional, bulk, interno) y hazla cumplir.
2. Haz coherente la identidad: SPF autoriza al remitente, DKIM firma como el dominio From (o subdominio alineado), DMARC coincide con tu tolerancia al riesgo.
3. Añade trazabilidad: correlaciona IDs de mensaje app → MTA → proveedor para que “¿dónde está mi correo?” sea una consulta, no una sesión de espiritismo.
4. Monitorea las métricas correctas: deferidos, rechazos por dominio, profundidad de cola y códigos de rebote. No “correos enviados”.
5. Deja de optimizar la capa equivocada: no luches contra SMTP con reintentos de aplicación. Respeta la cola.

Puedes sofisticarte más después. Primero, haz que te entreguen.