SPF PermError: demasiadas consultas DNS

La RFC 7208 limita la evaluación de SPF a 10 consultas DNS. Cada include:, a, mx, ptr, exists: y redirect= cuesta una, y los include de los include también cuentan. La consulta número 11 hace que los evaluadores devuelvan permerror, y los proveedores de correo lo tratan como "sin SPF válido": DMARC pierde su pata de SPF y los receptores estrictos rechazan tu correo o lo envían a spam.

Por qué ocurre

Los registros SPF crecen por acumulación: cada herramienta SaaS que conectaste alguna vez agregó un include, y los grandes proveedores anidan de 2 a 4 consultas dentro de cada uno. include:_spf.google.com por sí solo son 3 consultas. Con seis include de proveedores ya te pasaste del límite sin haber cambiado nada tú: que un proveedor agregue un include anidado puede hacerte superarlo de la noche a la mañana.

Diagnostícalo

La herramienta de SPF de abajo expande el árbol completo de include y cuenta cada consulta como lo hace un receptor, marcando el total frente al límite, para que veas exactamente qué rama es costosa.

Corrígelo

1. Elimina los include de servicios que ya no usas: casi siempre ahorra de 2 a 4 consultas.

2. Reemplaza los include profundos por IP directas donde los rangos del proveedor sean estables: ip4:198.51.100.0/24 cuesta cero consultas.

3. Nunca uses ptr (obsoleto y costoso) y evita a/mx cuando basta con un ip4.

4. Si de verdad necesitas muchos proveedores, usa un subdominio dedicado por flujo de correo (marketing.tudominio con su propio SPF) o un servicio de aplanamiento de SPF que mantenga por ti la lista combinada de IP.