¿Qué es el DNS inverso?

El DNS inverso asocia una IP con un nombre de host mediante un registro PTR. Por qué lo exigen los filtros de correo y cómo configurar un rDNS en un VPS.

La definición, con precisión

El DNS inverso (rDNS) es la consulta que asocia una dirección IP con un nombre de host, almacenada en el DNS como registro PTR. El DNS directo responde a «a qué IP apunta mail.example.com»; el DNS inverso responde a la pregunta espejo: en nombre de qué nombre responde 203.0.113.10. El registro pertenece a la dirección, no al dominio —una distinción que provoca la mayor parte de la confusión al configurarlo, porque significa que el PTR de la IP de tu VPS no tiene ninguna entrada por defecto en el panel DNS de tu dominio.

Por debajo, la consulta es DNS ordinario: los resolutores preguntan a zonas inversas especiales y la respuesta es una cadena con un nombre de host. No hay nada exótico en ello, y nada opcional si el servidor envía correo. Para cualquier otra carga de trabajo es una infraestructura silenciosa: ocasionalmente útil, rara vez urgente y barata de configurar correctamente una vez sabes quién controla el registro.

Cómo funciona el mecanismo

Las zonas inversas IPv4 viven bajo in-addr.arpa, con los octetos de la dirección invertidos: el PTR de 203.0.113.10 se encuentra en 10.113.0.203.in-addr.arpa. IPv6 hace lo mismo bajo ip6.arpa, un dígito hexadecimal por etiqueta, lo que hace los registros largos pero la lógica idéntica. Quien posee el bloque de direcciones controla la zona —el proveedor de hosting o su operador ascendente, nunca tu registrador ni el host DNS de tu dominio. Por eso el PTR es un ajuste del lado del hosting.

El estándar de calidad que aplican los receptores es el rDNS con confirmación directa, o FCrDNS: el nombre de host al que apunta el PTR debe resolver a su vez de vuelta a la misma IP. Un registro que apunta al vacío, o a un nombre que resuelve en otro sitio, puntúa como un registro ausente. La cadena tiene tres eslabones —que el PTR exista, que la consulta directa lo confirme y que el nombre sea uno que controlas— y los tres se comprueban automáticamente en cada handshake de correo.

La delegación explica la estructura de control: el registro regional delega la zona inversa de cada bloque al titular del bloque, igual que un registrador delega un dominio directo a sus servidores de nombres. Por eso mismo, mover un servidor no mueve el registro: el PTR se queda con la dirección, y una migración que olvida restablecerlo deja tu correo anunciando el nombre del proveedor anterior durante semanas.

Por qué el correo vive y muere por ello

Los filtros receptores de Gmail, Outlook y cualquier MTA mayoritario ejecutan las mismas comprobaciones iniciales al llegar una conexión: ¿existe un PTR para la IP emisora; está confirmado hacia adelante; coincide plausiblemente con el nombre que el servidor anunció en HELO/EHLO? Un registro ausente o genérico es una de las señales de spam más antiguas del libro: la RFC 1912 recomienda la coherencia PTR-HELO desde 1996, y las directrices para remitentes de Google enuncian el requisito sin rodeos para quien envía a volumen. El correo desde una dirección sin rDNS no siempre rebota, pero empieza cada conversación con un punto en contra.

El planteamiento honesto es: necesario, nunca suficiente. Un rDNS correcto supera la comprobación de identidad; el mensaje en sí todavía necesita alineación de SPF, DKIM y DMARC, un historial de envío razonable y un contenido que puntúe bien, y la IP de base necesita una reputación limpia independiente de su nombre. DNS inverso sobre una dirección quemada produce correo correctamente presentado y aun así archivado como basura: higiene, no reparación.

Las comprobaciones se ejecutan además en un orden estricto en el momento del handshake, y el veredicto del PTR llega primero: una conexión puede rechazarse solo por la ausencia del registro antes de que el mensaje en sí se analice. Cualquiera que gestione correo en un VPS pagado con Monero debería tratar el registro como configuración del primer día y no como un arreglo posterior, porque las primeras semanas de una dirección nueva son justo cuando los filtros más peso dan a sus presentaciones.

Más allá del correo: beneficios menores

Fuera del correo, las ganancias son pequeñas pero acumulativas. Los registros se vuelven legibles cuando las herramientas resuelven direcciones a nombres, lo que agiliza el diagnóstico de incidentes. Algunos sistemas antibot y heurísticas de abuso —redes IRC, servidores de juegos, formularios de registro— tratan un registro confirmado hacia adelante como una leve señal de confianza, porque la infraestructura desechable rara vez se molesta. Las búsquedas de geolocalización y atribución de red también contrastan con los nombres PTR, así que un registro sensato reduce la clasificación errónea de dónde vive tu servidor.

Una advertencia honesta apunta en sentido contrario: un PTR es público, legible por cualquiera que invierta tu dirección. La etiqueta le dice al mundo con qué dominio se asocia la IP, así que elige un nombre de host neutro cuando el nombre del dominio en sí no sea algo que quieras publicar en la dirección. Un nombre genérico como srv-203-0-113-10.example.net conserva los beneficios técnicos sin exponer nada, razón por la cual nuestra propia guía de opsec mantiene los registros PTR deliberadamente sosos. Consulta los límites del anonimato de un VPS sin KYC para ver el panorama completo, porque un PTR es un correlador más publicado entre una identidad y una dirección: el registro es legible por diseño, así que la etiqueta que publicas debe elegirse, no dejarse por defecto.

Configurar rDNS personalizado en un VPS

En nuestro panel el registro PTR es editable por dirección, tanto para la IPv4 como para las direcciones dentro del /64 IPv6 que incluye cada plan. La secuencia: elige un nombre de host que controles, crea el registro directo A o AAAA correspondiente en tu host DNS y luego fija el PTR en el lado del hosting con ese mismo nombre, dándole a la propagación de minutos a unas horas. Verifica desde el servidor con dig -x 203.0.113.10, host o nslookup, y confirma que la dirección directa resuelve de vuelta a la dirección.

Luego cierra el círculo por el lado del correo: configura el nombre HELO/EHLO del MTA con el nombre de host que lleva el PTR, ya que los filtros comparan ambos. En unidades dedicadas el cuadro se amplía: con tus propios rangos en un servidor dedicado, podemos delegarte la zona inversa a tus servidores de nombres para que gestiones los registros PTR en bloque por tu cuenta. En un VPS, la edición en el panel es todo el trabajo, y no tiene coste alguno.

En la propia pila de correo, el nombre tiene que coincidir en tres sitios. En Postfix vive en myhostname; en Exim, en PRIMARY_HOST_NAME; y el certificado que presenta el MTA debería llevar el mismo nombre, para que la información TLS coincida con el saludo. Cinco minutos de alineación en la configuración evitan los rechazos por HELO incoherente que, de lo contrario, aparecen semanas después enterrados en registros de entrega que nadie está leyendo todavía.