El DNS inverso (rDNS) hace lo contrario que el DNS normal: dada una dirección IP, devuelve el nombre de host asociado mediante un registro PTR. Los servidores de correo lo comprueban en cada conexión y muchos rechazan o marcan como spam los mensajes de IPs sin PTR o con un PTR genérico, y también aparece en traceroute, en los registros de acceso y en las herramientas de diagnóstico. En este tutorial comprobarás el PTR actual de tu servidor, lo configurarás desde el panel de CubePath para que coincida con tu dominio, alinearás el nombre de host del sistema y verificarás el resultado con dig.
Requisitos previos
- Un VPS de CubePath con Ubuntu 24.04 LTS u otra distribución Linux, o una IP flotante de CubePath asignada a un servidor.
- Un usuario no root con privilegios
sudo. - Un dominio propio con acceso a su zona DNS para crear registros A y AAAA. En los ejemplos se usa
mail.your_domain. - La herramienta
dig. En Ubuntu y Debian se instala consudo apt install bind9-dnsutils; en Rocky Linux, consudo dnf install bind-utils.
En los ejemplos, la IPv4 del servidor es 203.0.113.10 y la IPv6 2001:db8:10::10. Sustitúyelas por las tuyas.
Cómo funciona el DNS inverso
Las búsquedas inversas usan dos dominios especiales:
- IPv4:
in-addr.arpa. Los octetos se escriben al revés, así que el PTR de203.0.113.10se consulta en10.113.0.203.in-addr.arpa. - IPv6:
ip6.arpa. Cada cifra hexadecimal de la dirección completa se escribe al revés, separada por puntos.
La diferencia clave con el DNS directo es quién controla el registro. Los registros A de your_domain los gestionas tú en tu proveedor DNS, pero la zona inversa de una IP pertenece a quien tiene asignado el bloque de direcciones, es decir, al proveedor que te da la IP. Por eso el PTR no se crea en la zona de tu dominio, sino en el panel de tu proveedor, que es quien publica el registro en sus servidores de nombres.
Los servidores de correo no se conforman con que exista un PTR. Comprueban el DNS inverso confirmado (FCrDNS, forward-confirmed reverse DNS): la IP resuelve a un nombre con el PTR, y ese nombre resuelve de vuelta a la misma IP con su registro A o AAAA. Si cualquiera de los dos pasos falla, la comprobación falla.
| Consulta | Ejemplo | Quién la configura |
|---|---|---|
| Directa (A / AAAA) | mail.your_domain → 203.0.113.10 | Tú, en el DNS de tu dominio |
| Inversa (PTR) | 203.0.113.10 → mail.your_domain | Tú, desde el panel de CubePath |
Paso 1: Consultar el PTR actual
Averigua primero la IP pública del servidor:
ip -brief address
Consulta el PTR actual con dig -x, que construye el nombre in-addr.arpa por ti:
dig -x 203.0.113.10 +short
Si la IP ya tiene un PTR, verás el nombre asociado; si no tiene, la salida estará vacía. Un PTR recién asignado por el proveedor suele ser un nombre genérico. Para ver la respuesta completa, incluido el nombre de la zona inversa y su TTL, quita +short:
dig -x 203.0.113.10
;; QUESTION SECTION:
;10.113.0.203.in-addr.arpa. IN PTR
;; ANSWER SECTION:
10.113.0.203.in-addr.arpa. 3600 IN PTR host.example.net.
Para IPv6 el comando es el mismo:
dig -x 2001:db8:10::10 +short
Paso 2: Elegir el nombre y crear el registro directo
Elige un nombre de host completo (FQDN) que pertenezca a un dominio tuyo y que describa el servidor, por ejemplo mail.your_domain para un servidor de correo o vps1.your_domain para uno general. Evita nombres que parezcan de una conexión doméstica o dinámica, como los que contienen la IP o palabras como dynamic, porque algunos filtros antispam los penalizan.
Crea primero el registro directo, para que la comprobación FCrDNS funcione en cuanto publiques el PTR. En el proveedor DNS de tu dominio añade:
| Tipo | Nombre | Valor |
|---|---|---|
| A | mail | 203.0.113.10 |
| AAAA | mail | 2001:db8:10::10 |
El registro AAAA solo es necesario si el servidor tiene IPv6 y vas a configurar también su PTR. Comprueba que el registro directo ya resuelve:
dig +short A mail.your_domain
dig +short AAAA mail.your_domain
203.0.113.10
2001:db8:10::10
Paso 3: Configurar el PTR en el panel de CubePath
El PTR de las IPs que CubePath asigna a tus servidores se gestiona desde el panel:
- Inicia sesión en el panel de CubePath y abre tu VPS.
- Entra en la pestaña Network. Verás la lista de IPs asignadas al servidor, con una columna rDNS.
- Edita el campo rDNS de la IP que quieres configurar, escribe el nombre de host (por ejemplo
mail.your_domain) y guarda.
Las IPs flotantes también se pueden configurar desde la página Floating IPs, siempre que estén asignadas a un servidor: el panel no permite fijar el rDNS de una IP que no está asignada. Para quitar un PTR, deja el campo vacío o usa la opción de eliminar.
El panel valida que el valor sea un nombre de host válido: solo letras, números y guiones en cada etiqueta, sin empezar ni terminar ninguna con guion. No hace falta añadir el punto final; el panel lo gestiona por ti.
NotaEl cambio se aplica en segundo plano en los servidores DNS de CubePath. Además, si ya existía un PTR, los resolvers que lo tengan en caché seguirán devolviendo el valor anterior hasta que caduque su TTL.
Paso 4: Verificar el DNS inverso
Consulta de nuevo el PTR:
dig -x 203.0.113.10 +short
mail.your_domain.
Si todavía ves el valor anterior, puede ser la caché del resolver local. Pregunta a un resolver público distinto para comprobarlo:
dig -x 203.0.113.10 +short @1.1.1.1
Ahora comprueba el ciclo completo FCrDNS: que el nombre devuelto por el PTR resuelve a la misma IP.
dig +short A "$(dig -x 203.0.113.10 +short)"
203.0.113.10
Si la IP de la salida coincide con la de partida, la comprobación FCrDNS pasa. Repite las dos consultas con la IPv6 si también la has configurado.
Paso 5: Alinear el nombre de host del servidor
El PTR es lo que ven los demás, pero el propio servidor también se presenta con un nombre. Un servidor de correo, por ejemplo, anuncia su nombre en el saludo SMTP (HELO/EHLO), y conviene que coincida con el PTR. Establece el nombre de host del sistema:
sudo hostnamectl set-hostname mail.your_domain
Compruébalo:
hostnamectl hostname
mail.your_domain
Añade el nombre a /etc/hosts para que el sistema lo resuelva aunque falle el DNS:
sudo nano /etc/hosts
127.0.0.1 localhost
203.0.113.10 mail.your_domain mail
NotaEn muchos VPS, cloud-init regenera el nombre de host y
/etc/hostsen cada arranque. Si tus cambios se pierden al reiniciar, abre/etc/cloud/cloud.cfgy cambiapreserve_hostname: falseporpreserve_hostname: true. Si existe la opciónmanage_etc_hosts: true, cámbiala también afalse.
Si usas Postfix, fija el mismo nombre en su configuración, que es el que usará en el saludo SMTP:
sudo postconf -e 'myhostname = mail.your_domain'
sudo systemctl reload postfix
Comprueba el saludo conectando al puerto 25 del propio servidor:
nc -C localhost 25
220 mail.your_domain ESMTP Postfix (Ubuntu)
Escribe QUIT para cerrar la conexión.
Gestionar tu propia zona inversa
Todo lo anterior cubre el caso habitual: IPs individuales cuyo DNS inverso gestiona el proveedor. Solo si tienes asignado un bloque completo de direcciones y te han delegado su zona inversa a tus propios servidores de nombres (por ejemplo, con tus propias IPs de un registro regional), tendrás que publicar los PTR tú mismo. Con BIND en Ubuntu, la zona inversa de 203.0.113.0/24 se declara en /etc/bind/named.conf.local:
zone "113.0.203.in-addr.arpa" {
type master;
file "/etc/bind/db.203.0.113";
};
Y el archivo de zona /etc/bind/db.203.0.113 contiene los PTR con nombres completos terminados en punto:
$TTL 3600
@ IN SOA ns1.your_domain. hostmaster.your_domain. (
2026092501 ; serie
3600 ; refresh
900 ; retry
1209600 ; expire
3600 ) ; TTL negativo
IN NS ns1.your_domain.
IN NS ns2.your_domain.
10 IN PTR mail.your_domain.
Valida la zona y recárgala:
sudo named-checkzone 113.0.203.in-addr.arpa /etc/bind/db.203.0.113
sudo rndc reload
Si la zona no está delegada a tus servidores, publicarla no tiene efecto: el resto de Internet seguirá preguntando a los servidores del titular del bloque.
Solución de problemas
dig -x no devuelve nada después de guardar el rDNS
Espera unos minutos y pregunta a otro resolver (@1.1.1.1 o @9.9.9.9). Si seguía cacheado un valor anterior, tendrás que esperar al TTL que mostraba dig -x sin +short. Comprueba también en el panel que la IP está asignada al servidor y que el valor se ha guardado.
El panel rechaza el nombre de host
Revisa que no tenga espacios, guiones bajos ni caracteres acentuados, y que ninguna etiqueta empiece ni termine con guion. Escribe un nombre completo como mail.your_domain, no una URL con https://.
Los correos se rechazan con un error sobre el DNS inverso
Mensajes como Client host rejected: cannot find your reverse hostname o reverse DNS does not match indican que falta el PTR o que la comprobación FCrDNS falla. Repite las consultas del paso 4: el PTR debe devolver tu nombre y ese nombre debe resolver a la misma IP. Si el servidor envía por IPv6, el PTR IPv6 también es obligatorio.
El PTR es correcto pero el saludo SMTP muestra otro nombre
El servidor de correo usa su propia configuración, no el PTR. Revisa myhostname en Postfix (postconf myhostname) y el nombre de host del sistema.
Conclusión
Has comprobado el PTR de tu IP, has creado el registro directo, has configurado el DNS inverso desde el panel de CubePath y has verificado con dig que la comprobación FCrDNS pasa, con el nombre de host del sistema alineado. Si el servidor envía correo, el siguiente paso es publicar los registros SPF, DKIM y DMARC de tu dominio; también puedes repetir el proceso para la IPv6 y para cada IP adicional que añadas al servidor.