El límite SPF de diez consultas DNS se evalúa durante la recepción: un registro puede ser sintácticamente válido y aun así devolver permerror. Simplifica eliminando includes/remitentes innecesarios; no hagas flattening ciego de proveedores dinámicos a IPs que caducarán.
Cuenta mecanismos que hacen DNS
include, a, mx, ptr, exists y redirect consumen presupuesto; los includes anidados también cuentan.
Inventaría remitentes reales
Lista servicios que realmente envían con el dominio. Elimina includes abandonados antes de optimizar para sistemas que ya no existen.
Separa subdominios cuando aporte claridad
Transaccional, marketing o mercados pueden usar identidades separadas y reducir complejidad en el root.
Trata flattening como datos mantenidos
Si lo usas, define refresco y monitorización. Los rangos IP del proveedor pueden cambiar.
Comprueba DMARC
SPF pasando solo sirve para DMARC si alinea, o si DKIM aporta autenticación alineada.
Prueba cada remitente
Envía desde cada plataforma retenida e inspecciona Authentication-Results y la identidad evaluada.
Usa la guía SPF con varios remitentes y valida alineación con la guía DKIM.
Dibuja el árbol de dependencias SPF antes de editar DNS
Expande cada include y redirect en un árbol pequeño y cuenta los mecanismos que generan consultas en cada ruta. Marca propietario y si el remitente sigue activo. A menudo la solución segura es retirar un servicio abandonado o separar un remitente en subdominio, no comprimir un registro cuya complejidad viene de años de proveedores sin inventariar.