1. La Regla de las 10 Consultas DNS en RFC 7208 §4.6.4
El protocolo Sender Policy Framework (SPF), definido formalmente en la especificación IETF RFC 7208, impone un límite estricto de seguridad para evitar que los resolvedores de correo queden atrapados en bucles infinitos o sean utilizados como vectores de amplificación en ataques de denegación de servicio distribuido (DDoS).
De acuerdo con la sección 4.6.4 de RFC 7208, durante el proceso de evaluación de un registro SPF, un servidor de correo receptor (MTA) no debe realizar más de 10 consultas DNS acumuladas que requieran resolución de nombres. Si una verificación supera este umbral, el evaluador de SPF debe abortar la resolución inmediatamente y devolver el estado de evaluación permanente: PermError.
PermError, trata el mensaje como un fallo sintáctico grave. Dependiendo de la política DMARC del dominio, el correo será marcado como Spam o rechazado rotundamente antes del procesamiento de entrega.
2. Mecanismos que Consumen Lookups vs Modificadores Directos
No todos los términos presentes en un registro v=spf1 consumen una consulta DNS de la cuota de 10. Es fundamental diferenciar entre los mecanismos de resolución y las directivas de dirección directa.
| Término / Mecanismo | Consumo de Lookup DNS | Explicación y Comportamiento RFC 7208 |
|---|---|---|
| include: | +1 DNS Lookup (recursivo) | Ejecuta una consulta TXT del dominio incluido. Si ese registro contiene más include:, se suman acumulativamente. |
| a / mx / ptr / exists | +1 a +N DNS Lookups | Consultan registros A/AAAA o MX. mx consulta el registro MX y luego cada dirección IP devuelta. |
| redirect= | +1 DNS Lookup | Redirige la evaluación entera a otra zona DNS objetivo. |
| ip4: / ip6: | 0 (Cero Coste) | Compara directamente la IP del remitente contra la notación CIDR dada. Sin consultas de nombres. |
| all / ~all / -all | 0 (Cero Coste) | Modificador por defecto de cierre de regla. Evaluado localmente por la máquina de estado. |
3. El Impacto de la Concatenación de Servicios SaaS
En la arquitectura corporativa moderna, una organización suele integrar múltiples suites de software en la nube para correo transaccional, soporte de clientes y marketing:
Aunque el administrador sólo observa 5 términos include: a simple vista, cada proveedor incluye internamente más registros recursivos. Por ejemplo, Salesforce puede desglosarse en 3 sub-includes, y Google Workspace consume 4. Al evaluar la cadena completa, el cliente excede los 10 lookups y entra inmediatamente en PermError.
4. Diagnóstico Práctico mediante CLI (`dig`)
Para inspeccionar manualmente las consultas generadas por un registro SPF desde la terminal de comandos de administración de sistemas, ejecute las siguientes consultas recursivas con dig:
5. Estrategias de Mitigación: SPF Flattening y Subdominios Dedicados
Para solucionar definitivamente el fallo de PermError, existen dos arquitecturas estándar recomendadas por la ingeniería IETF:
Estrategia A: Segmentación por Subdominios de Envío (Recomendado)
Aísle los servicios de correo según su propósito funcional. De este modo, cada subdominio mantiene un registro SPF limpio con 1 o 2 lookups máximos:
- tu-dominio.com: Correo corporativo humano (Google Workspace) →
v=spf1 include:_spf.google.com ~all - mkt.tu-dominio.com: Envíos masivos (Mailchimp) →
v=spf1 include:servers.mcsv.net ~all - support.tu-dominio.com: Mesa de ayuda (Zendesk) →
v=spf1 include:mail.zendesk.com ~all
Estrategia B: Aplanamiento Automático de SPF (SPF Flattening)
Consiste en resolver dinámicamente todos los mecanismos include: mediante un script de automatización o resolvedor DNS y reemplazar los dominios por sus rangos exactos de direcciones ip4: e ip6:.