Registro SPF: sintaxis explicada con ejemplos

Referencia completa de la sintaxis de SPF (Sender Policy Framework): cada mecanismo, calificador y modificador, cómo evalúa el receptor el registro TXT y ejemplos de registro SPF listos para copiar.

2 de noviembre de 2026
10 min de lectura
Compartir:
Registro SPF: sintaxis explicada con ejemplos

Introducción

Un registro SPF es una línea de texto, y casi todos se copian de la página de configuración de un proveedor sin que nadie los lea. Funciona hasta que añades un segundo servicio, llegas al límite de consultas o ves un permerror en un informe DMARC.

Esto es una referencia de la sintaxis de SPF (Sender Policy Framework) tal como la define el RFC 7208: qué significa cada parte del registro, cómo lo evalúa el servidor receptor y ejemplos para las configuraciones más habituales.

Si antes necesitas ver cómo encaja SPF con DKIM y DMARC, empieza por SPF, DKIM y DMARC: la guía completa.

Qué es un registro SPF

Un registro SPF es un registro TXT de DNS en tu dominio que enumera los servidores autorizados a enviar correo en su nombre. El servidor receptor lo consulta, compara la IP que se conecta con la lista y obtiene un resultado: pass, fail, softfail, etc.

example.com.  3600  IN  TXT  "v=spf1 include:_spf.google.com ~all"

Dos detalles que se suelen confundir:

  • SPF siempre es un registro TXT. El antiguo tipo de registro SPF (tipo 99) quedó obsoleto en 2014. No lo publiques.
  • SPF comprueba el remitente del sobre, la dirección MAIL FROM (que también verás como Return-Path), no el From del mensaje. Si el remitente del sobre está vacío, como en los rebotes, comprueba el nombre HELO.

Anatomía de un registro SPF

Todos los registros SPF tienen la misma estructura:

v=spf1 [mecanismos y modificadores] [all]

Toma este registro:

v=spf1 ip4:203.0.113.10 include:_spf.google.com include:spf.protection.outlook.com -all
Parte Significado
v=spf1 Versión. Va la primera y exactamente así
ip4:203.0.113.10 Esta dirección IPv4 puede enviar
include:_spf.google.com Pueden enviar los servidores autorizados en el SPF de Google
include:spf.protection.outlook.com Pueden enviar los servidores autorizados en el SPF de Microsoft 365
-all Todo lo demás falla

Los términos se separan con un único espacio y se evalúan de izquierda a derecha.

Mecanismos SPF

Los mecanismos describen un conjunto de servidores. Si la IP que se conecta coincide, la evaluación se detiene y el calificador del mecanismo da el resultado.

Mecanismo Ejemplo Coincide cuando ¿Consulta DNS?
ip4 ip4:203.0.113.0/24 La IP está en esa dirección o rango IPv4 No
ip6 ip6:2001:db8::/32 La IP está en esa dirección o rango IPv6 No
a a o a:mail.example.com La IP es una dirección A/AAAA del dominio Sí
mx mx o mx:example.com La IP es uno de los servidores de correo del dominio Sí
include include:_spf.google.com El registro SPF del otro dominio devuelve pass Sí
exists exists:%{i}._spf.example.com La consulta del nombre devuelve algún registro A Sí
ptr ptr:example.com El DNS inverso de la IP termina en el dominio Sí
all -all Coincide siempre No

Sobre los menos evidentes:

  • a y mx sin valor usan el dominio actual. mx en example.com autoriza a los servidores de sus registros MX. Solo sirve si tus servidores de entrada también envían, algo poco habitual con correo alojado.
  • ip4 sin prefijo es una sola dirección (/32). ip4:203.0.113.10 e ip4:203.0.113.10/32 son lo mismo.
  • ptr no debe usarse. El RFC 7208 lo dice expresamente: es lento, poco fiable y algunos receptores lo ignoran.
  • exists con macros es para configuraciones avanzadas que calculan la consulta a partir de la IP del remitente. Si no lo has diseñado a propósito, no lo necesitas.

include no copia el otro registro

Es habitual pensar que include: pega el registro del otro dominio dentro del tuyo. No es así. El receptor evalúa el registro incluido por separado:

  • Si devuelve pass, el include coincide y tu registro devuelve el calificador del include (pass, por defecto)
  • Si devuelve fail, softfail o neutral, el include simplemente no coincide y la evaluación sigue con tu siguiente término
  • Si devuelve permerror o no tiene registro SPF, toda tu comprobación termina en permerror

Por eso el -all del final del registro de Google nunca hace fallar tu correo. Solo tu propio all decide qué pasa con los remitentes que no están en la lista.

Calificadores

Cada mecanismo puede llevar un prefijo que fija el resultado cuando coincide. Sin prefijo, se asume +.

Calificador Resultado Significado
+ pass Autorizado (por defecto, casi nunca se escribe)
- fail No autorizado
~ softfail Probablemente no autorizado; se acepta pero se trata como sospechoso
? neutral No se afirma nada

En la práctica solo verás calificadores en all:

  • -all: lo que no está en la lista falla
  • ~all: lo que no está en la lista da softfail
  • ?all: sin política; rara vez es útil
  • +all: cualquiera en internet puede enviar como tu dominio. No lo publiques nunca.

Modificadores

Los modificadores usan = en lugar de : y cambian cómo se procesa el registro. Cada uno puede aparecer una sola vez.

redirect= pasa la evaluación al registro SPF de otro dominio cuando nada del tuyo ha coincidido. Permite que muchos dominios compartan una misma política:

example.org.  TXT  "v=spf1 redirect=_spf.example.com"

redirect se ignora si el registro contiene un mecanismo all, así que no los combines.

exp= apunta a un registro TXT con un texto explicativo que se devuelve cuando falla. Pocos receptores lo muestran; puedes ignorarlo.

Cómo evalúa SPF el receptor

  1. Toma el dominio del remitente del sobre (MAIL FROM) o el nombre HELO si está vacío.
  2. Consulta los registros TXT de ese dominio y se queda con el que empieza por v=spf1. Si no hay ninguno, el resultado es none. Si hay dos, permerror.
  3. Evalúa los términos de izquierda a derecha. El primer mecanismo que coincide da el resultado.
  4. Si nada coincide y hay un redirect, evalúa el registro de destino.
  5. Si nada coincide y no hay redirect, el resultado es neutral.

Durante todo el proceso, el receptor cuenta las consultas DNS. Más de 10 términos que consultan DNS (include, a, mx, ptr, exists, redirect), incluidos los anidados, dan permerror. Más de 2 consultas vacías (nombres que no devuelven nada) también dan permerror.

Si tu registro está cerca de ese límite, Registro SPF: demasiadas consultas DNS explica cómo reducirlo.

Ejemplos de registro SPF

Sustituye example.com por tu dominio. Incluye solo los servicios que de verdad envían correo como tu dominio.

Solo Google Workspace:

v=spf1 include:_spf.google.com ~all

Solo Microsoft 365:

v=spf1 include:spf.protection.outlook.com ~all

Microsoft 365 y tu propio servidor:

v=spf1 ip4:203.0.113.10 include:spf.protection.outlook.com ~all

Google Workspace y una plataforma de marketing:

v=spf1 include:_spf.google.com include:spf.brevo.com ~all

Un dominio que nunca envía correo:

v=spf1 -all

Es el registro adecuado para dominios aparcados y para dominios que solo tienen una web. Indica a los receptores que cualquier correo que diga venir de ese dominio es falso.

Varios dominios con una política común:

_spf.example.com.  TXT  "v=spf1 include:_spf.google.com ip4:203.0.113.10 ~all"
example.com.       TXT  "v=spf1 redirect=_spf.example.com"
example.org.       TXT  "v=spf1 redirect=_spf.example.com"

Un subdominio de envío con su propio registro (por ejemplo, Amazon SES con un MAIL FROM personalizado):

mail.example.com.  TXT  "v=spf1 include:amazonses.com ~all"

Los subdominios no heredan el SPF del dominio principal. Cada nombre que se use como remitente del sobre necesita su propio registro.

Registros de más de 255 caracteres

Una sola cadena de un registro TXT no puede superar los 255 caracteres. Los registros SPF más largos se dividen en varias cadenas entre comillas, que el receptor une sin espacio entre ellas:

example.com.  TXT  "v=spf1 ip4:203.0.113.10 ip4:203.0.113.11 include:_spf.google.com " "include:spf.protection.outlook.com ~all"

Fíjate en el espacio al final de la primera cadena. Sin él, el registro unido queda como ..._spf.google.cominclude:... y se rompe. La mayoría de los paneles de DNS dividen los valores largos por ti; comprueba el resultado con una consulta.

Mantén también la respuesta pequeña: un registro SPF muy largo suele indicar que necesita menos includes, no más cadenas.

Errores de sintaxis habituales

Error Ejemplo Solución
Dos registros SPF Dos registros TXT con v=spf1 Fusiónalos en uno (cómo)
Versión mal escrita v=spf, o v=spf1 con un carácter de más Exactamente v=spf1
Espacio tras los dos puntos include: _spf.google.com include:_spf.google.com
Falta el all v=spf1 include:_spf.google.com Termina con ~all o -all
Términos después de all v=spf1 -all include:... all va al final; lo que venga detrás se ignora
+all v=spf1 +all No autorices nunca a todo el mundo
Comillas tipográficas copiadas de un documento “v=spf1 ...” Texto plano, comillas rectas o ninguna
Registro en el nombre equivocado www.example.com en vez de example.com Publícalo en el dominio del remitente del sobre

SPF y la alineación DMARC

Un pass no lo es todo. DMARC solo cuenta un pass de SPF si el dominio del remitente del sobre está alineado con el dominio del From. Cuando una plataforma de marketing envía con su propio dominio de rebote (bounces.esp-provider.net), SPF pasa para ese dominio, no para el tuyo.

Por eso muchos proveedores te piden configurar un dominio de rebote (return-path) propio bajo tu dominio, y por eso DKIM firmado con tu dominio suele ser el camino más fiable para pasar DMARC. Fallo de alineación DMARC cubre los dos casos.

Lista de comprobación

  • Hay exactamente un registro TXT que empieza por v=spf1
  • Cada include pertenece a un servicio que envía como tu dominio
  • Sin ptr y sin +all
  • El registro termina con ~all o -all
  • 10 consultas DNS o menos, contando los includes anidados
  • Los dominios que no envían publican v=spf1 -all

Siguientes pasos

  1. Comprueba tu registro y cuenta las consultas: Verificador de SPF →
  2. Construye un registro válido con tus proveedores: Generador de registros SPF →
  3. Encuentra el include de cada servicio: Directorio de servicios de correo →
  4. Comprueba qué remitentes pasan en la práctica: Empieza gratis → — los informes agregados de DMARC muestran los resultados de SPF por origen de envío, así detectas un include que falta antes de que una política bloquee el correo.

Artículos relacionados:

Tags:spfdnsemail-authentication

¿Listo para mejorar la entregabilidad de tus emails?

Empieza a monitorizar tus reportes DMARC y obtén información sobre tu configuración de autenticación.

Comenzar Prueba Gratuita