El protocolo SPF (Sender Policy Framework) es un pilar fundamental en la autenticación del correo electrónico. Su función principal es permitir que los propietarios de un dominio publiquen una lista de direcciones IP y servidores autorizados para enviar correos en su nombre. Cuando un servidor de correo receptor procesa un mensaje, evalúa el registro SPF del dominio del remitente para verificar si el origen es legítimo, ayudando así a prevenir la suplantación de identidad o spoofing.
Para que esta protección sea efectiva, el registro debe estar correctamente estructurado en el Sistema de Nombres de Dominio (DNS) como un registro de tipo TXT. Un error de sintaxis o una configuración de política inadecuada pueden provocar fallos en la entrega del correo o dejar el dominio vulnerable.
Funcionamiento del análisis de registros SPF
El análisis de un registro SPF requiere desglosar cada uno de sus componentes individuales, denominados términos, para evaluar su validez y el impacto que tienen en la infraestructura de red. El proceso se realiza de forma local en el navegador del usuario; el texto introducido no se sube a ningún servidor ni se almacena, garantizando que la información permanezca en el entorno local.
El análisis se divide en tres fases principales:
- Unión de fragmentos: Si el valor introducido contiene fragmentos DNS TXT entrecomillados, estos se unen de forma automática antes de iniciar la evaluación. El límite máximo de longitud aceptado para el procesamiento es de 20.000 caracteres.
- Identificación de términos: Se examina la estructura del texto para clasificar cada elemento según su tipo:
Versión,Mecanismo,ModificadoroDesconocido. - Evaluación de reglas y límites: Se calcula el número de consultas DNS directas que generará el registro y se contrastan los términos con las reglas de sintaxis del estándar SPF.
Es importante destacar que esta evaluación es un análisis estático local. No se realizan consultas DNS activas a internet, no se expanden los objetivos de los mecanismos include o redirect, ni se realizan pruebas de envío con direcciones IP reales.
Estructura y sintaxis de un registro SPF
Un registro SPF se compone de una declaración de versión seguida de mecanismos y, opcionalmente, modificadores. Cada término define una regla que los servidores de correo deben interpretar en orden de izquierda a derecha.
La declaración de versión
Todo registro SPF válido debe comenzar obligatoriamente con el término v=spf1. Este elemento define la versión del protocolo y debe cumplir dos condiciones estrictas:
- Debe ser el primer término del registro.
- No puede aparecer más de una vez en el mismo registro.
Mecanismos comunes
Los mecanismos son directivas que identifican a los remitentes autorizados. Pueden ir precedidos por un calificador que determina el resultado de la evaluación (+ para Pass, - para Fail, ~ para SoftFail, ? para Neutral). Si no se especifica un calificador, se asume el valor por defecto + (autorizado).
ip4eip6: Especifican direcciones IP o rangos de red en formato CIDR autorizados para enviar correos.aymx: Autorizan a las direcciones IP asociadas a los registros A, AAAA o MX del dominio. Ambos requieren realizar consultas DNS.include: Delega la autorización en el registro SPF de otro dominio. Es común cuando se utilizan proveedores de servicios de correo externos.all: Coincide siempre con cualquier remitente. Se ubica al final del registro para definir la política aplicable a todos los correos que no hayan coincidido con los mecanismos anteriores.
Modificadores
Los modificadores son parejas de clave y valor que proporcionan directrices adicionales. El más común es redirect, que indica que la evaluación debe continuar utilizando el registro SPF de otro dominio especificado. A diferencia de los mecanismos, los modificadores no pueden llevar calificadores como +, -, ~ o ?.
El límite de 10 consultas DNS y sus consecuencias
Una de las restricciones más críticas en el diseño de SPF es el límite de 10 consultas DNS. Para evitar ataques de denegación de servicio (DoS) basados en la amplificación de consultas DNS, el estándar establece que la evaluación completa de un registro SPF no debe activar más de 10 consultas de resolución de nombres.
Los términos que computan para este límite de consultas DNS son:
includeamxptrexistsredirect
Los mecanismos ip4, ip6 y all no requieren resolución de nombres, por lo que no suman al contador de consultas DNS.
Si un servidor de correo receptor realiza una evaluación SPF y esta supera el límite de 10 consultas DNS, el protocolo dicta que el receptor debe tratar el resultado como un error permanente (PermError). Esto suele traducirse en el rechazo del correo electrónico o en su desvío directo a la carpeta de correo no deseado, afectando gravemente a la entregabilidad del dominio.
Dado que los mecanismos include y redirect apuntan a registros externos que a su vez pueden contener otros include (consultas anidadas), el número total de consultas reales suele ser mayor que el estimado en una inspección visual del primer registro.
Riesgos de política y errores de sintaxis habituales
Durante la configuración de SPF, existen ciertos patrones que, aunque técnicamente válidos en el DNS, representan fallos de sintaxis o riesgos de seguridad importantes:
| Término o patrón | Tipo de riesgo / Error detectado | Consecuencia práctica |
|---|---|---|
+all |
Riesgo de política grave | Autoriza explícitamente a cualquier servidor de internet a enviar correos en nombre del dominio, anulando la utilidad de SPF. |
?all |
Política neutral | Devuelve un resultado neutral, lo que ofrece muy poca orientación a los servidores receptores sobre cómo tratar el correo no verificado. |
ptr |
Mecanismo desaconsejado | Es un mecanismo lento y poco fiable. No debe publicarse en entornos de producción. |
Términos tras all |
Error de flujo de evaluación | Cualquier término colocado después del mecanismo all es inaccesible, ya que all siempre coincide y detiene la evaluación. |
redirect con all |
Conflicto de directivas | Si el registro contiene el mecanismo all, el modificador redirect se ignora por completo. |
Sin all ni redirect |
Ausencia de política terminal | Si no se define ninguno de estos dos elementos, los remitentes que no coincidan con los mecanismos previos recibirán un resultado neutral. |
Preguntas frecuentes
¿Cómo se calcula la estimación de consultas DNS de SPF?
La estimación cuenta los términos include, a, mx, ptr, exists y redirect del registro pegado. Los registros incluidos y redirigidos pueden añadir más consultas, por lo que una comprobación local no puede conocer el total recursivo final.
¿Qué ocurre si SPF necesita más de 10 consultas DNS?
Los receptores SPF deben tratar como error permanente una evaluación que supere el límite de 10 términos con consulta DNS. El límite abarca toda la cadena de include y redirect, no solo el primer registro.
¿Un resultado sin incidencias demuestra que mi configuración SPF funciona?
No. Esta página solo comprueba el texto que pega. No consulta DNS, no amplía los registros del proveedor, no prueba una IP remitente ni confirma qué devolverá un servidor de correo receptor.