Qué aprenderá en este artículo
- La sintaxis de los registros SPF es el conjunto de reglas de formato que define cómo se escribe un registro TXT de SPF en el DNS. Si la sintaxis es incorrecta, la autenticación puede fallar incluso cuando las fuentes de envío previstas sean correctas.
- Todo registro SPF válido debe comenzar con «v=spf1» y, a continuación, incluir los mecanismos, los modificadores opcionales y una política de cierre. La ausencia o la duplicación de las etiquetas de versión pueden invalidar el registro.
- Entre los mecanismos SPF más habituales se encuentran «ip4», «ip6», «a», «mx» e «include», mientras que los calificadores como «-», «~» y «?» influyen en la forma en que los servidores receptores interpretan las coincidencias y las no coincidencias.
- La sintaxis de SPF no es lo mismo que la estrategia de SPF. La sintaxis consiste en escribir el registro correctamente. La estrategia consiste en decidir a qué remitentes debe autorizar su dominio y cuál debe ser el grado de rigor de su política.
El SPF suele parecer sencillo hasta que uno tiene que crear o solucionar problemas con el registro por sí mismo. El problema no consiste únicamente en saber a qué remitentes autorizar. Se trata de saber cómo expresarlas correctamente en el sistema de nombres de dominio, de modo que los servidores receptores puedan interpretar la política tal y como usted pretendía.
¿En qué consiste la sintaxis de los registros SPF?
La sintaxis de los registros SPF consiste en la estructura y las normas de formato que se utilizan para crear un registro TXT SPF válido. En la práctica, se trata del lenguaje que utiliza un dominio en el DNS para indicar a un servidor receptor qué fuentes de correo están autorizadas a enviar mensajes en su nombre.
Esto es importante porque la sintaxis de SPF controla cómo se expresan las fuentes de envío autorizadas en un registro TXT del DNS. Si la sintaxis es incorrecta, la autenticación SPF puede fallar incluso aunque figuren en la lista los remitentes correctos. Además, resulta útil diferenciar entre sintaxis y estrategia: la sintaxis del SPF es la capa de formato que permite que los sistemas de correo puedan leer una política, mientras que la estrategia determina qué remitentes se autorizan y cuál debe ser el nivel de rigor de la política.
Componentes fundamentales de la sintaxis de los registros SPF
Un registro SPF se compone de un pequeño número de elementos fundamentales: la etiqueta de versión, los mecanismos, los calificadores y los modificadores. En conjunto, indican al servidor receptor qué debe comprobar, cómo debe interpretar el resultado y qué debe hacer cuando no haya ningún mecanismo anterior que se ajuste a la situación. La especificación trata los mecanismos y los modificadores de forma diferente, aunque ambos aparezcan dentro del mismo registro TXT.
Mecanismos del SPF
Los mecanismos son los términos de coincidencia de un registro SPF. Ellas determinan qué fuentes están autorizadas. En los registros reales, los más habituales son:
- ip4 e ip6 para rangos específicos de IPv4 o IPv6
- a) para autorizar la dirección IP devuelta por un registro A o AAAA
- mx para autorizar las direcciones IP de los servidores del registro MX del dominio
- incluir para hacer referencia a la política SPF de otro dominio y evaluarla
- todo ello como mecanismo de última instancia de carácter general
Estos mecanismos son habituales, ya que reflejan la forma en que suele enrutarse el correo electrónico corporativo. Las direcciones IPv4 e IPv6 se utilizan para infraestructuras de envío conocidas; «mx» es habitual cuando el servidor de correo del dominio también envía mensajes, y «include» se utiliza ampliamente en plataformas en la nube como Microsoft 365 y Google Workspace.
También es posible que se encuentre con «exists» o «ptr», pero ambos requieren precaución. El RFC de SPF indica explícitamente que no se debe utilizar «ptr», y «exists» es un mecanismo más avanzado y que se presta a un uso indebido con mayor facilidad que los mecanismos en los que confían la mayoría de las organizaciones.
Clasificatorios del SPF
Un calificativo cambia el significado de un mecanismo. Los resultados prácticos son los siguientes:
- + pasar, aunque el signo más suele darse por supuesto
- - fallar
- ~ softfail
- ? neutro
Estos calificativos influyen en la forma en que el servidor receptor interpreta las comprobaciones del SPF. Una política de cierre más estricta, como «-all», indica al receptor que cualquier mensaje que no cumpla con los criterios de coincidencia debe dar error en la verificación SPF.
Un enfoque de cierre más flexible, como ~all, indica que las fuentes sin correspondencia deben generar un «softfail»; esto se utiliza a menudo durante la transición o cuando aún se están depurando los inventarios de los remitentes. En la práctica, esta elección influye en la aplicación de las normas, la resolución de problemas y, en ocasiones, en la ubicación de los mensajes en la bandeja de entrada en las etapas posteriores.
Modificadores del SPF
Los modificadores son elementos sintácticos especiales que amplían el comportamiento del SPF, en lugar de comparar directamente a los remitentes. Los más relevantes para la mayoría de los lectores del ámbito empresarial son «redirect» y «exp». El RFC de SPF define el campo «redirect» para delegar la evaluación a la política SPF de otro dominio, y el campo «exp» para devolver una explicación personalizada en caso de fallo.
Esto difiere de los mecanismos. Los mecanismos intervienen directamente en la correspondencia, mientras que los modificadores alteran la forma en que se procesa el registro. En entornos más complejos, la redirección puede resultar útil cuando varios dominios comparten el mismo sistema de correo y una misma política debe regir varios dominios relacionados. El RFC también recomienda incluir la redirección al final del registro para mayor claridad.
Etiquetas de versión de SPF
Todos los registros SPF deben comenzar con «v=spf1». Esta es la etiqueta de apertura obligatoria que identifica el registro TXT del DNS como una política SPF. Los servidores receptores utilizan esa etiqueta para saber que el registro debe evaluarse según las reglas del SPF. Si falta la etiqueta de versión, está duplicada o presenta un formato incorrecto, el registro puede considerarse no válido.
¿Cómo es un registro SPF válido?
La estructura estándar de un registro SPF válido es sencilla: comienza con la etiqueta de versión, se añaden uno o varios mecanismos, se incluyen modificadores de forma opcional y, por último, termina con una política de cierre. En términos más sencillos, el formato de un registro SPF válido sigue una estructura clara que los servidores receptores pueden evaluar sin confusiones.
Un ejemplo sencillo de registro SPF es el siguiente:
v=spf1 include:_spf.google.com ~all
Por qué es válido:
- «v=spf1» identifica el registro como SPF
- incluye: _spf.google.com autoriza la infraestructura de envío de Google Workspace
- ~«all» establece una política de «softfail» para las fuentes que no coinciden
Un ejemplo más avanzado de registro SPF es el siguiente:
v=spf1 ip4:192.168.0.10 include:spf.protection.outlook.com -all
Por qué es válido:
- «v=spf1» es la etiqueta de versión requerida
- ip4:192.168.0.10 autoriza una dirección IP concreta
- incluye: spf.protection.outlook.com autoriza las fuentes de envío de Microsoft 365
- -«all» establece un fallo estricto para todo lo demás
En ambos ejemplos, la sintaxis del SPF es correcta, ya que el registro comienza correctamente, utiliza mecanismos reconocidos y concluye con una política clara. La estrategia varía, pero la estructura se mantiene constante.
Normas y validación para un formato SPF correcto
La validez de un registro SPF depende de que su formato sea correcto. El registro debe comenzar correctamente, cumplir con los términos reconocidos del SPF y mantener un orden lógico, ya que los sistemas DNS y de correo electrónico no admiten entradas con formato incorrecto.
Empiece por la etiqueta de versión correcta
Todos los registros SPF deben comenzar con «v=spf1». Si falta la etiqueta de versión, está duplicada o es incorrecta, es posible que el registro se considere no válido. SPF utiliza únicamente una etiqueta de versión válida, por lo que no existe ninguna cadena de versión alternativa de SPF que deba utilizar en su lugar.
Utilice únicamente términos reconocidos en materia de SPF
Los mecanismos, los calificadores y los modificadores deben respetar la sintaxis válida de SPF. Los términos no reconocidos o mal situados pueden afectar a la evaluación. El uso exclusivo de términos SPF admitidos también contribuye a que la política resulte predecible para los servidores receptores y sea más fácil de mantener a medida que cambian los servicios de envío.
Mantenga el registro ordenado de forma lógica
Los registros SPF deben estar estructurados de forma clara, de modo que los mecanismos, los calificadores y los modificadores resulten fáciles de evaluar y mantener. Además, una estructura más clara facilita la resolución de problemas cuando cambia un servicio de envío o surge un problema de autenticación.
Preste atención a los errores sintácticos más comunes
Entre los problemas sintácticos más habituales se encuentran:
- Falta v=spf1
- Calificadores duplicados o con formato incorrecto
- Términos no reconocidos
- Demasiadas consultas en capas a través de «include», «a» o «mx»
- Intentos incorrectos de combinar varios registros SPF
- Ordenar los términos de forma confusa o incorrecta
Incluso los pequeños errores de formato pueden provocar que falle la validación SPF, lo que puede debilitar su estrategia general de autenticación del correo electrónico antes de que DMARC y los informes puedan cumplir su función. Por eso, las comprobaciones sintácticas deberían formar parte de cada actualización de registros, y no solo de la configuración inicial.
Publique únicamente una política SPF por nombre de host
Un dominio no debe publicar varios registros SPF para el mismo nombre de host. La combinación incorrecta de varios registros SPF puede provocar problemas de validación de SPF y fallos de autenticación.
Siga las prácticas recomendadas básicas en materia de SPF
Empiece siempre con v=spf1, mantenga una sintaxis clara y revise el registro periódicamente a medida que cambien los servicios de envío. Los pequeños errores sintácticos pueden impedir la autenticación SPF, por lo que las comprobaciones periódicas forman parte de un buen mantenimiento de los registros a largo plazo.
El objetivo no es únicamente que el registro sea técnicamente válido. El objetivo es mantener la configuración del SPF lo suficientemente clara como para que los cambios no generen nuevos problemas sintácticos con el paso del tiempo; por eso resulta útil validar las actualizaciones mediante una comprobación del registro SPF.
¿Cómo debe estructurar los registros SPF para varios remitentes?
Las organizaciones modernas rara vez envían correos electrónicos desde un único lugar. Es posible que un único dominio tenga que autorizar servidores internos, Microsoft Exchange, Google Workspace, plataformas de soporte y otros servicios de terceros en un único registro SPF.
Para que resulte más manejable:
- Mantenga una estructura clara para que cada mecanismo tenga una finalidad evidente
- Utilice únicamente los remitentes que realmente necesite para evitar inclusiones obsoletas o innecesarias
- Limite la complejidad, ya que los registros largos y con múltiples niveles son más difíciles de revisar y tienen más probabilidades de fallar
- Revise la política periódicamente, ya que los servicios de envío van cambiando con el tiempo
El objetivo no es solo la corrección, sino también la facilidad de mantenimiento. Un buen mantenimiento del SPF favorece tanto la autenticación del SPF como la capacidad de entrega del correo electrónico a largo plazo.
También conviene recordar que el SPF es solo una parte de la autenticación del correo electrónico. Funciona en combinación con DomainKeys Identified Mail y una política DMARC. Aunque un registro TXT de SPF válido no resuelve por sí solo todos los problemas de seguridad del correo electrónico, una sintaxis correcta del registro SPF sigue siendo un punto de control necesario, ya que un registro erróneo debilita la autenticación antes de que las políticas de nivel superior puedan surtir efecto.
Implemente los registros SPF correctos
La conclusión operativa clave es sencilla: la sintaxis de los registros SPF no es solo una cuestión de formato. Es la capa de control la que indica al servidor receptor cómo determinar qué remitentes están autorizados a utilizar su dominio. Si la sintaxis es incorrecta, la autenticación SPF puede fallar incluso aunque sus remitentes autorizados sean los correctos.
Por ello, el diseño de los registros SPF debe encontrar un equilibrio entre la exactitud y la facilidad de mantenimiento. Utilice una estructura clara, evite los registros SPF múltiples, asegúrese de que los mecanismos tengan una finalidad concreta y revise el registro periódicamente a medida que cambien los servicios de envío. Un formato de registro SPF claro facilita la gestión de ese proceso a lo largo del tiempo.
