DNS inverso para espacio IP alquilado: registros PTR, delegación y correo

El DNS inverso asocia una dirección IP a un nombre, mediante un registro PTR. Para la mayoría de los servicios es un detalle. Para un servidor de correo no lo es: Google exige que cada dirección que envía a Gmail tenga un registro PTR cuyo nombre resuelva de vuelta a la misma dirección, y muchos otros receptores buscan la misma coincidencia. Con espacio alquilado, el registro está en una zona que por defecto no controlas, así que conviene saber quién lo configura y cómo.

Cómo funciona el DNS inverso

Una consulta directa convierte un nombre en una dirección. Una consulta inversa convierte una dirección en un nombre, invirtiendo sus cuatro números bajo un dominio especial: el registro PTR de 203.0.113.10 está en 10.113.0.203.in-addr.arpa. IPv6 funciona igual bajo ip6.arpa, un dígito hexadecimal cada vez.

La zona de un /24, 113.0.203.in-addr.arpa en este ejemplo, la delega el registro en los servidores de nombres indicados para ella. En la región de servicio del RIPE NCC son las líneas nserver de un objeto domain en la RIPE Database. Quien gestiona esos servidores de nombres decide lo que dicen los registros PTR.

dig -x 203.0.113.10 +short

Quién lo controla en el espacio alquilado

El registro delega la zona inversa en el titular del bloque, así que en el espacio alquilado es el arrendador, no tú. En la práctica hay dos formas.

• El arrendador configura los registros que pides. Envías el nombre de cada dirección y el arrendador publica los registros PTR. Es la forma más sencilla y basta para casi todo el mundo.
• El arrendador te delega la zona. Con un objeto domain que apunta a tus servidores de nombres, gestionas tú mismo los registros PTR. Eso funciona para un /24 entero. Para una parte más pequeña, el arrendador puede pasarte solo tus direcciones con la delegación sin clases descrita en el RFC 2317: registros CNAME en su zona que apuntan a una zona en tus servidores de nombres.

En cualquier caso, pregunta antes de que empiece el alquiler cómo se hacen los cambios y cuánto tardan en aparecer, porque un servidor de correo al que no puedes dar un nombre adecuado es un servidor de correo que no entrega.

Qué comprueban los receptores de correo

Las directrices para remitentes de Google explican la regla para todo remitente, no solo para los masivos: «The public IP address of a sending SMTP server must have a corresponding PTR record that resolves to a hostname.» (traducción: «la dirección IP pública de un servidor SMTP de envío debe tener un registro PTR correspondiente que resuelva a un nombre de host»). Ese nombre de host debe tener a su vez un registro A, o AAAA para IPv6, que resuelva a la misma dirección. Es el DNS inverso con confirmación directa: de la dirección al nombre, y del nombre de vuelta a la misma dirección. Gmail responde a un registro que falta o no coincide con un error temporal o permanente, y aplica sus reglas con más rigor desde noviembre de 2025.

Van con ello dos costumbres. Usa el mismo nombre en el saludo que envía tu servidor de correo (HELO o EHLO), y elige nombres que parezcan un servidor y no un pool. Yahoo, que exige DNS inverso a todo remitente, pide registros PTR «meaningful, non-generic» (traducción: «significativos, no genéricos»), y algunos filtros tratan un nombre como 203-0-113-10.dynamic.example.net como señal de una conexión doméstica.

Configurarlo, paso a paso

1. Elige un nombre por cada dirección de envío, bajo un dominio que controles: mail1.example.com.
2. Crea el registro directo: mail1.example.com. A 203.0.113.10.
3. Configura el registro PTR: 10.113.0.203.in-addr.arpa. PTR mail1.example.com., a través de tu arrendador o en tu zona delegada.
4. Comprueba las dos direcciones desde una red ajena a la tuya:

dig -x 203.0.113.10 +short        # expect: mail1.example.com.
dig +short mail1.example.com A    # expect: 203.0.113.10

1. Haz que el servidor de correo use el mismo nombre. En Postfix es myhostname = mail1.example.com.

Errores que rompen la entrega

• Un registro PTR sin un registro A que coincida. La consulta inversa funciona y la comprobación directa falla.
• Dos registros PTR para una dirección. Las comprobaciones no se ponen de acuerdo sobre cuál cuenta. Deja uno.
• Un cambio de nombre con un TTL largo. Los resolvers siguen sirviendo el nombre antiguo hasta que vence el TTL. Bájalo un día antes de un cambio previsto.
• IPv6 olvidado. Si el servidor envía por IPv6, su dirección IPv6 necesita el mismo tratamiento bajo ip6.arpa, con un registro AAAA que coincida.
• Una zona delegada en servidores de nombres que dejan de responder. El registro solo comprueba los servidores de nombres cuando se hace la delegación. Si fallan después, todas las consultas inversas del bloque fallan con ellos.

Dónde encaja RTM Networks

El DNS inverso forma parte de cada alquiler sin coste adicional: dinos el nombre de cada dirección y configuramos los registros PTR (alquilar IPv4). Si las direcciones van a enviar correo, su reputación importa tanto como sus nombres, así que comprobamos cada bloque IPv4 que alquilamos en listas de bloqueo antes de la entrega y cada día mientras lo tienes (mantener limpio un bloque).