Comprobar un registro PTR: DNS inverso para tu servidor de correo

¿Qué es un registro PTR?

DNS relaciona nombres con direcciones técnicas. Una consulta DNS normal parte de un nombre de host y devuelve su dirección IP: un registro A proporciona una dirección IPv4 y un registro AAAA, una IPv6.

El DNS inverso funciona en sentido contrario. Consultas una dirección IP y obtienes un nombre de host mediante su registro PTR. PTR significa «pointer». En un servidor de correo, ese nombre podría ser mail.werkstatt.example.

Para confirmar que ambas direcciones coinciden, vuelve a consultar el nombre obtenido. Debe resolver a la IP inicial. Esta comprobación se conoce como DNS inverso confirmado mediante resolución directa.

La zona inversa suele pertenecer al proveedor responsable del rango de direcciones IP. Añadir un campo llamado PTR en el panel DNS de tu dominio no basta si ese proveedor no controla la zona inversa. Cloudflare explica cómo se gestionan las zonas DNS inversas.

¿Por qué importa el DNS inverso para el correo empresarial?

El servidor receptor ve la dirección IP del servidor que se conecta a él. Un nombre de host coherente y verificable ayuda a identificar al remitente. Google exige registros DNS directos e inversos válidos para las IP de envío. Consulta los requisitos de Gmail para remitentes.

Un PTR correcto no garantiza la llegada a la bandeja de entrada. También influyen la reputación de la IP, la autenticación del dominio y el comportamiento de envío. Corregir el DNS inverso no resuelve automáticamente todos los rechazos.

Para un pequeño negocio, la pregunta práctica es: ¿Qué servidor realiza la última conexión SMTP con el destinatario? SMTP es el protocolo de transferencia de correo entre servidores. Debemos comprobar la IP pública utilizada en esa última conexión.

Entrega directa o relay SMTP: ¿qué IP debes comprobar?

Con entrega directa, tu servidor se conecta a los servidores de los destinatarios. Si está detrás de un router, su dirección privada, como 192.168.1.20, no es la relevante. Necesitas la dirección pública de las conexiones salientes.

Con un relay SMTP, tu servidor entrega el correo saliente a un servicio de envío. El destinatario ve la IP del relay. Su proveedor gestiona la identidad de ese servidor; tú debes configurar tu dominio siguiendo sus instrucciones.

• Servidor propio con entrega directa: identifica la IP pública saliente en la configuración del servidor y de la red. Comprueba todas las direcciones utilizadas.
• MailPlus con relay: revisa la configuración del relay y los requisitos del proveedor. El PTR de tu conexión puede no ser relevante para la entrega final.
• Correo empresarial alojado: envía el error de entrega y las cabeceras completas a tu proveedor. Normalmente no administras sus IP de envío.

La IP de tu sitio web no es un sustituto fiable. El alojamiento web y el correo pueden utilizar proveedores completamente distintos.

Comprueba PTR y DNS directo en tres pasos

Estos comandos solo consultan DNS; no modifican registros. Ejecútalos en un terminal con dig instalado. Todas las direcciones y respuestas siguientes son ejemplos reservados, no mediciones de un servidor real. Sustitúyelos por los datos de tu ruta de envío.

1. Consulta el nombre de host

Para la dirección de ejemplo:

dig -x 203.0.113.25 +short

Una respuesta coherente sería:

mail.werkstatt.example.

El punto final indica un nombre DNS completo. Si no aparece ninguna respuesta, examina la respuesta completa sin +short. Una respuesta breve vacía no explica por sí sola si falta el registro o ha fallado la consulta.

2. Comprueba la resolución directa

Consulta ahora el nombre obtenido:

dig mail.werkstatt.example A +short

El resultado debe incluir la dirección comprobada:

203.0.113.25

Para IPv6, consulta la dirección IPv6 real de envío con dig -x y después el registro AAAA del nombre obtenido. Una ruta IPv4 funcional no demuestra que IPv6 esté bien configurado.

3. Compara con una entrega real

Envía un mensaje de prueba por esa ruta a un buzón externo que controles. Revisa las cabeceras completas y, si falla, el informe de entrega. Comprueba que la IP consultada sea la que realmente ve el servidor receptor.

Pide ayuda a tu proveedor o administrador para interpretar cabeceras complejas. Pueden contener direcciones y detalles internos; revísalas antes de compartirlas públicamente.

Cómo solicitar un cambio del PTR

Si falta la relación o es incorrecta, utiliza las opciones de DNS inverso de tu proveedor de IP o contacta con soporte. En una conexión empresarial fija suele ser el proveedor de Internet; en un VPS, el proveedor de alojamiento.

Por favor, estableced el registro PTR de nuestra IP pública de envío con el nombre de host de nuestro servidor de correo. El registro A o AAAA de ese nombre debe resolver a la misma dirección. Confirmad qué direcciones IPv4 e IPv6 cubre el cambio.

Sustituye el texto genérico por tus direcciones y nombre de host antes de enviarlo. Comprueba también el nombre que anuncia el servidor mediante SMTP. Esa configuración es independiente del registro DNS.

Tras el cambio, algunas respuestas pueden seguir en caché. El TTL indica cuánto tiempo se prevé conservar una respuesta. Comprueba de nuevo antes de hacer varias modificaciones especulativas.

Problemas habituales y siguiente comprobación

Observación	Siguiente comprobación
La consulta inversa no devuelve un nombre.	Revisa la respuesta DNS completa y contacta con el responsable del rango IP.
PTR devuelve un nombre cuyo registro A apunta a otra dirección.	Corrige conjuntamente el DNS directo y el inverso.
IPv4 funciona, pero algunas entregas fallan.	Comprueba si el servidor también envía por IPv6 y si esa ruta está bien configurada.
DNS parece correcto, pero el destinatario rechaza el correo.	Revisa el error SMTP exacto, la autenticación del dominio y la reputación de la IP.
Tu conexión no permite un PTR adecuado.	Reconsidera la entrega directa; utiliza un relay SMTP o correo alojado.

Con CGNAT, varias conexiones comparten una IPv4 pública. Un registro DNS no la convierte en una dirección pública bajo tu control exclusivo. Comprueba las limitaciones de la conexión antes de montar el sistema.

¿Necesita cada dominio de correo su propio PTR?

No necesariamente. Un servidor puede enviar para varios dominios desde la misma IP. PTR describe esa dirección del servidor; no tiene que reproducir el dominio que aparece después de @ en cada mensaje.

SPF, DKIM y DMARC cubren otros aspectos de la autenticación. Un registro MX tiene otra función: identifica los servidores que reciben correo para un dominio. Un MX válido no sustituye a un PTR.

Tu siguiente paso

Anota tu ruta real de envío, su IP pública saliente y el proveedor responsable. Comprueba PTR y DNS directo. Si no coinciden, tendrás una petición concreta para soporte.

Encontrarás definiciones breves en el glosario. Para continuar con la autenticación del dominio, consulta la guía de SPF, DKIM y DMARC.