Última actualización: julio de 2026

En resumen: El mecanismo ptr en un registro SPF autoriza a los servidores de envío realizando consultas de DNS inverso. Sin embargo, el RFC 7208 recomienda de forma expresa no publicarlo debido a su alta latencia, baja fiabilidad y excesiva carga sobre los servidores de nombres raíz.

En los inicios del estándar SPF (Sender Policy Framework), el mecanismo ptr parecía una forma cómoda de autorizar automáticamente todos los nombres de host pertenecientes a un dominio sin necesidad de programar direcciones IP individuales. Hoy en día, la especificación oficial del protocolo desaconseja firmemente su uso.

Cómo funciona el mecanismo ptr

Cuando un registro SPF incluye el mecanismo ptr:

v=spf1 ptr ~all

el servidor de correo receptor ejecuta un proceso de verificación de DNS inverso en varias etapas. Toma la dirección IP del servidor que se conecta y consulta el DNS para encontrar su registro PTR y obtener el nombre de host. A continuación, realiza una consulta directa (A o AAAA) sobre ese nombre de host resuelto para verificar que la lista de direcciones IP devuelta contenga la dirección IP original y que el nombre de host pertenezca al dominio consultado.

Por qué el RFC 7208 desaconseja ptr

La especificación del RFC 7208 establece de forma explícita que este mecanismo no debe publicarse (SHOULD NOT be published).

El estándar subraya varios inconvenientes operativos críticos basados en años de experiencia de despliegue:

  1. Lento y poco fiable: El mecanismo es lento, no es tan fiable como otros mecanismos en casos de errores DNS y genera una gran carga sobre los servidores de nombres .arpa. Incluso un breve tiempo de espera durante una consulta inversa puede hacer que el correo legítimo falle la autenticación.
  2. Estrictas restricciones y requisitos: Si se utiliza, deben existir registros PTR correctos configurados para los hosts del dominio y el mecanismo ptr debería ser uno de los últimos mecanismos comprobados.
  3. Alternativas superiores disponibles: Tras muchos años de experiencia en el despliegue de SPF, se ha llegado a la conclusión de que ptr es innecesario y deben utilizarse alternativas más fiables en su lugar.

El límite de 10 consultas DNS y permerror

Además de los problemas de latence y fiabilidad, el mecanismo ptr repercute gravemente en tu presupuesto de consultas DNS. El RFC 7208 define que los mecanismos include, a, mx, ptr y exists, junto con el modificador redirect, generan consultas DNS en el momento de la evaluación.

Dado que las implementaciones de SPF deben limitar el número total de estos términos a 10 consultas durante la evaluación, superar este límite hace que el servidor receptor detenga de inmediato el procesamiento y devuelva permerror (error permanente). Como una sola comprobación ptr desencadena múltiples consultas DNS subyacentes, depender de ella agota rápidamente tu presupuesto. Asimismo, un dominio no debe publicar múltiples registros SPF por separado, ya que esto también provoca un permerror inmediato.

Alternativas fiables

En lugar de depender de ptr, debes adoptar mecanismos directos y de alto rendimiento:

  • ip4 e ip6: Si operas desde direcciones IP dedicadas o subredes estáticas, los términos IP directos se evalúan al instante con cero consultas DNS.
  • include: Si delegas el envío a plataformas externas de terceros, apuntar a su registro SPF dedicado mediante include garantiza una autorización limpia y fácil de mantener.

Auditar tu configuración

Si aún conservas mecanismos ptr heredados en tus registros DNS, elimínalos y audita tu dominio con el escáner gratuito MXAudit. Destaca los términos en desuso y hace un seguimiento preciso de tus consultas frente al límite de 10 consultas DNS.

Para aprender más sobre cómo modernizar tu arquitectura de autenticación o configurar proveedores específicos, explora la guía SPF y tutoriales prácticos como configurar SPF en IONOS.

Más información