05 Oct 20265 minutes read
Waseem OsmanEspecialista en DMARCPor qué la mala configuración de un registro PTR importa, incluso cuando DMARC pasa
Resumen del registro PTR:
- Un registro PTR ausente o que no coincide no hará que DMARC falle, pero aun así reduce la reputación de la IP y puede enviar el correo a spam o provocar su rechazo.
- Los fallos de PTR adoptan varias formas: registros ausentes, coincidencias directas rotas, IPv6 sin verificar, nombres de host genéricos de la nube o dominios PTR sin relación.
- La titularidad del PTR corresponde al titular de la IP, no al propietario del dominio, lo que complica las auditorías a escala.
Su política DMARC está en p=reject. Su registro SPF está limpio. DKIM firma correctamente.
Y, sin embargo, los mensajes de determinada infraestructura de envío acaban en spam, algunos se difieren y sus reportes agregados de DMARC muestran altas tasas de aprobación que no explican el problema.
El culpable suele ser una mala configuración del registro de puntero (PTR): el único componente de la infraestructura de correo que la mayoría de los equipos trata como opcional. Una mala configuración del registro PTR daña silenciosamente la reputación del correo, y los problemas pueden persistir aunque DMARC técnicamente pase.
Un registro PTR ausente o que no coincide no aparecerá como un fallo de DMARC. Eso es lo que lo hace peligroso: un equipo de seguridad ya sobrecargado puede estar viendo reportes DMARC limpios y aun así perder colocación en la bandeja de entrada, sin un registro evidente de la causa.
Qué hacen realmente los registros PTR en un flujo de correo
Un registro PTR asocia una dirección IP con un nombre de dominio. Es lo inverso de lo que hace un registro A.
Cuando un servidor de correo receptor acepta una conexión, realiza una comprobación de DNS inverso confirmado por reenvío (FCrDNS). Hace una consulta de DNS inverso para encontrar el nombre de host asociado a esa IP y luego realiza una consulta DNS directa sobre ese nombre de host para confirmar que resuelve de vuelta a la misma IP.
Esto es distinto de SPF. SPF pregunta si esta IP está autorizada para enviar en nombre de este dominio. PTR pregunta otra cosa: ¿esta IP afirma pertenecer a un nombre de host y ese nombre de host lo confirma?
Las consultas PTR sí tienen un papel específico y limitado dentro de SPF. La RFC 7208 define un mecanismo ptr, que comprueba si existe la asignación inversa de una IP y luego apunta a un nombre de dominio.
La RFC indica que el mecanismo es lento, poco fiable ante errores de DNS e innecesario dada la existencia de alternativas más fiables.
Lo que importa es cómo usan PTR los servidores receptores. Un registro PTR ausente o que no coincide no suele provocar un rechazo definitivo. Sin embargo, contribuye a una puntuación de reputación más baja para esa IP, lo que afecta a la reputación del correo y puede enviar mensajes a spam aunque DMARC pase formalmente.
Patrones habituales de fallo de PTR
- Registro PTR ausente. No existe ningún registro PTR para la IP de envío. Algunos receptores enviarán el mensaje a spam o rechazarán directamente la conexión.
- Coincidencia directa rota. El registro PTR resuelve a un nombre de host, pero la consulta directa de ese nombre de host devuelve una IP distinta.
- Remitente IPv6 sin verificar. Correo enviado por IPv6 sin un registro PTR y AAAA coincidentes para esa dirección.
- Nombre de host genérico de la nube. El PTR sigue apuntando a un nombre de host predeterminado asignado por la nube, incluso cuando el remitente podría configurar el DNS inverso.
- El PTR apunta a un dominio sin relación. El nombre de host del PTR pertenece a un dominio sin conexión discernible con el remitente o su plataforma.
Cómo diagnosticar si un registro PTR es correcto
El proceso de diagnóstico es sencillo para una sola IP, pero a escala empresarial requiere herramientas sistemáticas.
Auditoría de una sola IP
Para cualquier IP de envío, confirme el estado de PTR y FCrDNS. Compruebe el registro PTR de la IP de envío y confirme que resuelve de vuelta a la misma IP en una consulta directa. Un registro ausente, un nombre de host genérico asignado por la nube o una consulta directa que no coincide con la IP original indican un problema.
Entornos con varios dominios
Las empresas que gestionan varios dominios se enfrentan a un problema de escala. Quien tiene la asignación de la IP suele controlar los registros PTR, no el propietario del dominio.
Esto crea una dependencia de coordinación que muchos equipos subestiman. Para entornos con varios dominios, la siguiente lista de comprobación ofrece una base:
- Inventaríe todas las IP de envío de todos los dominios. Esto incluye las IP de plataformas de marketing, proveedores de correo transaccional, sistemas de RR. HH., remitentes de ERP y cualquier otra herramienta que envíe correo en nombre de los dominios gestionados.
- Confirme la titularidad del PTR. Algunos proveedores permiten cambiar el PTR por autoservicio desde su consola. Otros requieren una solicitud de soporte.
- Verifique el FCrDNS de cada registro PTR. La mera existencia del PTR no basta. La confirmación directa también debe tener éxito.
- Asigne nombres de host que sigan una convención de nomenclatura coherente. Los nombres genéricos generan ambigüedad de atribución. Use nombres como mail1.sendinginfra.example.com.
- Documente la configuración del PTR como parte de la incorporación de remitentes. Cuando se autoriza una nueva herramienta o proveedor como fuente de envío, la configuración del PTR debe ser un paso obligatorio antes de que la IP entre en producción.
Cómo puede ayudar Sendmarc
Un registro PTR mal configurado es difícil de detectar porque no hace fallar DMARC y no siempre genera un rebote definitivo. Queda fuera de los reportes que la mayoría de los equipos ya supervisan, y por eso se convierte en trabajo de investigación manual para unos equipos de seguridad y TI ya sobrecargados.
El panel de reputación de la plataforma de Sendmarc muestra el estado de las listas de bloqueo, la proporción de cumplimiento y la proporción de entregabilidad de cada IP de envío. Así se puede ver que una IP concreta pierde reputación, en lugar de tratar la entregabilidad como una única métrica indiferenciada.
Para las empresas que gestionan varios dominios, esto aporta el inventario de remitentes necesario para realizar una auditoría estructurada de PTR: todas las fuentes de envío autorizadas visibles, con sus datos de IP y reputación en un solo lugar.
Esa visibilidad reduce el trabajo de correlación manual al rastrear un problema de entregabilidad. También ofrece a los CISO y a los equipos de cumplimiento una respuesta defendible cuando se les pide demostrar que la infraestructura de envío se supervisa y no se da por supuesta.
Si la entregabilidad se deteriora a pesar de una configuración DMARC limpia, el PTR es donde hay que mirar. Empiece con un inventario de remitentes, ejecute las comprobaciones de FCrDNS descritas arriba y trate la corrección del PTR como un requisito de infraestructura, no como una ocurrencia tardía.
Descubra cómo Sendmarc centraliza la visibilidad de todos los dominios e IP de envío.
