Correo: HELO/EHLO incorrecto — arréglalo antes de que los proveedores te limiten

Tu correo saliente “funciona” hasta que deja de hacerlo. Y entonces una mañana el equipo de Ventas informa que las propuestas llegan con horas de retraso,
los restablecimientos de contraseña aparecen después de que el usuario ha pulsado “reenviar” doce veces con rabia, y tu monitorización está en verde porque la cola
técnicamente se está procesando… simplemente no a una velocidad humana.

Una de las causas más silenciosas es también de las más tontas: tu servidor SMTP se presenta con un nombre HELO/EHLO falso.
Los grandes proveedores lo notan. Algunos te limitan. Otros te rechazan por completo. Y lo peor es que puedes operar así
durante meses—hasta que un ajuste de política, un tropiezo de reputación de IP o un nuevo pool de relays convierte tu “misconfig menor” en
un incidente.

Para qué se usa realmente HELO/EHLO (y por qué a los proveedores les importa)

SMTP empieza con presentaciones. El cliente se conecta, el servidor muestra un banner y luego el cliente dice ya sea:
HELO (clásico) o EHLO (SMTP extendido). Esa única línea incluye un “nombre” que el cliente
afirma como su identidad. No es autenticación. No es una prueba criptográfica. Es una declaración—a menudo honesta, a veces descuidada,
ocasionalmente maliciosa.

Los proveedores receptores todavía se preocupan porque HELO/EHLO actúa como una señal barata y temprana. Es parte de una historia de consistencia más amplia:
¿el rDNS de la IP que se conecta parece sensato, se alinea con el nombre reclamado, el nombre del certificado TLS coincide con
la identidad presentada, el dominio del remitente tiene SPF, DKIM pasa, DMARC se alinea, el comportamiento coincide con el historial?
HELO/EHLO es un hilo en ese tapiz. Un hilo desgastado no siempre te hunde. Bastantes hilos desgastados, y te mandan al carril lento.

En la práctica, los proveedores tratan un HELO/EHLO incorrecto como una de estas situaciones:

• Infraestructura mal configurada (no maliciosa, pero poco profesional)
• Host comprometido (un PC de escritorio fingiendo ser un servidor de correo)
• Remitente masivo que recorta esquinas (porque las esquinas son donde la entregabilidad muere)

¿Qué cuenta como “malo”? Los grandes éxitos:

• HELO/EHLO es localhost, localhost.localdomain o algún nombre interno.
• HELO/EHLO es un literal IP o una IP entre corchetes cuando no debería serlo.
• HELO/EHLO es un dominio sin registro A/AAAA.
• HELO/EHLO es un dominio que resuelve, pero no coincide con las expectativas de rDNS.
• HELO/EHLO cambia de forma impredecible entre reintentos o entre miembros de un pool de relays.

Si gestionas correo en producción, quieres que el lado receptor vea un nombre de dominio totalmente calificado (FQDN) estable, enrutable y que controles,
con DNS directo e inverso coincidentes cuando sea posible. No porque una RFC exija perfección, sino porque la entregabilidad es un ecosistema
de heurísticas, y tú no decides las reglas.

Datos e historia relevantes

Seis a diez puntos rápidos, porque la historia explica las políticas raras de hoy:

1. HELO precede a la mayor parte del pensamiento anti-spam moderno. El SMTP temprano asumía redes cooperativas; la “identidad” servía sobre todo para registros y saneamiento de ruteo.
2. EHLO llegó con ESMTP para negociar características. No es solo un saludo; desbloquea extensiones como SIZE y STARTTLS según el servidor.
3. El DNS inverso se volvió una herramienta contra el abuso en la era del spam. Los proveedores apoyaron rDNS porque mantenerlo consistemente era costoso para las botnets.
4. Algunos receptores siguen tratando la “ausencia de PTR” como sospechosa. No siempre es una violación de RFC, pero hay una fuerte correlación con fuentes de correo basura.
5. Los cheques HELO existían en configuraciones de MTA mucho antes de SPF. Muchos conjuntos de reglas de Postfix/Sendmail usaban comprobaciones de sanidad de HELO como filtrado barato.
6. Los sistemas de reputación de IP incorporan anomalías en el saludo. Un EHLO de localhost desde una IP pública parece un host comprometido, porque a menudo lo es.
7. TLS complicó la identidad. Ahora tienes nombre de banner, nombre EHLO y nombre en el certificado; las inconsistencias pueden penalizar en los puntajes.
8. La escalabilidad en la nube aumentó las probabilidades de desajuste. Pools autoescalados y nombres efímeros facilitan desplegar un MTA que “funciona” pero se presenta mal.
9. La entregabilidad se volvió crítica para el producto. Los restablecimientos de contraseña y los códigos MFA no son “email de marketing”; la limitación se convierte en un problema de disponibilidad.

Cómo falla un HELO/EHLO erróneo en producción

1) Limitación suave que parece “lentitud aleatoria”

Muchos proveedores prefieren limitar en lugar de rechazar. Aceptarán un pequeño goteo y diferirán el resto con fallos temporales
(respuestas 4xx). Tu MTA reintenta. La cola crece. Eventualmente, los usuarios se quejan.

La pista de humo no es una caída total; es un acantilado en el tiempo hasta la entrega. Y porque los reintentos pueden “tener éxito finalmente,” en ocasiones
el on-call se encoge de hombros y vuelve al “verdadero” incidente. Ese encogimiento convierte un mal ajuste en un modo de vida permanente.

2) Rechazos duros con mensajes crípticos

Algunos receptores rechazan con “bad HELO” o “invalid hostname,” que al menos es honesto. Otros devuelven fallos de política vagos.
Si tus logs no conservan el texto de la respuesta remota, lo diagnosticarás mal como “el proveedor es inestable.”

3) Decaimiento de reputación: no lo notas hasta que lo notas

Un EHLO incorrecto puede tolerarse cuando la reputación de tu IP/dominio es impecable. Más tarde, una cuenta comprometida envía un pico de correo sospechoso,
o una nueva IP de salida se calienta mal, y de pronto el puntaje del receptor cambia. Tu misconfig de HELO se vuelve la excusa conveniente para penalizarte.

4) Las incoherencias de TLS e identidad se suman

Si tu EHLO dice mail.example.com pero tu certificado TLS es para smtp-out.example.net, y tu PTR es
ec2-203-0-113-10.compute-1.amazonaws.com, has construido un pequeño museo de incoherencias. Ninguna coincidencia única es siempre fatal.
La colección sí lo es.

Idea parafraseada de Werner Vogels (CTO de Amazon): “Todo falla todo el tiempo; diseña para detectar y recuperarte.” La identidad en correo es parte de la detección—solo que en el lado del receptor.

Broma #1: Que tu servidor de correo diga “HELO localhost” es como presentarte a una reunión con un cliente con una tarjeta que dice “Hola, soy otra persona.”
Nadie es arrestado, pero nadie confía en ti.

Guía de diagnóstico rápido

Cuando la entrega se vuelve lenta o los rebotes suben, no empieces rotando claves API o culpando al DNS “en general.” Haz esto, en orden, y normalmente
encontrarás el cuello de botella en menos de 20 minutos.

Primero: confirma si el receptor te está difiriendo o rechazando

• Revisa los registros salientes para deferrals 4xx y su texto.
• Identifica los dominios receptores principales que están siendo diferidos (Gmail, Microsoft, Yahoo, dominios corporativos personalizados).
• Confirma si los mismos destinatarios tienen éxito horas después (comportamiento clásico de throttling).

Segundo: captura la conversación SMTP exacta que tu cliente presenta

• El banner que recibes del remoto.
• Tu cadena EHLO/HELO.
• Si STARTTLS cambia algo.
• Si el remoto se queja explícitamente sobre HELO/EHLO.

Tercero: verifica la alineación de identidad (EHLO ↔ DNS directo ↔ DNS inverso ↔ TLS)

• ¿Resuelve el nombre EHLO (A/AAAA)?
• ¿La IP que se conecta tiene PTR, y parece sensato?
• ¿El PTR resuelve de nuevo a la IP conectante (forward-confirmed reverse DNS), cuando es factible?
• ¿El nombre del certificado TLS es consistente con lo que afirmas ser?

Cuarto: revisa la configuración del MTA y el enrutamiento del remitente

• ¿Usas múltiples relays o IPs de salida NAT?
• ¿Tu HELO está sobrescrito por transporte, por remitente, o por relayhost?
• ¿Alguna “optimización” lo cambió recientemente (imagen de contenedor, plantilla de autoscaling, nuevo relay)?

Quinto: solo entonces persigue SPF/DKIM/DMARC

Eso importa enormemente. Pero cuando depuras throttling que empezó justo después de mover IPs de salida o reconstruir nodos de correo,
HELO/EHLO y DNS inverso son la victoria más rápida. Asegura tu presentación antes de negociar confianza.

Tareas prácticas: comandos, salidas, decisiones

Estas son comprobaciones reales que puedes ejecutar desde un host de correo o una caja de diagnóstico cercana. Cada tarea incluye:
un comando, salida de ejemplo, qué significa y qué decisión tomar.

Task 1: Ver qué envía tu servidor como EHLO (desde logs)

cr0x@server:~$ sudo grep -R "EHLO" /var/log/mail.log | tail -n 5
Jan 03 09:12:41 mx1 postfix/smtp[22104]: <remote>: EHLO localhost
Jan 03 09:13:02 mx1 postfix/smtp[22177]: <remote>: EHLO mx1.internal
Jan 03 09:13:30 mx1 postfix/smtp[22230]: <remote>: EHLO mail.example.com
Jan 03 09:14:05 mx1 postfix/smtp[22301]: <remote>: EHLO localhost.localdomain
Jan 03 09:14:40 mx1 postfix/smtp[22392]: <remote>: EHLO mail.example.com

Qué significa: Tus clientes presentan valores EHLO inconsistentes: localhost, nombres internos y un FQDN correcto.

Decisión: Elimina la aleatoriedad. Configura un único nombre EHLO estable para SMTP saliente y asegúrate de que todos los nodos lo usen.

Task 2: Reproducir la conversación SMTP con OpenSSL (STARTTLS)

cr0x@server:~$ openssl s_client -starttls smtp -crlf -connect gmail-smtp-in.l.google.com:25 -servername gmail-smtp-in.l.google.com < /dev/null
CONNECTED(00000003)
---
220 mx.google.com ESMTP
---
no peer certificate available
---

Qué significa: Puedes alcanzar el puerto 25 y obtener un banner. Esto solo prueba conectividad, no tu EHLO. Necesitas hablar SMTP realmente.

Decisión: Usa una sesión interactiva para enviar EHLO y observar las respuestas del servidor (siguiente tarea).

Task 3: Hablar SMTP interactivamente y ver si EHLO dispara la política

cr0x@server:~$ nc -v gmail-smtp-in.l.google.com 25
Connection to gmail-smtp-in.l.google.com 25 port [tcp/smtp] succeeded!
220 mx.google.com ESMTP
EHLO localhost
550-5.7.1 Invalid HELO/EHLO domain. See https://support.google.com/mail/?p=InvalidHelo
550 5.7.1 Bad HELO/EHLO

Qué significa: El receptor rechaza explícitamente tu valor EHLO. No es una historia fantasmal de reputación; es una misconfiguración concreta.

Decisión: Corrige el nombre EHLO inmediatamente. Hasta entonces, los reintentos no ayudarán; estás recibiendo un bloqueo por política.

Task 4: Validar que el nombre EHLO resuelve (DNS directo)

cr0x@server:~$ dig +short A mail.example.com
203.0.113.10

Qué significa: El nombre EHLO tiene un registro A. Eso es lo mínimo.

Decisión: Sigue adelante: también comprueba AAAA y si esta IP es realmente tu egress.

Task 5: Comprobar presencia de AAAA (no te sorprendas con IPv6)

cr0x@server:~$ dig +short AAAA mail.example.com

Qué significa: No hay registro IPv6. Está bien si no envías por IPv6. También es una pista: si estás enviando por IPv6, podrías estar usando un nombre/ruta diferente.

Decisión: Confirma qué familia IP usa realmente tu MTA para alcanzar a los principales proveedores.

Task 6: Identificar la IP saliente real (no adivines)

cr0x@server:~$ curl -s ifconfig.me
203.0.113.10

Qué significa: La IP pública de egress por defecto de este host es 203.0.113.10 (al menos para HTTP). SMTP aún podría diferir si tienes enrutamiento de políticas o un relay.

Decisión: Cruza esta información con logs y reglas NAT/firewall; no asumas que “curl IP” es igual a “SMTP IP.”

Task 7: Comprobar DNS inverso (PTR) para la IP saliente

cr0x@server:~$ dig +short -x 203.0.113.10
mail.example.com.

Qué significa: El PTR apunta a mail.example.com. Este es el camino bueno: la IP reclama un nombre que controlas.

Decisión: Asegura que tu nombre EHLO coincide con este PTR (o al menos esté en el mismo dominio controlado con DNS directo consistente).

Task 8: Comprobar DNS inverso confirmado por directo (FCrDNS)

cr0x@server:~$ host mail.example.com
mail.example.com has address 203.0.113.10

Qué significa: PTR → nombre, y nombre → misma IP. Muchos receptores valoran esta simetría.

Decisión: Si esto falla, arregla el DNS antes de ajustar el MTA. Los receptores usan esto como pista de confianza.

Task 9: Inspeccionar qué piensa Postfix de tu hostname/HELO

cr0x@server:~$ sudo postconf -n | egrep '^(myhostname|mydomain|smtp_helo_name|smtp_helo_timeout|smtp_host_lookup|inet_protocols)'
myhostname = mx1.internal
mydomain = internal
inet_protocols = all

Qué significa: Tu myhostname es un nombre solo interno, y no has establecido smtp_helo_name. Postfix puede usar $myhostname como EHLO. Así es como terminas diciendo “hola, soy mx1.internal” a Gmail.

Decisión: Establece myhostname a un FQDN público o configura smtp_helo_name al FQDN público usado para los saludos salientes (a menudo es más seguro cuando la nomenclatura interna debe permanecer).

Task 10: Aplicar una corrección segura de EHLO en Postfix (y verificar)

cr0x@server:~$ sudo postconf -e 'smtp_helo_name = mail.example.com'
cr0x@server:~$ sudo systemctl reload postfix
cr0x@server:~$ sudo postconf smtp_helo_name
smtp_helo_name = mail.example.com

Qué significa: El SMTP saliente debería usar ahora mail.example.com para EHLO.

Decisión: Retesta inmediatamente con una sesión SMTP remota (Task 3), y observa cambios en la respuesta de la política.

Task 11: Confirmar la configuración HELO de Exim (si usas Exim)

cr0x@server:~$ sudo exim -bP helo_data
helo_data = 

Qué significa: No hay una anulación explícita de HELO configurada. Exim la derivará del hostname del sistema en muchas configuraciones.

Decisión: Si el hostname del sistema es interno o inestable, establece un helo_data consistente a un FQDN público y asegúrate de que el DNS coincida.

Task 12: Verificar que el hostname del sistema no te sabotee

cr0x@server:~$ hostname -f
mx1.internal

Qué significa: Tu OS cree que su FQDN es interno. Muchos MTAs toman esto por defecto para los saludos a menos que se sobrescriba.

Decisión: O corrige el FQDN del host a un nombre público (si procede) o configura explícitamente el nombre helo del MTA para el tráfico saliente.

Task 13: Comprobar qué presentas en el lado receptor (banner vs EHLO)

cr0x@server:~$ sudo postconf -n | egrep '^(smtpd_banner|myhostname)'
myhostname = mx1.internal
smtpd_banner = $myhostname ESMTP

Qué significa: Tu banner entrante anuncia mx1.internal. Eso no es lo mismo que EHLO, pero es otra superficie de identidad. Algunos receptores y escáneres correlacionan estas señales cuando tu servidor actúa como cliente en otros lados (relays, cadenas smarthost).

Decisión: Si este host es accesible públicamente, corrige myhostname y el banner. Si es solo salida detrás de un relay, prioriza EHLO saliente pero evita exponer dominios internos si es posible.

Task 14: Confirmar que no estás enviando accidentalmente por IPv6 con rDNS roto

cr0x@server:~$ postconf -n | grep inet_protocols
inet_protocols = all

Qué significa: Postfix puede usar IPv6. Si tu red tiene egress IPv6 pero sin PTR para la dirección v6, puedes ser limitado o bloqueado de maneras que parecen “aleatorias,” porque algunos destinos prefieren v6.

Decisión: Si no puedes mantener rDNS y reputación IPv6 todavía, considera temporalmente inet_protocols = ipv4 mientras arreglas v6 correctamente.

Task 15: Observar la presión real de la cola mientras arreglas la identidad

cr0x@server:~$ mailq | head -n 20
-Queue ID-  --Size-- ----Arrival Time---- -Sender/Recipient-------
3F2A81C04E*     2199 Fri Jan  3 09:10:12  noreply@example.com
                                         user@gmail.com
                                         (host gmail-smtp-in.l.google.com[142.250.102.26] said: 550 5.7.1 Bad HELO/EHLO (in reply to EHLO command))

Qué significa: La cola registra explícitamente el rechazo remoto ligado a EHLO. Esa es la causa raíz en texto claro.

Decisión: Corrige EHLO y luego vacía la cola selectivamente. No purgues a ciegas—tus usuarios quieren su correo.

Task 16: Después de arreglar, fuerza un reintento y confirma la aceptación

cr0x@server:~$ sudo postqueue -f
cr0x@server:~$ sudo tail -n 20 /var/log/mail.log
Jan 03 09:22:10 mx1 postfix/smtp[24511]: 3F2A81C04E: to=<user@gmail.com>, relay=gmail-smtp-in.l.google.com[142.250.102.26]:25, delay=716, delays=715/0.01/0.2/0.3, dsn=2.0.0, status=sent (250 2.0.0 OK  1704273730 a1-20020a170902d1c100b003d7f9c0d1a9si1234567plb.123 - gsmtp)

Qué significa: El mensaje fue aceptado (2.0.0). Probablemente tu corrección funcionó. El retraso largo refleja el tiempo que estuvo fallando antes de la corrección.

Decisión: Monitoriza la mejora sostenida: profundidad de cola, tasas de deferral por dominio y tasas de quejas. Un envío exitoso no es una tendencia.

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

1) Síntoma: Gmail rechaza con “Bad HELO/EHLO”

Causa raíz: EHLO es localhost, dominio interno o inválido (sin punto, sin DNS).

Solución: Configura el HELO/EHLO saliente a un FQDN público que controles (Postfix: smtp_helo_name; Exim: helo_data), y asegúrate que resuelva.

2) Síntoma: Microsoft 365 acepta algo de correo y luego difiere mucho (4xx)

Causa raíz: Identidad inconsistente: EHLO rota entre nombres/nodos/IPs, o EHLO no se alinea con PTR/reputación.

Solución: Estandariza EHLO en el pool de envío y alinea el DNS inverso por cada IP. Si usas múltiples IPs de salida, cada una debe tener PTR sensato en la misma familia de dominio.

3) Síntoma: Entregabilidad bien durante semanas, luego de pronto lenta tras una reconstrucción

Causa raíz: La nueva imagen/plantilla revirtió el hostname a localhost.localdomain o cambió el comportamiento de cloud-init. El MTA ahora se presenta mal.

Solución: Codifica el HELO en la gestión de configuración. Añade una prueba de integración post-despliegue que hable SMTP y verifique la cadena EHLO.

4) Síntoma: Solo algunos destinos fallan, otros bien

Causa raíz: Diferentes proveedores tienen diferentes exigencias sobre HELO; algunos son permisivos, otros no. O estás en dual-stack y solo la ruta IPv6 falla.

Solución: Revisa logs por dominio y confirma qué familia IP se usa. Si IPv6 es el culpable, arregla rDNS v6 o fuerza temporalmente IPv4.

5) Síntoma: El receptor dice “HELO name does not resolve”

Causa raíz: Tu nombre EHLO no tiene registro A/AAAA, o el DNS de horizonte dividido significa que solo resuelve internamente.

Solución: Publica DNS público para el nombre EHLO. No uses una zona solo interna para la identidad SMTP pública.

6) Síntoma: Los receptores se quejan de “invalid hostname” incluso con un FQDN

Causa raíz: Usaste guiones bajos, caracteres ilegales o un nombre que viola reglas básicas de hostname.

Solución: Usa un hostname DNS simple: letras, dígitos, guiones y puntos. Nada de guiones bajos. Manténlo aburrido.

7) Síntoma: “Arreglé” EHLO pero la limitación persiste

Causa raíz: La reputación de la IP está dañada ahora, o tu PTR/TLS/SPF todavía está desalineado. HELO fue uno de varios castigos.

Solución: Verifica rDNS y coherencia TLS, luego evalúa alineación SPF/DKIM/DMARC y patrones de envío. Espera un período de calentamiento si cambiaste señales de identidad recientemente.

8) Síntoma: Todo funciona desde un nodo, falla desde otro

Causa raíz: Los nodos del pool tienen configuraciones divergentes: hostname, parámetros del MTA, egress NAT o comportamiento del resolver DNS.

Solución: Trata la configuración de identidad del MTA como infraestructura inmutable. Audita todos los nodos, diferencia configuraciones y aplica con CI/CD.

Tres mini-historias corporativas desde el frente del correo

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

Una empresa SaaS mediana movió el correo saliente de un par de mascotas (VMs gestionadas a mano) a un pequeño pool autoescalado.
El equipo hizo las cosas grandes correctamente: firmado DKIM, actualizaciones SPF, política DMARC en modo monitor, monitorización de colas.
Asumieron que el saludo era “solo cosmético.” No lo era.

Las nuevas imágenes provenían de una base endurecida. Cosas buenas: sysctls estilo CIS, SSH restringido, logging sensato.
Pero la base también configuraba el hostname del sistema al ID de instancia. Postfix lo recogió. El pool se presentó al mundo
como ip-10-2-3-4 y a veces como localhost según el arranque y cloud-init.

Durante una semana nadie lo notó. La mayoría de destinatarios corporativos eran permisivos, y el volumen no era enorme.
Luego un gran proveedor empezó a diferir más agresivamente, y el backoff de reintentos hizo lo que hace: construyó una cola.
Llegaron tickets de soporte con la peor frase en operaciones: “intermitente.”

El on-call intentó límites de tasa, añadió más nodos y vio la cola crecer—porque escalar una misconfiguración es convertir un bug en un modo de vida.
Finalmente alguien sacó una transcripción SMTP cruda y vio el EHLO. La corrección tomó cinco minutos. La gira de disculpas, dos días.

La lección no fue “lee la RFC.” Fue más simple: nunca asumas que las superficies de identidad son cosméticas. En correo, las señales “cosméticas” a menudo son las únicas señales que tienen los receptores.

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

Una empresa financiera quería mayor throughput saliente para estados y alertas sensibles al tiempo. Su equipo de correo afinó concurrencia y pipelining,
y desplegó múltiples IPs de egress para distribuir carga. En papel: buena ingeniería.

Luego “optimizaron” el HELO para que fuera único por nodo, pensando que ayudaría en la depuración. Cada servidor se presentaba como
mx-out-01.example.com, mx-out-02.example.com, etc. Olvidaron el detalle desagradable: el DNS inverso solo se actualizó para la mitad de las IPs,
y algunos nombres EHLO ni siquiera existían aún en DNS público.

En días, la entregabilidad se volvió desigual. Algunos destinatarios recibían correo al instante, otros horas después. El nuevo comportamiento creó una narrativa falsa:
“Debe ser filtrado por contenido.” Así que retocaron plantillas y encabezados y se metieron en un callejón equivocado.

La historia real fue que aumentaron la varianza de identidad mientras incrementaban el volumen de envío. Eso es exactamente cuando los proveedores aprietan.
Más IPs más más nombres EHLO multiplicaron las oportunidades de desajuste.

La solución final fue poco llamativa: reducir el conjunto de HELO a un único nombre estable, alinear PTR para cada IP saliente y desplegar cambios con un nodo canario.
La “optimización” para depuración hizo el sistema más difícil de depurar porque del lado receptor comenzaron a tratarlos como remitentes inconsistentes.

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

Una organización de salud gestionaba su propio relay saliente porque necesitaban control estricto para auditoría y manejo de mensajes.
Fueron conservadores: un nombre primario, propiedad documentada del DNS, gestión de configuración estricta, cambios lentos y constantes.
Nadie fue promovido por ello. Eso suele ser buena señal.

Un trimestre, tuvieron que rotar IPs de salida por un cambio de proveedor de red. Aquí es donde las organizaciones normalmente se derriten:
los cambios de PTR tardan, la reputación de la IP antigua se evapora, y el consejo “solo actualiza DNS” de cada proveedor queda incompleto.

Tenían una checklist que incluía la alineación de HELO como elemento de primera clase: las nuevas IPs recibieron PTR apuntando a mail.example.org,
el DNS directo ya mapeaba ese nombre a la IP correcta, y Postfix tenía smtp_helo_name fijado.
También tenían un canario: un relay de bajo volumen tomó la nueva ruta primero.

Cuando un proveedor empezó a diferir el tráfico del canario, lo detectaron temprano, limitaron el radio de daño y ajustaron reduciendo temporalmente la concurrencia
para ese destino mientras la reputación se calentaba. La pool principal nunca tuvo una crisis de colas.

Su práctica “aburrida” fue simplemente tratar la identidad SMTP como un contrato de interfaz, no como una sugerencia. No evitó todo el dolor, pero lo hizo contenible.

Broma #2: La entregabilidad del correo es como la fontanería—nadie quiere pagar por ella, y todos lo notan en cuanto huele raro.

Listas de verificación / plan paso a paso (despliegue seguro)

Plan paso a paso: arreglar HELO/EHLO sin crear un segundo incidente

1. Elige un nombre de identidad saliente único.
   • Usa un FQDN estable que controles, como mail.example.com o smtp.example.com.
   • Evita nombres por nodo a menos que tengas razones fuertes y una higiene DNS igualmente fuerte.
2. Asegura que el nombre resuelva públicamente.
   • Publica A (y AAAA si envías por IPv6) para el nombre elegido.
   • No dependas de DNS de horizonte dividido para una identidad orientada a internet.
3. Alinea DNS inverso para cada IP saliente.
   • Configura PTR hacia un hostname dentro de tu familia de dominio.
   • Prefiere PTR que coincida exactamente con tu EHLO, o al menos que coincida con el namespace de tu dominio de envío.
4. Establece explícitamente el HELO saliente del MTA.
   • Postfix: configura smtp_helo_name.
   • Exim: configura helo_data (y verifica por transporte si hace falta).
5. Audita la consistencia del pool.
   • Compara postconf -n entre nodos.
   • Confirma que ningún nodo usa un resolvador o dominio de búsqueda distinto que altere la resolución del hostname.
6. Haz canary con el cambio.
   • Redirige un pequeño porcentaje de correo saliente a través de un nodo o una IP de egress con el HELO corregido.
   • Observa deferrals y rebotes por dominio destino.
7. Despliega gradualmente y luego vacía colas con cuidado.
   • Tras la corrección, puedes postqueue -f, pero ojo con límites de tasa: podrías golpear proveedores y provocar nueva limitación.
   • Considera vaciado escalonado por destino si los volúmenes son grandes.
8. Añade una prueba de regresión.
   • En CI o post-despliegue, ejecuta una conversación SMTP contra un receptor de prueba que verifique la cadena EHLO.
   • Haz que falle la construcción si EHLO contiene localhost o un sufijo interno.

Lista operativa: cómo se ve “bien”

• El nombre EHLO es un FQDN válido, estable entre reintentos y nodos.
• El nombre EHLO tiene registros A/AAAA públicos.
• La IP saliente tiene PTR sensato y, preferiblemente, alineado con EHLO.
• El hostname PTR resuelve de nuevo a la IP de salida (FCrDNS).
• El nombre del certificado TLS es coherente con la identidad de correo (especialmente si terminas TLS tú mismo).
• Los logs conservan las cadenas de respuesta remotas para rechazos/deferrals (para ver “Bad HELO” en vez de “delivery failed”).
• La monitorización de colas incluye tasas de deferral por destino (porque solo “tamaño de cola” es un mentiroso).

Preguntas frecuentes

1) ¿HELO/EHLO es lo mismo que el dominio en el encabezado “From:”?

No. HELO/EHLO es el saludo del cliente SMTP. “From:” es un encabezado del mensaje que ven los usuarios.
Los receptores correlacionan muchas identidades, pero son capas diferentes y pueden diferir legítimamente (relays, remitentes terceros, etc.).

2) Si tengo SPF/DKIM/DMARC, ¿puedo ignorar HELO/EHLO?

No. La autenticación ayuda, pero los proveedores puntúan la consistencia. Un EHLO roto sigue siendo un signo de infraestructura descuidada o malware.
Intentas parecer un sistema de correo real, no ganar una discusión técnica con una RFC.

3) ¿Qué debería poner como nombre EHLO en Postfix?

Normalmente un FQDN estable único como mail.example.com. En Postfix, establece smtp_helo_name a ese valor.
Asegúrate de que resuelva públicamente y de que se alinee con el PTR de tu IP saliente.

4) ¿EHLO debería coincidir exactamente con el DNS inverso?

“Debería” depende de tu entorno, pero la coincidencia exacta es la opción menos controvertida.
Si no puedes hacerlo exacto (múltiples IPs, restricciones del proveedor), mantenlo dentro de la misma familia de dominio y conserva el DNS consistente.

5) ¿Puedo usar una dirección IP en HELO/EHLO?

Evítalo. Algunos sistemas aceptan literales de dirección entre corchetes, pero muchos receptores lo tratan como sospechoso.
Usa un FQDN válido con DNS apropiado en su lugar.

6) Mis hostnames son internos por política. ¿Puedo mantenerlos así?

Puedes mantener el hostname del SO interno y aun así presentar un EHLO público para SMTP saliente configurándolo explícitamente en el MTA.
Eso suele ser el compromiso más limpio entre políticas de nombres internas y la realidad de entregabilidad externa.

7) ¿Por qué esto se rompió “de repente” si estaba mal durante meses?

Porque los receptores cambian su puntuación, tus patrones de tráfico cambian y la reputación de tu IP cambia. Una penalidad menor se vuelve decisiva cuando otras señales se degradan.
También: cambios de infraestructura (nuevas imágenes, nuevo NAT, activación de IPv6) pueden alterar silenciosamente el nombre de saludo.

8) ¿Y el SMTP entrante—importa mi smtpd_banner?

Sí, especialmente si tu servidor es accesible públicamente. Un banner que anuncie localhost o nombres internos parece amateur y puede influir en cómo otros MTAs te tratan.
No es lo mismo que el EHLO saliente, pero es parte de la identidad pública de tu servidor de correo.

9) ¿HELO/EHLO afecta a TLS?

Indirectamente. Algunos receptores correlacionan el nombre EHLO con nombres de certificado TLS y el comportamiento SNI.
Las discordancias se acumulan. Quieres una historia coherente: nombre, DNS, IP y certificado no deberían contradecirse.

10) Si uso un relay de terceros (smarthost), ¿me sigue importando?

Sí, pero de otra manera. Si entregas el correo a un relay, la responsabilidad de su EHLO y reputación IP controla la entrega a destinatarios finales.
Tu riesgo se desplaza a la sesión SMTP entre tú y el relay: asegura presentar una identidad sensata y no activar sus límites de política.

Conclusión: próximos pasos que puedes entregar esta semana

HELO/EHLO no es glamoroso. Es una sola línea de texto. Y puede arruinarte la semana.
Los proveedores la leen como una señal de competencia. Cuando envías “EHLO localhost,” les estás diciendo que tu infraestructura está mal gestionada o comprometida.
Ellos responden en consecuencia: limitan, difieren, rechazan.

Pasos prácticos:

1. Elige un FQDN saliente estable para EHLO y asegúrate de que resuelva públicamente.
2. Alinea PTR para cada IP saliente y confirma DNS inverso directo cuando sea factible.
3. Configura EHLO explícitamente en tu MTA (no dependas del hostname del SO por defecto).
4. Haz canary y observa deferrals/rebotes por destino antes del despliegue completo.
5. Añade una prueba de regresión para que la próxima reconstrucción no reintroduzca “localhost” en el correo de producción.

Haz ahora el trabajo aburrido de identidad. Tu canal de incidentes futuro estará más tranquilo y tus usuarios dejarán de tratar el correo como una ruleta.