¿Qué es el mecanismo ptr de SPF y por qué sigue presente en 950.631 registros? (2026)

Q: ¿Qué debería usar en lugar de ptr?

Bloques ip4:/ip6: para los servidores que controlas, o el include: documentado por tu proveedor. Ambos son deterministas, rápidos y fiables: todo lo que ptr no es.

Q: ¿Cuenta ptr para el límite de 10 consultas de SPF?

Sí: cada ptr cuesta al menos una de las diez consultas DNS que un receptor realizará antes de darse por vencido con un PermError. En registros ya saturados de mecanismos include:, el mecanismo muerto puede ser el que te empuje por encima del límite.

Publicado 2026-07-03

Cifras a 2026-06-29 · metodología v7. Censo agregado de 261 millones de dominios calificados. Todas las cifras son agregadas: nunca el registro de una empresa individual. Consulta cómo calificamos.

ptr es un mecanismo de SPF que autoriza a los remitentes mediante una búsqueda de DNS inverso, y el propio estándar SPF dice “no lo uses” desde 2014. 12 años después, 950.631 dominios lo siguen publicando. Eso es aproximadamente 1 de cada 146 de los 139 millones de registros SPF de internet que arrastran un mecanismo que la especificación declaró obsoleto antes de que algunos de esos dominios fueran registrados.

Qué se suponía que hacía ptr

ptr dice: “acepta correo de cualquier servidor cuyo DNS inverso resuelva de vuelta a mi dominio”. Suena elegante: no hay listas de IP que mantener. En la práctica exige que el receptor haga una búsqueda inversa sobre la IP que se conecta y luego confirme hacia delante cada nombre de host que recibe. El RFC 7208 (§5.5) lo declaró obsoleto con palabras claras: el mecanismo es “lento, no es tan fiable como otros mecanismos en casos de errores de DNS, e impone una gran demanda de recursos sobre los servidores de nombres .arpa”, e indica que “NO DEBERÍA usarse”.

Por qué sigue siendo una trampa en 2026

Tres razones por las que un mecanismo declarado obsoleto hace 12 años todavía importa:

Consume tu presupuesto de consultas. Cada ptr cuenta contra el techo estricto de SPF de 10 consultas DNS por comprobación: el límite que, una vez superado, anula el registro entero con un PermError. Un mecanismo que no hace nada fiable sigue costándote el presupuesto que necesitan tus mecanismos include: reales.
Falla de forma impredecible. El DNS inverso es el rincón peor mantenido de la mayoría de las redes. Cuando la búsqueda ptr agota su tiempo o la confirmación hacia delante falla, tu correo legítimo pierde el “pass” de SPF con el que contaba.
Algunos receptores lo omiten por completo. Como el estándar lo declara obsoleto, algunas implementaciones simplemente ignoran ptr, de modo que los remitentes que se suponía debía autorizar nunca estuvieron protegidos en primer lugar.

De dónde viene

Casi nadie elige ptr hoy en día. Llega por herencia: una guía de configuración escrita en 2009, una plantilla copiada de una vieja configuración de servidor, un registro “que funciona” migrado intacto a través de tres cambios de alojamiento. Ese es el patrón que ve nuestro censo en cada mecanismo obsoleto-pero-presente: el viejo consejo no muere, se copia y se pega. Los dominios que arrastran ptr no son descuidados: están siguiendo instrucciones que se retiraron hace 12 años.

Cómo arreglarlo: gratis, cinco minutos

Encuentra tu registro SPF (dig TXT tudominio.com o compruébalo gratis).
Si contiene ptr, identifica qué servidores dependían de él.
Sustituye el ptr por la forma precisa: un bloque ip4:/ip6: para los servidores que controlas, o el include: que documenta tu proveedor.
Ya que estás ahí, confirma que el registro termina con un calificador real: consulta ~all frente a -all.

Preguntas frecuentes

¿Qué significa ptr en un registro SPF? Autoriza a cualquier servidor cuyo DNS inverso resuelva dentro de tu dominio. El RFC 7208 §5.5 lo declaró obsoleto en 2014 por lento y poco fiable, y dice que NO DEBERÍA usarse; aun así, 950.631 dominios lo siguen publicando a 2026-06-29.

¿Es válido alguna vez el mecanismo ptr de SPF? Todavía se analiza, y algunos receptores aún lo evalúan, pero el estándar desaconseja su uso en todos los casos, algunos receptores lo ignoran y gasta una de tus diez consultas DNS. No existe ninguna configuración moderna en la que ptr sea la respuesta correcta.

¿Qué debería usar en lugar de ptr? Bloques ip4:/ip6: para los servidores que controlas, o el include: documentado por tu proveedor. Ambos son deterministas, rápidos y fiables: todo lo que ptr no es.

¿Cuenta ptr para el límite de 10 consultas de SPF? Sí: cada ptr cuesta al menos una de las diez consultas DNS que un receptor realizará antes de darse por vencido con un PermError. En registros ya saturados de mecanismos include:, el mecanismo muerto puede ser el que te empuje por encima del límite.

Comprueba si tu registro tiene fantasmas

Un mecanismo declarado obsoleto hace 12 años, todavía asentado en tu DNS, es exactamente el tipo de cosa que nadie busca. Buscarlo lleva medio minuto.

Comprueba tu dominio → · Arregla SPF → · Dos registros SPF = ninguno → · El modelo de madurez de SPF → · Solo datos agregados. Datos almacenados y procesados en la UE.