Cada día se envían millones de correos electrónicos con direcciones de remitente falsificadas. Los ciberdelincuentes suplantan su dominio para engañar a sus clientes, empleados y socios. Sender Policy Framework —SPF, en sus siglas en inglés— es una de las defensas más antiguas y más ampliamente desplegadas contra este problema. Comprender cómo funciona SPF, qué puede y qué no puede hacer, y por qué importa especialmente en el contexto de DMARC es esencial para cualquier organización seria en materia de seguridad del correo electrónico.

¿Qué es SPF?

Sender Policy Framework es un estándar de autenticación de correo electrónico descrito en RFC 7208. Permite al propietario de un dominio publicar en DNS una lista de servidores de correo y direcciones IP autorizadas para enviar mensajes en nombre de ese dominio. Cuando un servidor receptor recibe un correo, puede consultar esa lista y comprobar si el servidor remitente figura en ella.

SPF opera a nivel de sobre, concretamente sobre la dirección MAIL FROM (también denominada return-path o remitente del sobre). Es la dirección que el servidor remitente utiliza en la transacción SMTP; no es necesariamente la dirección que usted ve en el campo "From" de su cliente de correo. Esta distinción es crítica y volveremos a ella cuando hablemos de la alineación DMARC más adelante.

Por sí solo, SPF es un primer filtro útil. Sin embargo, tiene limitaciones bien conocidas, razón por la cual funciona mejor cuando se combina con DKIM y está regulado por DMARC.

Cómo funciona SPF — paso a paso

Cuando un servidor de correo recibe un mensaje entrante, la evaluación SPF sigue estos pasos:

  1. El servidor receptor extrae el dominio de la dirección MAIL FROM (remitente del sobre) de la transacción SMTP. Si MAIL FROM está vacío —lo que puede ocurrir con las notificaciones de estado de entrega— se utiliza en su lugar el dominio HELO/EHLO (ámbito HELO).
  2. El servidor receptor realiza una consulta DNS TXT para obtener el registro SPF de ese dominio, por ejemplo _spf.example.com o simplemente en example.com.
  3. El servidor evalúa los mecanismos del registro SPF en orden —ip4, ip6, include, a, mx, etc.— para ver si la IP remitente coincide con alguno de ellos.
  4. Cuando se encuentra una coincidencia, el calificador asociado (+, -, ~ o ?) determina el resultado: pass, fail, softfail o neutral. Si ningún mecanismo coincide, el mecanismo all al final proporciona un resultado predeterminado.
  5. El resultado se incluye en las cabeceras del correo y el servidor receptor puede usarlo para decidir si entregar, poner en cuarentena o rechazar el mensaje.

Anatomía de un registro SPF

Un registro SPF es un registro DNS TXT publicado en su dominio. Siempre comienza con v=spf1 y termina con un mecanismo all. Un ejemplo típico es:

v=spf1 include:_spf.google.com include:mailgun.org ip4:203.0.113.10 ~all

Los componentes clave son:

Mecanismo / Modificador Qué hace Ejemplo
v=spf1 Declara el registro como SPF versión 1. Primera etiqueta obligatoria. v=spf1
ip4 / ip6 Autoriza una dirección IPv4 o IPv6 específica o un rango CIDR. ip4:203.0.113.0/24
include Importa el registro SPF de otro dominio (p. ej., un ESP o servicio en la nube). include:_spf.google.com
a Coincide con el registro A (o AAAA) del dominio: la IP del servidor web. a
mx Coincide con las IP de los registros MX del dominio: los servidores de correo entrante. mx
redirect Reemplaza el registro actual por completo con el registro SPF de otro dominio. redirect=_spf.example.com
all Comodín al final. El calificador determina el resultado para todo lo que no coincidió antes. -all (fail), ~all (softfail)

Los calificadores que preceden a cada mecanismo son:

  • + (por defecto, pass): la IP remitente está autorizada.
  • - (fail): la IP remitente está explícitamente no autorizada.
  • ~ (softfail): la IP remitente probablemente no está autorizada; se utiliza como advertencia suave.
  • ? (neutral): no se hace ninguna afirmación sobre la IP remitente.

Resultados SPF explicados: pass, fail, softfail, neutral y más

La evaluación SPF produce uno de varios resultados:

Resultado Significado Causa típica
pass La IP remitente está autorizada por el registro SPF. Todos los remitentes legítimos configurados correctamente.
fail La IP remitente está explícitamente no autorizada (-all). Correo falsificado, o un remitente legítimo no incluido en SPF.
softfail La IP remitente probablemente no está autorizada (~all). La entrega puede producirse igualmente. Fase de transición, o un remitente no registrado.
neutral El dominio no hace ninguna afirmación sobre la IP remitente (?all). Registro explícitamente no comprometido: poco habitual en producción.
none No se encontró ningún registro SPF para el dominio. SPF aún no desplegado, o el dominio no tiene registro TXT.
temperror Se produjo un error DNS transitorio durante la evaluación. Interrupción de DNS, tiempo de espera agotado o problema temporal del resolver.
permerror Error permanente en el registro SPF (error de sintaxis, demasiadas consultas DNS). Registro mal configurado o límite de 10 consultas superado.

Solo un resultado pass puede satisfacer SPF para los propósitos de DMARC; pero eso es solo la mitad de la historia. El dominio también debe estar alineado.

SPF y DMARC — la alineación lo es todo

Aquí es donde muchos administradores se confunden. SPF puede pasar perfectamente —la IP remitente figura en el registro SPF— y DMARC puede seguir fallando. El motivo: la alineación SPF.

DMARC comprueba si el dominio autenticado por SPF (el dominio MAIL FROM / envelope-from) está alineado con el dominio de la dirección Header-From visible: la que sus destinatarios ven en su bandeja de entrada. Hay dos modos disponibles:

  • Alineación flexible (aspf=r, por defecto): los dominios organizacionales deben coincidir. Por ejemplo, bounce.example.com está alineado con example.com.
  • Alineación estricta (aspf=s): los dominios deben ser idénticos. bounce.example.com no está alineado con example.com.

Muchos proveedores de servicios de correo (ESP) y plataformas en la nube utilizan su propio dominio como dirección MAIL FROM cuando envían en su nombre. Google Workspace, Amazon SES, Mailchimp, HubSpot: todos tienen comportamientos predeterminados diferentes. En algunos casos, el pass SPF ocurre para el dominio del proveedor, que no está alineado con el dominio Header-From suyo, lo que hace que DMARC SPF falle aunque el SPF bruto pase.

Cómo DMARCFlow explica la alineación SPF en los informes DMARC

Leer los informes XML de DMARC es tedioso. Los datos brutos le indican si SPF pasó o falló, pero no por qué importa para DMARC. DMARCFlow analiza cada registro de informe agregado DMARC y ejecuta un análisis de información SPF dedicado que traduce el resultado bruto a un lenguaje sencillo. Hay cinco posibles resultados:

Escenario Qué significa
MAIL FROM aligned pass SPF pasó en el ámbito MAIL FROM y el dominio autenticado está alineado con su Header-From. Este es el resultado ideal: DMARC SPF está satisfecho.
MAIL FROM pass, not aligned SPF pasó para un dominio MAIL FROM, pero ese dominio no coincide con el Header-From según el modo de alineación configurado. DMARC SPF falla a pesar del pass SPF.
Only HELO pass Solo el dominio HELO/EHLO produjo un pass SPF. DMARC no evalúa HELO para la alineación, por lo que esto no puede satisfacer DMARC SPF.
MAIL FROM result not a pass Se obtuvo un resultado SPF de MAIL FROM, pero fue fail, softfail, neutral, none, temperror o permerror. Ninguno de estos satisface DMARC.
No relevant SPF results No se encontró ningún resultado SPF de MAIL FROM ni de HELO. Sin ninguna evaluación SPF, DMARC SPF no puede satisfacerse.

En lugar de escudriñar XML críptico, DMARCFlow le muestra exactamente qué escenario se aplica a cada fuente de envío en sus informes, junto con el dominio autenticado, el dominio Header-From y si la alineación tuvo éxito o falló. Esto hace que sea sencillo identificar remitentes mal configurados y tomar medidas específicas.

Problemas SPF comunes y cómo resolverlos

La mayoría de los problemas SPF corresponden a unas pocas categorías recurrentes:

  • Remitentes no incluidos. Ha añadido un nuevo servicio de correo (un CRM, una plataforma de marketing o un proveedor de correo transaccional) pero olvidó agregarlo a su registro SPF. Los correos de ese servicio fallan SPF para su dominio.
  • Discordancia de alineación. Su ESP usa su propio dominio en el campo MAIL FROM. SPF pasa para el dominio del ESP, pero DMARC SPF falla porque el dominio del ESP no está alineado con su Header-From. La solución habitual es configurar un dominio MAIL FROM personalizado (return-path) en el ESP que coincida con su propio dominio.
  • Correo reenviado. Cuando el correo es reenviado por un tercero, la IP remitente cambia. El nuevo servidor remitente no figura en su registro SPF, por lo que SPF falla. Esta es una limitación fundamental de SPF: DKIM gestiona mejor el reenvío, ya que se basa en una firma criptográfica en lugar de en la IP remitente.
  • Softfail en lugar de fail. Usar ~all al final de su registro SPF significa que los mensajes no autenticados producen un softfail en lugar de un fail definitivo. Si bien esto es más seguro durante el despliegue inicial, no aplica un rechazo estricto. Pase a -all una vez que esté seguro de que todos los remitentes legítimos están cubiertos.
  • Múltiples registros SPF. Un dominio debe tener exactamente un registro SPF TXT. Si tiene dos, los servidores de correo que lo evalúen devolverán un permerror y SPF fallará. Combine todos los mecanismos en un único registro.
  • Superar el límite de 10 consultas. Véase la sección siguiente.

Límites de SPF: la trampa de las 10 consultas

SPF impone un límite estricto: la evaluación de un único registro no puede desencadenar más de 10 consultas DNS. Los mecanismos que generan consultas incluyen include, a, mx, ptr y exists. Superar este límite produce un permerror, que cuenta como un fallo SPF a efectos de DMARC.

Este es un problema habitual para las organizaciones que utilizan muchos servicios de terceros. Cada include cuenta como una consulta, pero los includes anidados dentro de ese dominio también cuentan. Google Workspace, por ejemplo, tiene sus propios includes anidados dentro de _spf.google.com. Añada tres o cuatro ESP principales y fácilmente podrá aproximarse al límite o superarlo.

La solución es aplanar su registro SPF —sustituyendo las referencias include por los rangos IP reales a los que se resuelven— o utilizar un servicio SPF gestionado que mantenga automáticamente un registro aplanado. DMARCFlow señala los resultados permerror en los informes e identifica cuándo el límite de consultas es la causa raíz.

Cómo DMARCFlow convierte la complejidad de SPF en claridad

Entender SPF de forma aislada es una cosa. Actuar sobre él en el contexto del tráfico de correo real a través de decenas de servicios y dominios de envío es otra. Aquí es donde DMARCFlow aporta un valor significativo.

DMARCFlow es una plataforma de monitorización e informes DMARC diseñada para hacer que la autenticación del correo electrónico sea comprensible y procesable. En lo que respecta específicamente a SPF, DMARCFlow ofrece:

  • Análisis de información SPF por registro. Cada registro de cada informe DMARC se analiza individualmente. DMARCFlow determina no solo si DMARC SPF pasó o falló, sino por qué, asociándolo a uno de los cinco escenarios de información descritos anteriormente: pass de MAIL FROM alineado, pass de MAIL FROM no alineado, pass solo HELO, resultado de MAIL FROM sin pass, o sin SPF relevante en absoluto.
  • Conciencia del modo de alineación. DMARCFlow lee la etiqueta aspf de su política DMARC real y evalúa cada resultado SPF frente al modo de alineación correcto —flexible o estricto—, de modo que el análisis siempre refleje su configuración real.
  • Análisis de fallos de autenticación. Cuando los fallos SPF aparecen en múltiples registros, DMARCFlow los agrupa, calcula las tasas de fallo y muestra las principales fuentes de envío fallidas para que sepa qué direcciones IP y remitentes investigar primero.
  • Validación de política. DMARCFlow comprueba su política DMARC en busca de problemas de coherencia; por ejemplo, si su modo de alineación es adecuado para su infraestructura de envío y si su nivel de aplicación (none / quarantine / reject) está alineado con las tasas de pass que está viendo.
  • Seguimiento del nivel de madurez. DMARCFlow asigna a su dominio un nivel de madurez DMARC del 0 (sin protección) al 5 (máxima protección con alineación estricta y aplicación completa de reject). La alineación SPF es una entrada directa: si su SPF no está correctamente alineado, alcanzar niveles de madurez más altos queda bloqueado y DMARCFlow le muestra exactamente por qué.
  • Puntuación de seguridad con desglose por componente. Cada dominio obtiene una puntuación de seguridad sobre 100. El desglose muestra de forma transparente cómo SPF, DKIM, la aplicación de política, la cobertura y los informes contribuyen —o restan— a la puntuación global.
  • Motor de recomendaciones. Basándose en sus datos reales, DMARCFlow genera recomendaciones priorizadas y procesables. Si su SPF está fallando debido a un MAIL FROM no alineado en un ESP específico, le indica qué configurar y cómo hacerlo.
  • Cumplimiento RGPD, alojado en la UE. Todos los datos de informes se procesan y almacenan exclusivamente dentro de la Unión Europea. No se retienen datos personales. Esto es importante para las organizaciones sujetas al RGPD y aquellas que gestionan datos de residentes de la UE.
¿Está su SPF correctamente alineado con DMARC?
Ejecute un análisis gratuito y vea sus resultados SPF, el estado de alineación y la puntuación de seguridad en segundos.
Comprobar su SPF

Conclusión

SPF es una pieza fundamental de la autenticación del correo electrónico. Declara qué servidores tienen permiso para enviar correo en nombre de su dominio y proporciona a los servidores receptores una forma de verificar esa afirmación. Pero SPF solo no es suficiente: falla con el reenvío, opera únicamente a nivel de sobre y su valor para DMARC depende por completo de si el dominio autenticado está alineado con la dirección Header-From que sus destinatarios realmente ven.

Comprender los cinco escenarios de alineación SPF —desde un pass alineado limpio hasta un resultado solo HELO sin valor para DMARC— es lo que distingue a las organizaciones que simplemente tienen un registro SPF de las que han asegurado genuinamente su correo. El camino desde "SPF existe" hasta "DMARC aplicado con alineación SPF" requiere visibilidad sobre lo que está ocurriendo realmente en sus flujos de correo.

DMARCFlow proporciona esa visibilidad. Analiza sus informes DMARC, clasifica cada resultado SPF según el resultado de alineación, destaca los patrones de fallo y le ofrece recomendaciones específicas para cerrar las brechas. Ya sea que esté comenzando con la autenticación del correo o ya esté operando con política de quarantine y buscando avanzar hacia reject, DMARCFlow le brinda el conocimiento para avanzar con confianza.