Comprobar la salud de tu servidor de correo sólo para encontrar un error de «DNS inverso no coincide con el banner smtp» no es agradable de ver, ya que parece sospechoso para los servidores receptores, aunque tus intenciones sean puras.
Este error significa esencialmente que el nombre de host que tu servidor difunde cuando se presenta (el banner SMTP) no coincide con el registro de puntero (PTR) de la dirección IP de tu servidor de correo. Esta comprobación existe porque los spammers raramente controlan la infraestructura que utilizan para enviar basura, por lo que los proveedores de correo utilizan este handshake como «aval» principal de la legitimidad de tu servidor.
Naturalmente, esto plantea una pregunta importante: ¿qué importancia tiene corregir este error y qué grado de juicio se produce antes de que un correo electrónico sea aceptado para su entrega?
A continuación, desglosaremos cuándo esta advertencia afecta a la entregabilidad, cuándo es seguro ignorarla y cómo decidir si arreglarla afectará a la colocación en la bandeja de entrada o simplemente silenciará una herramienta de diagnóstico.
Lo más importante
- «El DNS inverso no coincide con el banner SMTP» significa que el nombre de host que presenta tu servidor de correo durante el handshake SMTP es diferente del nombre de host devuelto por el registro DNS inverso (PTR) de la IP remitente.
- Cuándo importa: una falta de coincidencia DNS inverso / banner SMTP a menudo puede ignorarse por sí sola, pero afecta a la entregabilidad cuando se combina con cosas como una autenticación deficiente y un bajo compromiso.
- Cómo abordar las correcciones: sólo haz coincidir el banner y el DNS si controlas la IP y el nombre de host, de lo contrario corres el riesgo de romper flujos de correo legítimos sólo para borrar un mensaje de error.
Para qué se utilizan el banner SMTP y el DNS inverso
Cuando un servidor de correo se conecta a otro servidor, lo primero que hace es anunciar un nombre de host mediante HELO o EHLO. Ese valor se convierte en el banner SMTP. Se registra inmediatamente y se vincula a la conexión antes incluso de que entren en escena la autenticación, el contenido o la reputación.
¿Por qué es importante? Porque los receptores no evalúan el correo electrónico en el vacío. Observan patrones. Con el tiempo, aprenden que un nombre de host específico procede de una IP específica, con una cadencia específica, comportándose de formas predecibles. Eso es lo que les permite clasificar el tráfico adecuadamente, en lugar de tratar cada conexión como un riesgo nuevo.
El DNS inverso contempla la misma situación desde el otro lado. En lugar de confiar en lo que afirma el servidor emisor, el servidor receptor realiza una búsqueda PTR en la IP para ver qué nombre de host le asocia la red.
Pero, si ni el banner ni el PTR demuestran nada, ¿para qué compararlos?
Porque los desajustes rara vez son aleatorios. Cuando el banner SMTP tiene una identidad y la IP resuelve a otra, los receptores empiezan a preguntarse si el remitente controla realmente su infraestructura o la está heredando indirectamente, ya sea a través de un alojamiento compartido, un espacio IP revendido o una configuración del servidor mal mantenida. Esa pregunta adquiere mayor importancia a escala, donde los malos actores también dependen de infraestructuras prestadas o desechables.
¿Significa eso que cada desajuste es un problema? No. Los entornos compartidos lo hacen constantemente, y los proveedores de inbox lo saben. Lo que causa sospechas no es la falta de coincidencia en sí, sino la falta de intención: banners por defecto, PTR genéricos, nombres rotativos o configuraciones que parecen ensambladas en lugar de operadas.
El objetivo de la comprobación es detectar si un servidor de correo tiene una identidad coherente o sólo está de paso.
Cuando los problemas de configuración se acumulan en tu contra, el compromiso es lo que realmente restablece la confianza. InboxAlly refuerza las señales de compromiso a las que prestan atención los ISP, a menudo mejor que cualquier ajuste de infraestructura. Reserva una demostración gratuita y comprueba lo que InboxAlly puede hacer por la ubicación de tu bandeja de entrada.
Cuando este error se convierte en un riesgo para la entregabilidad
IPs dedicadas frente a entornos de envío compartidos
Esta advertencia es muy común en infraestructuras compartidas. Los SMTP en nube y los pools de alojamiento compartido asignan IPs a escala, las nombran según convenciones internas y no adaptan los registros PTR a clientes individuales. Tu banner SMTP puede hacer referencia a tu dominio de envío o a un nombre de host de marca, mientras que el DNS inverso apunta a algo como mail-123.proveedor.net. Eso es normal.
Lo importante es el control.
En las IP compartidas, los receptores asumen que no eres el propietario de la nomenclatura, por lo que esperan algún desajuste y lo descuentan en consecuencia. Intentar forzar la alineación en estas configuraciones suele ser contraproducente, bien porque no puedes cambiar el PTR en absoluto, bien porque acabas anunciando una identidad que no te pertenece realmente.
Las IP dedicadas son diferentes. En este caso, los desajustes pueden ser un problema porque ahora se supone lo contrario. Si controlas la IP, los receptores esperan que también controles su nomenclatura, por lo que un banner que reclama una identidad mientras que el PTR reclama otra sugiere una configuración inacabada, restos de valores predeterminados o una infraestructura que ha sido reutilizada de forma descuidada. Obviamente, nada de esto inspira confianza.
Contraintuitivamente, es más importante que la configuración tenga sentido con el nivel de control que implica tu infraestructura que el hecho de que los nombres coincidan perfectamente.
Primero la concordancia de patrones
Esta advertencia casi nunca viene sola. Por sí sola, no suele ser motivo de preocupación. Pero lo más frecuente es que venga acompañada de otras pistas que apuntan en la misma dirección.
La falta de compromiso es el acelerador más común. Si los usuarios no abren, hacen clic o responden, los receptores empiezan a examinar todo lo demás más de cerca. Un banner desajustado que normalmente no es un problema, ahora puede crear problemas de entrega del correo electrónico.
Los problemas de autenticación, como la acumulación de SPF includes y las políticas DMARC a medio cifrar , van aún más lejos. Aunque individualmente no son fatales, juntos revelan dejadez, y el desajuste del banner encaja perfectamente en esa narrativa.
Pero probablemente el mayor indicador de todos sea la incoherencia de la identidad. Una semana, el banner utiliza un nombre de host de marca; la semana siguiente, vuelve a un nombre predeterminado. La IP sigue siendo la misma, el volumen fluctúa, los dominios rotan. Técnicamente válido, prácticamente desordenado.
Por ejemplo, un remitente que ejecuta una IP dedicada con SPF y DKIM correctamente configurados, deja el banner SMTP en el nombre de host predeterminado de Postfix, mantiene un registro PTR genérico y envía en picos de volumen semanales desiguales. No pasa nada «sobre el papel», pero la entregabilidad del correo electrónico está casi garantizada que se degradará.
¿Cuándo te arriesgas a ser penalizado?
Las penalizaciones suelen aplicarse durante las transiciones. Las IP frías no obtienen mucho beneficio de la duda, y los nuevos dominios emparejados con una infraestructura incoherente se clasifican con cautela. Incoherencias como éstas ralentizan la formación de confianza cuando ésta es de suma importancia.
Causas comunes que verás
Rara vez ves esta advertencia porque alguien haya hecho algo escandaloso. La mayoría de las veces, se debe a un puñado de montajes muy ordinarios que salieron lo suficientemente mal como para parecer descuidados.
- PTR genéricos establecidos por los proveedores de alojamiento. La mayoría de los proveedores de alojamiento asignan los ajustes de DNS inverso automáticamente y nunca vuelven a revisarlos. El PTR apunta a un nombre de host propiedad del proveedor, mientras que el banner SMTP utiliza algo personalizado. Eso está bien en infraestructuras compartidas, pero no tanto en IP dedicadas.
- Banners SMTP por defecto desmarcados. Postfix anunciando mail.localdomain o exchange exponiendo un nombre de host interno sigue siendo escandalosamente común, a pesar de que el tema se ha discutido hasta la extenuación. Se trata menos de corrección y más de negligencia.
- Varios dominios envían desde una IP. Una IP, varios dominios, banners rotativos según la aplicación o el flujo de correo = este error, casi el 100% de las veces.
- La infraestructura cambia sin que se revise la configuración DNS. Puede que se reasigne una IP, se reconstruya un servidor de correo o se cambie de proveedor, pero sólo se actualiza una parte de la identidad. El banner SMTP cambia mientras que el PTR se queda atrás (o viceversa), y el desajuste persiste mucho tiempo después del cambio original.
Todos estos casos muestran lo que ocurre cuando la infraestructura del correo electrónico cambia de forma incremental en lugar de por diseño.
Qué hacer a continuación
Si hay algo que aprender, es que la alineación importa más que la perfección. Los sistemas de correo intentan comprender si tu infraestructura se comporta como algo propio, mantenido y predecible.
Utiliza advertencias como ésta para hacer mejores preguntas sobre el control, la coherencia y la intención. Verifica los cambios con los resultados reales de la entrega, no sólo con la salida del escáner. Y resiste el impulso de «arreglar» cualquier cosa que no repercuta en la práctica en la colocación en la bandeja de entrada.
Las configuraciones limpias ayudan; los sistemas coherentes ayudan más. Pero lo mejor que puedes hacer por la entregabilidad es reforzar activamente el compromiso positivo para que los proveedores de la bandeja de entrada confíen en tu correo desde el principio.
Reserva una demostración gratuita de InboxAlly para ver cómo el compromiso guiado puede ayudarte a sacar tus correos electrónicos del spam y llevarlos directamente a la bandeja de entrada, y a mantenerlos allí mientras realizas cambios de infraestructura como éste.