Cómo configurar un registro PTR para un servidor de correo

gmail, yahooy Microsoft comprueban los registros PTR en el correo entrante y rechazan o envían a la carpeta de spam los mensajes de servidores sin DNS inverso válido. A diferencia de SPF, DKIM o DMARCUn registro PTR no es algo que puedas agregar a tu propia zona DNS. Debe ser configurado por el propietario de la dirección IP que usa tu servidor de correo para enviar mensajes.

Los registros PTR suelen ser lo que falta una vez que el resto de la pila de autenticación está completamente configurada. La mayoría de los remitentes configuran todo lo que controlan directamente y aun así experimentan problemas de entrega porque la IP de envío no apunta a un nombre de host de confianza.

Configurar un registro PTR implica encontrar la IP de envío, confirmar quién la controla, elegir el nombre de host correcto, enviar la solicitud al propietario de la IP y comprobar que la resolución DNS inversa funciona después del cambio.

Cómo configurar un registro PTR para un servidor de correo: 5 pasos

La configuración de PTR sigue los mismos cinco pasos básicos con cualquier proveedor de alojamiento. Lo único que cambia es la forma de enviar la solicitud de PTR.

El proceso completo suele tardar entre 1 y 5 días hábiles. Los tres primeros pasos solo toman unos minutos. El proveedor se encarga de la actualización del PTR y, finalmente, se comprueba que el DNS inverso funcione correctamente.

Paso 1: Encuentra la dirección IP pública de tu servidor de correo.

Identifique la dirección IP pública que su servidor de correo utiliza para las conexiones SMTP salientes. Esta es la IP que ven los servidores de correo receptores, no ninguna IP interna o privada que su servidor pueda utilizar.

Ejecuta curl ifconfig.me desde la línea de comandos del servidor de correo o consulta el panel de configuración de red de tu plataforma en la nube. En el caso de los servicios SMTP dedicados, la IP de envío suele aparecer directamente en el panel de control del proveedor.

Confirme que la IP sea estática. Los registros PTR requieren direcciones IP estáticas; son inútiles si la IP subyacente cambia periódicamente. Las plataformas en la nube suelen asignar direcciones IP estáticas por defecto a los servidores de correo, pero verifique esto antes de continuar con el siguiente paso.

Paso 2: Identifique al propietario de su bloque de direcciones IP.

Busque la IP usando Herramienta de DNS inverso de MXToolbox o bien, mediante una consulta WHOIS a ARIN, RIPE o APNIC, según su región. El resultado identifica la organización que controla el bloque de IP, generalmente su proveedor de servicios en la nube, empresa de alojamiento o proveedor de servicios de Internet (ISP).

No puedes omitir al propietario de la IP. Él controla la zona DNS inversa donde reside el registro PTR. Aunque administres el DNS de tu dominio, no controlas el DNS inverso de las direcciones IP que no te pertenecen.

Paso 3: Elija un nombre de host y agregue un registro A que coincida.

Elija un nombre de host que identifique claramente la función y el dominio del servidor de correo; por ejemplo, mail.yourcompany.com o smtp.yourcompany.com funcionan bien. Evite los nombres de host genéricos proporcionados por el ISP, como host-203-0-113-25.example-isp.com, ya que resultan sospechosos para los servidores de correo receptores, incluso cuando son técnicamente funcionales.

En el DNS de su dominio, cree un registro A que apunte este nombre de host a la IP pública de su servidor de correo. Este registro A debe existir antes de enviar la solicitud PTR; el DNS inverso con confirmación directa (FCrDNS) requiere que las búsquedas directas e inversas coincidan.

Espere hasta 24 horas para que se propague el registro A antes de enviar la solicitud PTR. La mayoría de los servidores DNS se actualizan en pocas horas, pero esperar todo el tiempo evita discrepancias durante el proceso de verificación del propietario de la IP.

Paso 4: Configure el PTR a través del propietario de su IP.

El procedimiento exacto depende completamente de tu proveedor. Las plataformas en la nube, como AWS, Azure y GCP, y los servidores VPS dedicados suelen ofrecer la configuración de PTR de autoservicio directamente en sus consolas. Los servicios de alojamiento compartido tradicionales y los proveedores de servicios de Internet (ISP) generalmente requieren abrir un ticket de soporte.

Al enviar una solicitud, incluya tres datos: la dirección IP, el nombre de host deseado y una prueba de que usted controla el dominio (el registro A correspondiente del paso 3 sirve como prueba). La mayoría de los proveedores responden en un plazo de 1 a 3 días hábiles. Consulte la sección específica del proveedor a continuación para obtener instrucciones detalladas.

Paso 5: Verificar con FCrDNS

Una vez que el propietario de la IP confirme que el PTR está configurado, verifíquelo con dos comandos. Primero, ejecute dig -x 203.0.113.25 @8.8.8.8 (sustituyendo su IP real) para confirmar que la búsqueda inversa devuelve el nombre de host elegido. Luego, ejecute dig mail.yourcompany.com @8.8.8.8 (sustituyendo su nombre de host) para confirmar que la búsqueda directa A devuelve la misma IP.

Ambas consultas deben devolver resultados coincidentes. Esta coincidencia bidireccional es FCrDNS, la comprobación estándar que realizan los servidores de correo receptores. Un registro PTR que devuelve un nombre de host cuyo registro A no apunta a la IP original no supera la prueba FCrDNS y se considera inválido, aunque técnicamente exista un registro PTR.

Espere hasta 24 horas para que se complete la propagación del DNS antes de asumir que el nuevo PTR es visible de forma fiable desde todas las redes.

Configuración del registro PTR por parte del proveedor de alojamiento

La ruta de configuración exacta varía significativamente entre las plataformas de alojamiento. Las plataformas en la nube generalmente ofrecen configuración PTR de autoservicio a través de sus consolas o API, mientras que el alojamiento compartido tradicional requiere un ticket de soporte. La información necesaria es idéntica en ambos casos: dirección IP, nombre de host y comprobante de propiedad del dominio.

AWS EC2 y SES

AWS requiere una solicitud de soporte en lugar de la configuración de autoservicio. Abra el Centro de soporte en la consola de AWS, seleccione "Servicio: SES" o "Servicio: EC2" según el origen de su tráfico y envíe una solicitud de DNS inverso. Incluya la IP elástica y el nombre de host deseado. Las revisiones suelen tardar entre 24 y 48 horas. Documentación de DNS inverso de SES de AWS Cubre en detalle todo el flujo de trabajo de la solicitud.

microsoft Azure

Azure admite la configuración de PTR tanto a través del Portal como de PowerShell. En el Portal, acceda a su recurso de IP pública y busque directamente el campo DNS inverso. A través de PowerShell, use Set-AzPublicIpAddress con el parámetro ReverseFqdn. La documentación de Microsoft sobre DNS inverso de Azure describe la sintaxis exacta para ambos métodos.

Google Cloud Platform (GCP)

En la consola de GCP, vaya a Red VPC → Direcciones IP externas. Haga clic en el menú de tres puntos junto a la IP correspondiente y seleccione DNS inverso. Introduzca su nombre de host y guarde. GCP verifica que el registro A del nombre de host apunte a la IP antes de activar el PTR, lo que significa que el paso 3 anterior debe completarse para que este paso se realice correctamente.

Hetzner, Linode y DigitalOcean

Los tres proveedores de VPS dedicados ofrecen configuración PTR de autoservicio directamente a través de sus paneles de control. En Hetzner Robot o Cloud, busque la IP en Servidores, haga clic en el icono del lápiz junto a rDNS e ingrese el nombre de host. En Linode Cloud Manager, abra la pestaña Red de Linode. En DigitalOcean, configure PTR en la sección Redes de la configuración de Droplet.

Alojamiento compartido y cPanel

Los servicios de alojamiento compartido tradicionales, como Bluehost, HostGator, GoDaddy y la mayoría de los proveedores basados ​​en cPanel, generalmente no ofrecen configuración de PTR de autoservicio. Abra un ticket de soporte solicitando un registro PTR para su IP, que apunte al nombre de host de su servidor de correo, y proporcione una prueba de propiedad del dominio mediante el registro A correspondiente.

Algunos servicios de alojamiento compartido no permiten la personalización de PTR, independientemente de cómo se formule la solicitud. Si el tuyo no la permite, la única solución es migrar a un proveedor que sí lo haga. Esto suele implicar un VPS dedicado, una plataforma en la nube o un servicio de correo electrónico transaccional con soporte para PTR.

Servicios de correo electrónico alojados (Google Workspace, Microsoft 365)

Los servicios de correo electrónico alojados gestionan los registros PTR en su propia infraestructura compartida. Los remitentes que utilizan Google Workspace o Microsoft 365 no necesitan configurar los registros PTR por sí mismos, ya que el proveedor del servicio se encarga de ello para las direcciones IP que posee y controla.

Esto solo se aplica cuando se envían correos a través de los servidores de salida del propio servicio. Si se enruta el correo a través de un servidor SMTP de terceros mientras se utiliza Google Workspace o Microsoft 365 para otros fines, los requisitos de PTR se aplican a la IP de ese servidor de terceros, no a la infraestructura de Google o Microsoft.

Cómo verificar que su registro PTR funciona correctamente

La verificación confirma dos cosas distintas: que el PTR esté configurado y que FCrDNS se resuelva correctamente. Omitir este paso es la razón más común por la que los equipos creen que un PTR está configurado cuando en realidad no funciona correctamente.

• Verificación por línea de comandos: Ejecuta `dig -x [tu IP] @8.8.8.8` para confirmar que la búsqueda inversa devuelve el nombre de host que elegiste. Ejecuta `dig [tu nombre de host] @8.8.8.8` para confirmar que la búsqueda directa devuelve tu IP. Ambos resultados deben coincidir; esta es la comprobación FCrDNS que realizan los servidores de correo receptores.
• Herramientas de verificación en línea: La función de búsqueda DNS inversa de MXToolbox acepta una dirección IP y devuelve el nombre de host PTR, además de un estado de éxito o fracaso. Esto resulta útil para confirmaciones no técnicas y para incluirlo en los tickets de soporte al trabajar con el propietario de la IP en una solución.
• Verificación del lado del servidor: Ejecute el comando `hostname -f` en el propio servidor de correo para confirmar que el nombre de host configurado en el servidor coincide con el que devuelve el PTR. Si difieren, el comando HELO/EHLO del servidor de correo envía un nombre distinto al que resuelve el PTR, y la mayoría de los servidores receptores interpretan esta discrepancia como un fallo leve, incluso cuando el PTR es técnicamente válido.

Problemas comunes en los registros PTR y cómo solucionarlos

Estos cuatro problemas son la causa de la mayoría de los problemas de entrega relacionados con PTR. En la mayoría de los casos, solucionarlos implica contactar al propietario de la propiedad intelectual.

Falta por completo el registro PTR.

Diagnosticar: Al ejecutar dig -x [tu IP] @8.8.8.8 no se obtiene ningún resultado PTR o se obtiene NXDOMAIN.

Solución: Contacta con el propietario de la IP y solicita un registro PTR que apunte al nombre de host del servidor de correo que hayas elegido. Proporciona como prueba la titularidad del dominio y el registro A correspondiente del DNS de tu dominio.

El nombre de host PTR no coincide con el registro A (fallo de FCrDNS).

Diagnosticar: La búsqueda inversa devuelve un nombre de host, pero la búsqueda directa de ese nombre de host devuelve una IP diferente o ninguna IP. Este es el patrón de fallo clásico de FCrDNS.

Solución: Actualice el registro A para que apunte a la dirección IP de envío real, o solicite al propietario de la IP que actualice el registro PTR para que coincida con un registro A existente. Ambos registros deben coincidir para que FCrDNS funcione correctamente.

Nombre de host genérico del ISP en lugar de un nombre de host de marca.

Diagnosticar: El PTR devuelve un nombre de host como host-203-0-113-25.example-isp.com en lugar de un nombre de host de marca bajo su propio dominio.

Solución: Solicite al propietario de la IP que actualice el PTR para que apunte a un nombre de host de su dominio (mail.yourcompany.com o smtp.yourcompany.com). Si bien los nombres de host genéricos de los proveedores de servicios de Internet no invalidan técnicamente el FCrDNS, resultan sospechosos para los servidores receptores y reducen la confianza en el sistema.

Falta el registro PTR de IPv6

Diagnosticar: PTR funciona correctamente para el tráfico IPv4, pero Gmail rechaza los correos entregados mediante IPv6 con errores de "error de DNS inverso" o "falta de coincidencia de identidad del remitente".

Solución: Solicite un registro PTR independiente específicamente para la dirección IPv6. Los registros PTR de IPv6 se encuentran en la zona ip6.arpa con notación de nibble invertida, lo que significa que se configuran de forma totalmente independiente de los registros IPv4, incluso cuando ambos sirven al mismo servidor de correo.

Registros PTR bien hechos

La configuración de PTR sigue un proceso universal de 5 pasos, pero la ruta de configuración real varía según el proveedor. Las plataformas en la nube y los servidores VPS dedicados ofrecen configuración de autoservicio; el alojamiento compartido requiere un ticket de soporte; los servicios de correo electrónico alojados gestionan todo el proceso en su nombre.

La verificación FCrDNS es la comprobación más importante tras la configuración. La mayoría de los problemas de entrega relacionados con el PTR se deben a una discrepancia entre el PTR y el registro A correspondiente. Al corregir dicha discrepancia, los problemas de entrega relacionados suelen resolverse automáticamente.

Una sólida reputación de dominio e IP depende de que los registros PTR funcionen junto con SPF, DKIM y DMARC. Los registros PTR confirman la identidad a nivel de red, pero no reemplazan una buena higiene de listas. Para una entrega confiable, tanto la autenticación como la calidad de las listas deben estar presentes.

Si está configurando un nuevo servidor de correo o Calentando un nuevo dominio de envío, emparejar la configuración del PTR con Validación de listas de correo electrónico Antes de tu primer envío de producción, la autenticación sólida y una lista limpia, en conjunto, brindan a cada mensaje la mejor oportunidad posible de llegar a la bandeja de entrada, y cada una soluciona un problema que la otra no puede resolver.