Guía de sintaxis de los registros SPF: componentes, reglas, ejemplos y validación
por
Última actualización: 10 10 minutos de lectura
Puntos clave
- El SPF ayuda a verificar si un servidor remitente está autorizado a enviar correos electrónicos en nombre de tu dominio, pero funciona mejor si se utiliza junto con DKIM y DMARC.
- Los registros SPF utilizan mecanismos, calificadores y modificadores para definir los remitentes autorizados y controlar cómo gestionan los servidores receptores el correo que no cumple con los criterios.
- El servidor del destinatario comprueba el registro SPF mediante una búsqueda DNS para verificar la autorización del remitente.
- Las comprobaciones de SPF pueden devolver los resultados «Pass», «Fail», «SoftFail», «Neutral», «None», «TempError» o «PermError», dependiendo de la evaluación del registro y del servidor receptor.
- Los modificadores de SPF, como «exp» y «redirect», ofrecen opciones adicionales de personalización para la validación y la gestión del correo electrónico.
Si alguna vez te has preguntado por qué algunos de tus correos electrónicos legítimos acaban en las carpetas de spam o se bloquean por completo, es posible que el problema radique en cómo está configurada la autenticación del correo electrónico de tu dominio. Un factor clave en este sentido es la sintaxis del registro SPF, que desempeña un papel crucial a la hora de verificar que tus correos electrónicos se envían desde servidores autorizados. Aunque el SPF ayuda a evitar que tus mensajes sean marcados como sospechosos, su sintaxis puede resultar difícil de entender y aún más complicada de configurar correctamente.
En esta entrada, analizaremos cómo funciona la sintaxis de los registros SPF y qué debes tener en cuenta a la hora de configurarlos para tu dominio.
¿En qué consiste la sintaxis de los registros SPF?
La sintaxis de un registro SPF es el conjunto de reglas que definen cómo se escribe un registro SPF (Sender Policy Framework) en el DNS de un dominio. En términos sencillos, es el "lenguaje" que utiliza su dominio para indicar a los servidores de correo receptores qué fuentes están autorizadas a enviar correos electrónicos en su nombre.
La sintaxis de un registro SPF suele incluir mecanismos (como ip4, ip6 o include), calificadores (como +, -, ~ o ?) y modificadores que, en conjunto, determinan si un correo electrónico entrante supera o no la comprobación SPF.
Comprender esta sintaxis es crucial porque incluso un error menor, como un espacio de más, un calificador incorrecto o la falta de un mecanismo, puede hacer que sus correos electrónicos no pasen la autenticación y acaben en spam o sean rechazados.
Nota sobrela alineación de DMARC: SPF valida el dominio del remitente del sobre, que no siempre coincide con la dirección «De» que ven los usuarios en su bandeja de entrada. Para que DMARC supere la validación mediante SPF, el dominio que figura en el campo «Return-Path» debe coincidir con el dominio visible en el campo «De». Por este motivo, SPF debe combinarse con DKIM y DMARC.
Estructura y componentes de la sintaxis de los registros SPF
Un registro SPF se compone de cuatro partes principales: la etiqueta de versión, los mecanismos, los calificadores y los modificadores. Cada parte desempeña una función específica y, en conjunto, determinan cómo gestionan los servidores de correo receptores los mensajes que afirman proceder de tu dominio.
| Componente SPF | Propósito | Ejemplo |
|---|---|---|
| Etiqueta de versión | Identifica el registro como SPF | v=spf1 |
| Mecanismo | Define los remitentes autorizados | ip4:203.0.113.5 |
| Calificador | Define el resultado cuando un mecanismo coincide | -todos, ~todos |
| Modificador | Añade instrucciones de procesamiento opcionales | redirect=, exp= |
Etiqueta de versión
La etiqueta de versión es el punto de partida de un registro SPF. Identifica que el registro utiliza la sintaxis SPF y garantiza que los servidores de correo interpreten correctamente el texto siguiente. Sin ella, el registro no funcionará. Solo se permite una etiqueta de versión, y debe aparecer justo al principio del registro. Formato válido actual: v=spf1.
Operadores de calificación SPF: +, -, ~ y ?
Los calificadores son símbolos que se colocan delante de los mecanismos. Indican al servidor de correo receptor qué debe hacer si el mecanismo coincide. Si no se especifica ningún calificador, la acción por defecto es «Pass».
| Calificador | Resultado | Significado | Caso de uso típico | Nivel de riesgo |
|---|---|---|---|---|
| + | Pasar | Remitente autorizado; correo aceptado | Por defecto — rara vez se indica explícitamente | Bajo |
| - | Falla | Remitente no autorizado; correo rechazado | Aplicación estricta tras la implantación completa | Bajo si está completo |
| ~ | SoftFail | Probablemente no esté autorizado; marcado | Pruebas o implementación transitoria | Medio |
| ? | Neutral | No hay decisión de política; el servidor decide | Se utiliza muy pocas veces en la producción | Alta — sin protección |
Mecanismos SPF: all, ip4, ip6, a, mx, exists e include
Los mecanismos son las reglas principales de un registro SPF. Definen qué servidores, direcciones IP o dominios están autorizados a enviar correo en nombre del dominio. Cada mecanismo se comprueba en orden de izquierda a derecha y, si se encuentra una coincidencia, se aplica el calificador asociado.
| Mecanismo | Ejemplo de sintaxis | Qué autoriza | Consultas de DNS | Uso recomendado |
|---|---|---|---|---|
| todo | -todos | Coincide con todos los remitentes — «catch-all» al final | 0 | Termina siempre con -all o ~all |
| ip4 | ip4:203.0.113.5 | Una dirección IPv4 concreta o un rango CIDR | 0 | Servidores dedicados de salida |
| ip6 | ip6:2001:db8::1 | Una dirección IPv6 específica o un prefijo | 0 | Correo saliente a través de IPv6 |
| a | a o a:example.com | Direcciones IP que coinciden con los registros A/AAAA del dominio | 1 | Cuando el servidor web también envía correos electrónicos |
| mx | mx | Direcciones IP de los servidores MX del dominio | 1 por MX | Cuando los servidores MX envían mensajes salientes |
| ptr | ptr:example.com | Comprobación de DNS inverso (obsoleta según el RFC 7208) | Múltiple | Evitar — en desuso |
| existe | existe:example.com | Se considera correcto si el dominio se resuelve en el DNS | 1 | Uso avanzado con macros |
| incluye | incluir:_spf.google.com | Remitentes autorizados por el dominio mencionado | 1 + anidado | Remitentes externos |
El mecanismo «all»: -all frente a ~all frente a ?all
-all (Rechazo absoluto): Cualquier remitente que no figure en la lista se rechaza explícitamente. Utiliza esta opción una vez que hayas comprobado exhaustivamente tu registro SPF y se hayan incluido todos los remitentes legítimos. Esta es la configuración recomendada para una aplicación estricta.
~todos (SoftFail): Se aceptan los remitentes que no figuran en la lista, pero se marcan como sospechosos. Utiliza esta opción durante las pruebas o en la fase de implantación gradual, cuando aún no estés seguro de que todos los remitentes legítimos figuren en la lista.
?all (Neutro): No se aplica ninguna política a los remitentes que no figuran en la lista. Esto no ofrece ninguna protección real y no se recomienda su uso en entornos de producción.
+all (Pasar todo): Permite que cualquier servidor envíe mensajes en tu nombre. Esto es peligroso y nunca se debe utilizar.
Modificadores SPF: redirect y exp
redirect= (Modificador): Delega la evaluación completa de la política SPF a otro dominio. A diferencia de «include», «redirect» sustituye por completo el registro actual y no se puede combinar con el mecanismo «all». El mecanismo «include» de SPF funciona de manera diferente. Añade remitentes autorizados del registro SPF de un dominio al que se hace referencia sin sustituir el propio.
exp= (Modificador): Proporciona una cadena de explicación personalizada para los errores de SPF. Cuando un mensaje no supera la verificación de SPF, el servidor receptor puede consultar este registro TXT para obtener un motivo comprensible para los usuarios.
«include» frente a «redirect»: diferencia clave
| incluye | redirigir | |
|---|---|---|
| Tipo | Mecanismo | Modificador |
| Efecto | Añade remitentes del dominio al que se hace referencia | Sustituye toda la evaluación del SPF |
| ¿Se puede usar con todo? | Sí | No — todas las anulaciones redirigen |
| Número de consultas DNS | Cuenta para el límite de 10 búsquedas | Cuenta para el límite de 10 búsquedas |
Resultados de la evaluación del FPS y qué significan
Cuando un servidor de correo receptor evalúa un registro SPF, devuelve uno de los siete resultados posibles. Comprender cada resultado ayuda a los propietarios de dominios a diagnosticar los errores de entrega y a mejorar su configuración de SPF. Para conocer estrategias sobre cómo solucionar los errores comunes de SPF, consulta nuestra guía sobre cómo optimizar su registro SPF.
Ejemplos de sintaxis de registro SPF
Registro SPF simple
v=spf1 ip4:203.0.113.5 -all
v=spf1 → etiqueta de versión. ip4:203.0.113.5 → autoriza una dirección IPv4. -all → todos los demás servidores dan error. Se trata de una configuración habitual para un dominio pequeño que envía correo electrónico desde un único servidor.
Registro SPF avanzado
v=spf1 ip4:203.0.113.0/24 include:_spf.google.com include:_spf.mailhost.com ~all exp=explain._spf.example.com
Este registro autoriza un rango completo de IP /24, dos remitentes externos, acepta remitentes no incluidos en la lista con un indicador SoftFail y proporciona una explicación personalizada del error. Cada mecanismo «include», «a», «mx», «exists» y «redirect» activa consultas DNS. Si el total supera los 10, SPF devuelve un PermError.
Ejemplo de registro SPF para empresas
v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:sendgrid.net ~all
Este registro es habitual en organizaciones que utilizan Google Workspace, Microsoft 365 y una plataforma de distribución de terceros. Cada una de estas plataformas añade consultas DNS, por lo que los equipos deben comprobarlas minuciosamente para evitar que se produzcan errores de tipo «PermError».
Ejemplo de gestión de MSP SPF
Para los MSP que gestionan numerosos dominios de clientes, el objetivo no es solo crear un registro SPF válido, sino supervisar los cambios en todos los clientes. La validación centralizada de SPF ayuda a detectar registros duplicados, riesgos relacionados con los límites de consultas y inclusiones erróneas antes de que los clientes sufran problemas de entrega. El Programa de socios MSP/MSSP de PowerDMARC permite a los proveedores de servicios gestionar la autenticación en todos los dominios de sus clientes desde un único panel de control, sin necesidad de cambiar de herramienta ni de analizar manualmente los registros DNS.
Ejemplos de sintaxis del registro SPF TXT según el caso de uso
| Caso de uso | Registro SPF TXT | Explicación | Precaución |
|---|---|---|---|
| Solo servidores MX | v=spf1 mx -all | Solo los servidores MX pueden enviar | Da error si se envía a través de un servidor que no sea MX |
| Una sola dirección IPv4 | v=spf1 ip4:203.0.113.5 -all | Se ha autorizado una dirección IP concreta | Actualizar cuando cambie la dirección IP |
| Varios remitentes | v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~all | Google + Microsoft 365 | Total de búsquedas en el monitor |
| Redirigir | v=spf1 redirect=_spf.example.com | Política delegada | No mezclar con todos |
| No enviar | v=spf1 -todos | Dominio aparcado, sin correo electrónico | Utilizar únicamente para fines distintos al envío |
Cómo utilizar varios mecanismos de inclusión en la sintaxis de los registros SPF
v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:sendgrid.net include:_spf.salesforce.com ~all
Cada mecanismo de inclusión activa al menos una consulta DNS, y las inclusiones anidadas añaden más. El total en toda la cadena no debe superar el 10. El procesamiento del SPF se detiene en la primera coincidencia, por lo que el orden es importante: coloca primero los remitentes más utilizados. Si el recuento de consultas se acerca a 10, utiliza la herramienta de aplanamiento de SPF de PowerDMARC para optimizar tu registro automáticamente. Para configuraciones empresariales complejas, las macros SPF ofrecen una alternativa más escalable a la simplificación tradicional, ya que se expanden dinámicamente en el momento de la evaluación.
Demasiadas consultas DNS en los registros SPF
La RFC 7208 limita a 10 el número total de consultas DNS durante la evaluación del SPF. Este límite se aplica a toda la cadena de consultas, incluidas las consultas anidadas activadas por los mecanismos «include», «a», «mx», «exists» y «redirect». Si se supera el límite, el servidor receptor devuelve un «PermError», lo que provoca que el SPF falle por completo. También existe una restricción menos conocida: el límite de dos consultas nulas. Si más de dos consultas DNS devuelven NXDOMAIN, el SPF también falla. Para obtener una guía detallada sobre cómo resolver esto, consulta cómo solucionar el exceso de consultas DNS.
Mecanismos que cuentan: include (1 + anidados), a (1), mx (1 por cada consulta MX + A), exists (1), redirect (1 + anidados), ptr (varios — en desuso).
Mecanismos que NO cuentan: ip4 e ip6 no activan búsquedas DNS.
Cómo reducir las consultas DNS: Elimina los mecanismos «include» para los remitentes que ya no utilices. Sustituye los mecanismos «a» y «mx» por valores IPv4 explícitos siempre que sea posible. Evita el «ptr». Utiliza PowerSPF (SPF alojado) para consolidar las inclusiones y mantenerte dentro del límite sin necesidad de realizar un mantenimiento manual del DNS. Para obtener más información sobre el proceso de simplificación en sí, consulta «Simplificación de SPF: de la sobrecarga de DNS a un SPF optimizado».
Cómo publicar un registro TXT de SPF en el DNS
El SPF se publica como un registro TXT en el DNS de tu dominio, ya sea en el dominio raíz (por ejemplo, example.com) o en el subdominio correspondiente. Utiliza nuestro generador gratuito de registros SPF para crear un registro válido al instante antes de publicarlo.
| Campo DNS | Valor que hay que introducir | Notas |
|---|---|---|
| Host / Nombre | @ o dejar en blanco para el dominio raíz | Utiliza el nombre del subdominio para los registros SPF del subdominio |
| Tipo | TXT | El tipo SPF heredado (Tipo 99) ha quedado obsoleto; utiliza siempre el tipo TXT |
| Valor | Tu registro SPF completo, por ejemplo: v=spf1 include:_spf.google.com -all | Debe comenzar con v=spf1 |
| TTL | 3600 (1 hora) | Un valor de TTL más bajo acelera la propagación durante los cambios |
Importante: Un dominio solo puede tener un registro TXT de SPF. Publicar varios registros TXT que empiecen por «v=spf1» provoca un PermError.
Flujo de trabajo de validación sintáctica de SPF
Paso 1: Realizar un inventario de todas las fuentes de envío: Microsoft 365, Google Workspace, CRM, herramientas de marketing, sistemas de atención al cliente, nóminas y remitentes regionales.
Paso 2: Escribe o actualiza el registro SPF: añade únicamente mecanismos e inclusiones autorizados.
Paso 3: Comprobar el número de consultas: asegúrate de que el registro no supere el límite de 10 consultas DNS.
Paso 4: Comprueba la sintaxis: utiliza una herramienta de comprobación de SPF para detectar problemas de formato, duplicados y mecanismos obsoletos.
Paso 5: Supervisar los resultados de la autenticación: revisa los informes DMARC para confirmar que los remitentes legítimos cumplen con los requisitos de SPF y DKIM.
Reglas de sintaxis, validación y errores comunes de los registros SPF
Escribir un registro SPF consiste en colocar los mecanismos y calificadores en el orden correcto y asegurarse de que el registro funciona realmente como está previsto. Incluso pequeños errores de sintaxis, como la falta de una etiqueta o un espacio de más, pueden hacer que el registro falle y que los correos electrónicos sean rechazados, marcados como spam o que tu dominio sea vulnerable a la suplantación de identidad.
Esta sección cubre tres áreas clave: mejores prácticas para escribir la sintaxis SPF, errores comunes a evitar y cómo validar su registro antes de publicarlo en vivo.
Siga las mejores prácticas para la sintaxis SPF
Para que el FPS funcione correctamente, hay que seguir unas cuantas reglas de oro para que el registro sea eficaz y fiable:
- Comience siempre con la etiqueta de versión correcta: v=spf1.
- Límite DNS para evitar superar el límite de límite de 10 búsquedaslo que provocaría la rotura del registro.
- Utilice la función incluir para evitar bucles o referencias circulares.
- Mantén los registros lo más concisos posible: las configuraciones excesivamente complejas son más difíciles de mantener y tienen más probabilidades de fallar.
- Revise los registros SPF con regularidad, especialmente si su infraestructura de correo electrónico cambia o si añade/elimina proveedores.
Gestión de la sintaxis de SPF para MSP y MSSP
Para los MSP y los MSSP que gestionan el SPF en numerosos dominios de clientes, las prácticas recomendadas van más allá de crear un único registro correcto. Entre las consideraciones operativas clave se incluyen:
- Estandarizar las plantillas SPF para configuraciones habituales de los clientes (por ejemplo, Google Workspace y Microsoft 365) con el fin de agilizar la incorporación y reducir los errores de sintaxis.
- Automatizar la supervisión del recuento de consultas para recibir alertas antes de que el registro SPF de un cliente supere el límite de 10 consultas DNS, especialmente cuando los clientes añaden nuevas herramientas SaaS.
- Utiliza paneles de control centralizados para detectar simultáneamente registros SPF duplicados, inclusiones erróneas o mecanismos que faltan en todos los dominios de los clientes.
- Documentar los cambios cada vez que se añada un nuevo remitente al entorno de un cliente, con el fin de mantener un registro de auditoría preciso para el cumplimiento normativo y la resolución de problemas.
Evitar errores de sintaxis comunes
Muchos problemas con los FPS se deben a errores simples pero perjudiciales. Tenga cuidado con estas trampas:
- Falta la etiqueta de versión: cada registro debe comenzar con v=spf1.
- Calificadores duplicados: no es válido utilizar más de un calificador para el mismo mecanismo.
- Mecanismos excesivos: los registros largos y sobrecargados aumentan el riesgo de errores y superan los límites del DNS.
- Problemas de formato sintáctico: los espacios mal colocados, los errores tipográficos o los caracteres no admitidos pueden provocar que el registro no se procese correctamente.
- Varios registros SPF: un dominio solo debe tener un registro SPF; si hay más de uno, la validación fallará.
- Mecanismos obsoletos: evita ptr, ya que ha dejado de recomendarse y es posible que no sea compatible con todos los servidores.
Recuerde: aunque la intención del registro sea correcta, los errores de sintaxis harán que SPF falle por completo.
Valide la sintaxis de su registro SPF
Antes de publicar su registro SPF, la validación es fundamental. Los validadores comprueban que la sintaxis sea correcta y que el registro no supere los límites de búsqueda de DNS ni contenga mecanismos no compatibles.
- Utiliza herramientas de comprobación de registros SPF, como la de PowerDMARC verificador de SPF, para identificar rápidamente los problemas.
- La validación ayuda a garantizar que el registro funcione de forma coherente en los distintos servidores de correo receptores.
- Se recomienda probar los registros nuevos o actualizados en un entorno de prueba antes de aplicarlos en directo.
- La validación periódica tras los cambios mantiene su política SPF actualizada y funcional.
Al validar, se reduce el riesgo de que los correos electrónicos reboten, vayan a spam o dejen su dominio vulnerable a la suplantación de identidad.
La sintaxis del registro SPF en acción
Una sintaxis correcta del registro SPF es fundamental para garantizar la entrega segura del correo electrónico y la protección contra la suplantación de identidad. Cada uno de sus componentes —la etiqueta de versión, los mecanismos, los calificadores y los modificadores— interactúa con los demás para determinar cómo gestionan los servidores de correo tus mensajes.
A medida que la adopción del SPF sigue creciendo —con unas tasas de aprobación globales que ya alcanzan el 80,24 %—, las organizaciones que invierten en una sintaxis SPF limpia y validada obtienen una ventaja cuantificable en cuanto a la capacidad de entrega, el cumplimiento normativo y el nivel de seguridad.
Para obtener una guía detallada paso a paso del proceso de configuración inicial, consulta cómo configurar los registros SPF. Y para asegurarte de que cumples con los últimos requisitos de cumplimiento, consulta los requisitos de autenticación de correo electrónico de Google y Yahoo para 2026.
Preguntas frecuentes
1. ¿Cómo se crea un registro SPF?
Empieza con v=spf1, añade mecanismos para enumerar los remitentes autorizados (como ip4: para direcciones IP específicas o include: para servicios de terceros) y termina con un calificador como -all para bloquear todo lo demás. Publica el registro como un único registro TXT de DNS en la raíz de tu dominio.
2. ¿Qué ocurre si la sintaxis de mi registro SPF es incorrecta?
Los servidores de correo pueden rechazar tus correos electrónicos o marcarlos como spam, y tu dominio se vuelve más vulnerable a la suplantación de identidad. Un error de sintaxis, como la falta de una etiqueta de versión, registros SPF duplicados o superar el límite de 10 consultas DNS, puede provocar que el SPF falle por completo.
3. ¿Cuál es un ejemplo de un registro SPF que utilice MX?
Un registro SPF que utiliza MX tiene el siguiente formato: v=spf1 mx -all, lo que permite que solo los servidores de intercambio de correo del dominio envíen mensajes de correo electrónico en su nombre.
4. ¿Cuántas consultas DNS se permiten en un registro SPF?
SPF permite un máximo de 10 consultas DNS por evaluación, tal y como se define en el RFC 7208. Los mecanismos que se tienen en cuenta son: include, a, mx, exists, redirect y ptr. Si se supera este límite, SPF devuelve un PermError.
5. ¿Se pueden tener varios registros SPF para un mismo dominio?
No. Un dominio debe tener un único registro TXT de SPF. La presencia de varios registros que empiecen por «v=spf1» provoca un PermError. Combina todos los remitentes autorizados en un solo registro.
6. ¿Cuál es la diferencia entre SPF -all y ~all?
-all (rechazo definitivo) indica a los destinatarios que rechacen los correos de remitentes que no figuren en la lista. ~all (rechazo temporal) indica a los destinatarios que los acepten, pero que los marquen. Utiliza ~all durante las pruebas y cambia a -all una vez que se hayan confirmado todos los remitentes legítimos.
7. ¿El SPF por sí solo evita la suplantación de identidad en el correo electrónico?
No. El SPF solo valida el remitente del sobre (Return-Path), no la dirección «De» visible. Debe combinarse con DKIM y DMARC para garantizar una protección completa contra la suplantación de identidad y el phishing.
8. ¿Qué es el «SPF flattening» y cuándo lo necesito?
La «aplanamiento» de SPF sustituye los mecanismos «include» por las direcciones IP resueltas, lo que reduce las consultas DNS. Es necesario cuando tu registro SPF supera o se acerca al límite de 10 consultas DNS. Las herramientas automatizadas, como PowerSPF, gestionan esto de forma dinámica.
9. ¿Cuánto tiempo tarda en propagarse un registro SPF?
La propagación del DNS suele tardar entre 1 y 4 horas, dependiendo de tu proveedor de DNS y de la configuración del TTL. En algunos casos, puede tardar hasta 48 horas. Comprueba siempre tu registro tras publicarlo.
Ahona es la Directora de Marketing de PowerDMARC, con más de 5 años de experiencia escribiendo sobre temas de ciberseguridad, especializada en seguridad de dominios y correo electrónico. Ahona tiene un posgrado en Periodismo y Comunicaciones, consolidando su carrera en el sector de la seguridad desde 2019.
Últimas publicaciones de Ahona Rudra (ver todas)
- Seguridad del fax: guía completa para proteger documentos confidenciales en 2026 - 30 de julio de 2026
- ¿Qué es un servicio de filtrado de correo electrónico? - 29 de julio de 2026
- Suplantación de identidad en el correo electrónico: qué es y cómo evitarla - 29 de julio de 2026
