SPF: quién envía por ti

Cualquier persona en el mundo puede mandar un correo que diga De: ventas@mitienda.com. El protocolo de correo (SMTP) nació en los años 80 sin ninguna verificación del remitente, igual que una carta de papel: puedes escribir cualquier remitente en el sobre. SPF (Sender Policy Framework) es la primera capa de defensa: una lista pública de los servidores que sí tienen permiso de enviar correo en nombre de tu dominio.

En esta lección aprenderás la sintaxis completa, el límite de 10 consultas DNS que rompe tantos SPF, cómo combinar Google Workspace con tu hosting y herramientas de marketing, y cómo comprobar que funciona.

Concepto

Analogía: la lista de invitados del portero

Tu dominio es un edificio y los correos que salen "a tu nombre" son personas que dicen trabajar ahí. El servidor que recibe el correo (Gmail, Outlook, Yahoo) es el portero de otro edificio. Cuando llega alguien diciendo "vengo de parte de mitienda.com", el portero llama a tu recepción (consulta tu DNS) y pregunta: "¿Este señor que viene desde la IP 203.0.113.10 está en tu lista?".

Tu registro SPF es esa lista:

v=spf1 include:_spf.google.com ip4:203.0.113.10 ~all
 │      │                        │               │
 │      │                        │               └─ "A cualquier otro: sospechoso"
 │      │                        └─ "El servidor 203.0.113.10 (mi hosting) sí"
 │      └─ "Todos los servidores de Google Workspace, sí"
 └─ "Esto es una lista SPF versión 1"

Qué dominio revisa SPF exactamente

Este detalle es clave para entender DMARC después. Un correo tiene dos remitentes:

Sobre (envelope)     MAIL FROM: rebotes@mitienda.com   ← lo usa SPF
                     (también llamado Return-Path)

Carta (encabezados)  From: Ventas <ventas@mitienda.com> ← lo que ve el usuario
                     Subject: Tu pedido #1032

SPF revisa el dominio del sobre (MAIL FROM / Return-Path) y la IP que se conecta. No revisa el From: que ve el usuario. Muchas plataformas (Mailchimp, SendGrid, Brevo) usan su propio dominio en el sobre (bounce.mcsv.net, por ejemplo), así que su SPF se evalúa contra su dominio, no el tuyo. Esto explica por qué a veces "no hace falta" agregar su include y por qué DMARC necesita la alineación (lo verás en la lección de DMARC).

El flujo completo

Servidor de Google (IP 209.85.220.41) envía correo con MAIL FROM ventas@mitienda.com
        │
        ▼
Gmail del destinatario:  "¿Qué dice el SPF de mitienda.com?"
        │   consulta DNS: TXT mitienda.com
        ▼
"v=spf1 include:_spf.google.com ip4:203.0.113.10 ~all"
        │
        ├─ ¿209.85.220.41 está en _spf.google.com? → consulta más DNS... → SÍ
        ▼
Resultado: spf=pass

Sintaxis completa

Un SPF siempre empieza con v=spf1 y luego tiene mecanismos que se evalúan de izquierda a derecha. El primero que coincide con la IP decide el resultado.

Mecanismos

Mecanismo	Qué autoriza	Cuenta para el límite de 10	Ejemplo
ip4:	Una IPv4 o un rango CIDR	No	ip4:203.0.113.10, ip4:203.0.113.0/24
ip6:	Una IPv6 o rango	No	ip6:2001:db8::10, ip6:2001:db8::/32
a	Las IP de los registros A/AAAA del dominio	Sí (1)	a (= a:mitienda.com), a:mail.mitienda.com
mx	Las IP de los servidores MX del dominio	Sí (1, más búsquedas de cada MX)	mx
include:	Todo lo que autorice el SPF de otro dominio	Sí (1 + lo que tenga dentro)	include:_spf.google.com
exists:	Avanzado: autoriza si un nombre existe	Sí	Poco usado
ptr	Por DNS inverso	Sí	Obsoleto, no lo uses
all	Cualquier IP (siempre va al final)	No	~all

Y dos modificadores:

Modificador	Para qué	Ejemplo
redirect=	"Usa el SPF de otro dominio en lugar del mío" (cuenta 1 consulta)	v=spf1 redirect=_spf.mitienda.com
exp=	Mensaje explicativo cuando falla (casi nadie lo usa)	—

Calificadores

Cada mecanismo puede llevar un símbolo delante. Si no lleva nada, es +:

Calificador	Resultado	Significado
+ (por defecto)	pass	Autorizado
-	fail	No autorizado, recházalo
~	softfail	Probablemente no autorizado, acéptalo pero márcalo como sospechoso
?	neutral	No digo nada

Por eso +a +mx (como lo escribe cPanel) es idéntico a a mx.

~all vs -all vs ?all

El all final dice qué hacer con todo lo que no está en la lista:

Final	Qué hacen los receptores en la práctica	Cuándo usarlo
?all	Nada. Equivale a no tener SPF	Nunca en producción
~all	Aceptan, pero suma puntos de spam. Con DMARC, cuenta como fallo de SPF	El más recomendado cuando tienes DMARC; también mientras pruebas
-all	Algunos rechazan antes de evaluar DKIM/DMARC	Dominios que no envían correo, o cuando estás 100 % seguro de tu lista

¿Por qué no siempre -all?

Suena más seguro, pero tiene un costo: cuando alguien reenvía tu correo (por ejemplo, un alias universitario que reenvía a Gmail), la IP que entrega ya no es la tuya y el SPF falla. Con -all algunos servidores rechazan ese correo de inmediato, aunque tu firma DKIM fuera válida y DMARC lo hubiera aceptado. Con ~all + DKIM + DMARC, la protección real la da DMARC. Por eso Google y la mayoría de expertos recomiendan ~all cuando ya tienes DMARC.

El límite de 10 consultas DNS

La regla más importante y la menos conocida: evaluar un SPF no puede requerir más de 10 consultas DNS. Si las supera, el resultado es permerror (error permanente) y para DMARC eso cuenta como fallo. Además, no puede haber más de 2 consultas "vacías" (void lookups: nombres que no existen o sin respuesta).

Cuentan: include, a, mx, ptr, exists y redirect. Y cuentan los que están dentro de cada include. No cuentan: ip4, ip6, all.

Ejemplo de conteo

v=spf1 include:_spf.google.com include:spf.protection.outlook.com a mx include:sendgrid.net ~all

include:_spf.google.com            1
   └─ contiene 3 includes más        +3  (_netblocks, _netblocks2, _netblocks3)
include:spf.protection.outlook.com 1
   └─ contiene includes propios      +1 o más
a                                  1
mx                                 1
include:sendgrid.net               1
   └─ ...                           +?
                              ─────────
                     Total aprox:  9 o más  → al borde del límite

Los includes de cada proveedor cambian con el tiempo, así que un SPF que hoy tiene 9 consultas mañana puede tener 11 sin que tú toques nada. Por eso hay que revisarlo con una herramienta que cuente las consultas reales (ver "Cómo probarlo").

Cómo bajar el número de consultas

1. Quita lo que no se usa. El servicio de newsletter que el cliente dejó hace dos años sigue ahí gastando consultas.
2. Cambia a y mx por ip4: cuando conoces la IP. ip4:203.0.113.10 cuesta 0 consultas; a cuesta 1.
3. No agregues include de plataformas que usan su propio Return-Path (Mailchimp, y SendGrid/Brevo/SES con su configuración por defecto). Para ellas lo importante es DKIM con tu dominio.
4. Mueve el envío masivo a un subdominio (news.mitienda.com) que tenga su propio SPF. Cada nombre tiene su propio límite de 10.
5. "Aplanar" (flattening): reemplazar includes por las IP que contienen. Funciona, pero si el proveedor cambia sus IP tu SPF se rompe en silencio. Solo con un servicio que lo actualice automáticamente.

Combinar servicios: recetas para mitienda.com

Referencia de los includes más comunes (verifica siempre la documentación del proveedor, pueden cambiar):

Servicio	Lo que agregas al SPF	Notas
Google Workspace	include:_spf.google.com	Usa 4 consultas
Microsoft 365	include:spf.protection.outlook.com
Zoho Mail	include:zohomail.com	Zoho antes indicaba include:zoho.com; usa lo que diga tu panel
Hosting cPanel	ip4:203.0.113.10 (o a mx, o el include de tu hosting)	cPanel lo sugiere en Email Deliverability
Cloudflare Email Routing	include:_spf.mx.cloudflare.net	Solo reenvío; lo crea Cloudflare
Mailchimp	Normalmente nada	Mailchimp usa su propio Return-Path; configura sus CNAME de DKIM
SendGrid	include:sendgrid.net solo si no usas "Domain Authentication" con CNAME	Con autenticación de dominio, el Return-Path es em1234.mitienda.com (CNAME a SendGrid)
Brevo	Hoy pide sobre todo DKIM y su código brevo-code; algunos planes indican include:spf.brevo.com	Antes era include:spf.sendinblue.com
Amazon SES	include:amazonses.com solo en el dominio de MAIL FROM personalizado (p. ej. bounce.mitienda.com)

Receta 1: Google Workspace + formularios del hosting cPanel

El cliente lee su correo en Gmail (Workspace) y el formulario de contacto de WordPress envía por el SMTP del hosting:

Type:    TXT
Name:    @
Content: v=spf1 include:_spf.google.com ip4:203.0.113.10 ip6:2001:db8::10 ~all

Consultas: 4 (Google). Usar ip4/ip6 en vez de a mx nos ahorra dos.

Receta 2: Workspace + hosting + Mailchimp + SendGrid (transaccional de la tienda)

v=spf1 include:_spf.google.com ip4:203.0.113.10 include:sendgrid.net ~all

• Mailchimp no se agrega: se autentica con sus CNAME de DKIM (k2._domainkey, k3._domainkey).
• include:sendgrid.net solo si SendGrid envía con Return-Path de mitienda.com. Si configuraste su autenticación de dominio, el Return-Path es un subdominio CNAME a SendGrid y el include en la raíz sobra.

Receta 3: dominio que no envía correo

Un dominio que solo tiene la web (por ejemplo mitienda.mx que redirige a mitienda.com) también debe tener SPF, para que nadie lo use para suplantarte:

TXT  @       v=spf1 -all
TXT  _dmarc  v=DMARC1; p=reject;

Aquí -all es perfecto: nadie debe enviar.

Los subdominios no heredan el SPF

El SPF de mitienda.com no aplica a news.mitienda.com. Si envías desde un subdominio (en el sobre), ese subdominio necesita su propio TXT v=spf1 ....

Paso a paso: crear o editar el SPF en Cloudflare

1. Busca si ya existe uno. En DNS → Records, usa el buscador de registros y escribe spf1. O desde la terminal: nslookup -type=txt mitienda.com 1.1.1.1.
2. Si ya existe, pulsa Edit (Editar) en ese registro. Si no existe, Add record.
3. Escribe el registro completo:

   Type:    TXT
   Name:    @
   Content: v=spf1 include:_spf.google.com ip4:203.0.113.10 ~all
   TTL:     Auto

4. Save.
5. Pruébalo (siguiente sección).

Usa el generador

En Herramientas de dominios tienes un generador de SPF: marcas los servicios que usas y te arma el registro, y el consultor DNS en vivo te muestra el SPF actual de cualquier dominio. Úsalos para no equivocarte con la sintaxis.

Errores comunes

Error	Ejemplo	Consecuencia	Solución
Dos registros SPF	Un TXT v=spf1 include:_spf.google.com ~all y otro v=spf1 a mx ~all	permerror: SPF falla para todos	Uno solo: v=spf1 include:_spf.google.com a mx ~all
Más de 10 consultas	Muchos includes	permerror	Ver "Cómo bajar el número de consultas"
Dos all o all en medio	v=spf1 ~all include:_spf.google.com	Todo lo que va después de all se ignora	all siempre al final, una vez
Error de escritura	v=spf1 include:_spf.gogle.com, v=spf 1, ip4: 203.0.113.10	permerror o consultas vacías	Sin espacios después de :; revisa nombres
SPF como tipo "SPF"	Registro de tipo SPF (99)	Obsoleto desde 2014, los receptores lo ignoran	Siempre tipo TXT
+all	v=spf1 +all	Autoriza a todo internet a enviar como tú	Nunca
IPv6 olvidada	El servidor envía por IPv6 y solo pusiste ip4	softfail intermitente	Agrega ip6:2001:db8::10

permerror no es un aviso, es un fallo

Muchos creen que si el SPF tiene un error "simplemente se ignora". No: para DMARC, permerror cuenta como SPF fallido. Si además DKIM no está bien, tus correos fallan DMARC por completo.

Cómo probarlo

1. Consulta el registro

Windows

nslookup -type=txt mitienda.com 1.1.1.1
# Debe salir UNA sola línea que empiece con "v=spf1"

# Ver qué hay dentro de un include (para contar consultas a mano)
nslookup -type=txt _spf.google.com 1.1.1.1

Linux / macOS

dig +short mitienda.com TXT | grep spf1
# Debe salir UNA sola línea

dig +short _spf.google.com TXT
dig +short _netblocks.google.com TXT

2. Usa un validador

• Herramientas de dominios: consultor y generador.
• MXToolbox SPF Record Lookup: muestra el árbol de includes y el total de consultas.
• dmarcian SPF Surveyor: visualiza cada include y avisa si pasas de 10.

3. Envía un correo real y lee los encabezados

Envía un correo desde ventas@mitienda.com a una cuenta de Gmail personal. En Gmail abre el mensaje → menú ⋮ → Mostrar original. Arriba verás un resumen:

SPF:    PASS with IP 209.85.220.41
DKIM:   'PASS' with domain mitienda.com
DMARC:  'PASS'

Más abajo, en los encabezados completos, busca Authentication-Results:

Authentication-Results: mx.google.com;
       spf=pass (google.com: domain of ventas@mitienda.com designates
       209.85.220.41 as permitted sender) smtp.mailfrom=ventas@mitienda.com

smtp.mailfrom es el dominio del sobre que se evaluó. Si ves softfail o permerror, ya sabes por dónde empezar.

Ejercicios

1. Escribe el SPF para: correo en Zoho Mail y formularios que salen por el SMTP del hosting (203.0.113.10, IPv6 2001:db8::10).
2. Corrige este SPF: v=spf1 include:_spf.google.com ~all include:zohomail.com.
3. Un cliente tiene estos dos TXT en @. Únelos en uno:

   v=spf1 +a +mx +ip4:203.0.113.10 ~all
   v=spf1 include:_spf.google.com ~all

4. Cuenta las consultas DNS (sin entrar a los includes de Microsoft) de: v=spf1 a mx ip4:203.0.113.10 include:spf.protection.outlook.com ~all. ¿Cómo bajarías dos?
5. mitienda.net solo redirige a mitienda.com y no tiene correo. ¿Qué SPF le pones?
6. ¿Por qué un correo de Mailchimp puede mostrar spf=pass aunque tu SPF no incluya a Mailchimp?

Ver solución

1. v=spf1 include:zohomail.com ip4:203.0.113.10 ip6:2001:db8::10 ~all
2. El ~all está en medio: todo lo que va después se ignora. Correcto: v=spf1 include:_spf.google.com include:zohomail.com ~all (aunque tener Google y Zoho a la vez solo tiene sentido si de verdad ambos envían).
3. Un solo registro (borra el otro): v=spf1 include:_spf.google.com ip4:203.0.113.10 a mx ~all. Si a y mx resuelven a la misma IP 203.0.113.10, quítalos: v=spf1 include:_spf.google.com ip4:203.0.113.10 ~all. Y si el MX ahora es de Google, mx ya sobra con más razón.
4. a (1) + mx (1) + include de Microsoft (1 + los suyos) = 3 + los internos. ip4 no cuenta. Para bajar dos: reemplaza a mx por ip4: de esas IP (en este caso ya está ip4:203.0.113.10, así que simplemente quítalos si apuntan ahí).
5. v=spf1 -all (y de preferencia un DMARC v=DMARC1; p=reject; en _dmarc).
6. Porque SPF evalúa el dominio del sobre (Return-Path), y Mailchimp usa el suyo (por ejemplo mcsv.net), cuyo SPF sí incluye sus servidores. Ese pass es para el dominio de Mailchimp, no está alineado con tu From:; para que DMARC pase con tu dominio necesitas su DKIM con mitienda.com.

Resumen

• SPF es la lista pública de servidores autorizados a enviar con tu dominio, publicada en un TXT en @ que empieza con v=spf1.
• Evalúa la IP contra el dominio del sobre (Return-Path), no el From: visible.
• Mecanismos: ip4, ip6, a, mx, include; calificadores + - ~ ?; all siempre al final.
• Un solo SPF por nombre. Dos registros = permerror.
• Máximo 10 consultas DNS (contando los includes anidados). Prefiere ip4/ip6 y quita servicios que no uses.
• ~all + DKIM + DMARC es la combinación recomendada; -all para dominios que no envían.
• Comprueba con nslookup/dig, un validador y "Mostrar original" en Gmail.
• Siguiente: DKIM: la firma de tus correos.