¿Qué es SPF y cómo autoriza tus servidores de envío?

Cómo es un registro SPF

SPF es un único registro TXT publicado en la raíz de tu dominio. Aquí tienes un ejemplo típico para una empresa que envía a través de Google Workspace, SendGrid y un servidor propio:

ton-domaine.fr.  IN TXT
  "v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.10 -all"

Desglosémoslo:

• v=spf1 — la versión. Todo registro SPF empieza por ahí; así lo reconoce el destinatario.
• include:_spf.google.com — delega en Google: «todo servidor que Google declare autorizado para este subdominio lo está también para mí».
• include:sendgrid.net — lo mismo para SendGrid, tu proveedor de emailing.
• ip4:203.0.113.10 — una IP concreta, tu servidor propio, autorizada de forma fija.
• -all — el cualificador final: todo lo que no esté listado arriba se rechaza de forma estricta.

Un solo registro, una sola línea (aunque se muestre en varias por legibilidad). Es ya la primera trampa: solo debe haber uno — volvemos a ello.

Los mecanismos, uno por uno

El interior de un registro SPF es una sucesión de mecanismos que el destinatario evalúa de izquierda a derecha hasta encontrar una coincidencia:

• include: — delega la autorización en otro dominio. Es el mecanismo más habitual: tu proveedor (Google, Microsoft 365, SendGrid, Mailchimp…) publica su SPF, y tú lo importas. No tienes que conocer sus IP, que cambian: él las mantiene al día.
• ip4: / ip6: — autoriza una dirección IP concreta o un bloque entero (p. ej. ip4:203.0.113.0/24). Ideal para tus propios servidores, cuya IP es estable.
• a — autoriza las IP presentes en los registros A (o AAAA) del dominio. Práctico si tu servidor web también envía correo.
• mx — autoriza las IP de tus servidores de correo entrante (los registros MX). Útil cuando la misma máquina recibe y emite.
• el cualificador final all — la red de seguridad que decide la suerte de todo lo demás.

Cada mecanismo puede llevar un cualificador: + (autoriza, por defecto), - (rechaza), ~ (softfail), ? (neutro). En la práctica solo se ve sobre all, y la elección ahí es decisiva:

• -all (fail estricto) — todo lo que no esté listado se rechaza. Es el buen objetivo: una postura clara y defendible.
• ~all (softfail) — «probablemente no legítimo, pero deja pasar marcándolo». Útil en fase de despliegue, mientras inventarías todo.
• ?all (neutro) — ninguna opinión. Casi mejor no publicar nada; no protege.
• +all — que NUNCA hay que publicar. Autoriza al mundo entero a emitir para tu dominio. Es el equivalente de una puerta abierta de par en par. Si lo ves en algún sitio, corrígelo de inmediato.

Para el detalle de cada cualificador y de los casos límite, hemos escrito una guía dedicada: entender el mecanismo all en SPF.

La trampa de los 10 lookups DNS

Aquí está el error más frecuente, y el más traicionero porque es silencioso. La RFC 7208 impone que la evaluación de un registro SPF no desencadene más de 10 resoluciones DNS. Cada include:, cada a, cada mx cuenta como al menos una resolución — y un include puede a su vez contener otros, en cascada.

Suma: Google Workspace consume varios lookups, tu proveedor de marketing unos cuantos, tu herramienta de facturación otro tanto, tu atención al cliente aún más… y superas los 10 sin darte cuenta. Por encima, el destinatario devuelve un permerror (error permanente): SPF falla por completo, como si no existiera. Tu correo legítimo puede entonces quedar marcado como sospechoso.

La trampa es traicionera porque el registro parece correcto y funciona mientras te mantienes por debajo del límite — y luego, un día, añades un proveedor más, cruzas el umbral y todo se rompe de golpe sin mensaje de error visible. Detallamos el diagnóstico y las causas en SPF: demasiados lookups DNS, y si quieres entender el propio mensaje de error, qué es un permerror SPF lo aborda paso a paso.

La solución se llama aplanamiento (flattening): reemplazas include: glotones por los bloques ip4:/ip6: correspondientes, resueltos de una vez por todas. Ahorras lookups a cambio de un mantenimiento: si el proveedor cambia sus IP, tienes que regenerar. Es un compromiso que gestionar, explicado en detalle en nuestra guía sobre el aplanamiento de un registro SPF.

Las trampas habituales más allá de los lookups

Otros dos errores rompen SPF de forma discreta:

• Dos registros SPF en el mismo dominio. La RFC es tajante: solo debe existir un único registro TXT que empiece por v=spf1. Si publicas un segundo — a menudo al añadir un proveedor sin tocar el existente —, el destinatario devuelve un permerror y los dos se ignoran. La regla: fusiona todo en un registro único. Dos include adicionales van en la línea existente, no en una nueva.
• +all por descuido. Ya lo hemos dicho, pero merece repetirse: es la peor configuración posible. Un +all (o un all sin cualificador restrictivo, según algunas lecturas) equivale a no tener ninguna protección.

Si no sabes en qué estado está tu dominio, no lo adivines: verifica tu registro SPF en unos segundos. Y si haces malabares entre Microsoft 365 y Google Workspace, el caso particular de la convivencia de los dos include se trata en SPF para Microsoft 365 y Google Workspace.

Un caso concreto: Microsoft 365 y Google Workspace

Tomemos una situación muy frecuente. Una empresa migra de Microsoft 365 a Google Workspace pero mantiene temporalmente ambos activos. El registro queda así:

ton-domaine.fr.  IN TXT
  "v=spf1 include:spf.protection.outlook.com include:_spf.google.com -all"

Cada uno de los dos include desencadena varias resoluciones DNS. Con dos proveedores importantes, ya estás a la mitad del presupuesto de 10 lookups. Añade la facturación, el emailing de marketing y el soporte, y el permerror te acecha. Es el escenario típico en el que el aplanamiento de uno de los dos include se vuelve necesario — y donde se entiende, de forma muy concreta, por qué el límite de lookups SPF merece que lo vigiles antes de que muerda.

Por qué SPF por sí solo no basta

Vuelve a la distinción del principio: SPF valida el sobre (MAIL FROM / Return-Path), no el From: visible. Un atacante puede, por tanto, configurar un SPF perfecto para su propio dominio, pasar el control sin problema y mostrar tu dominio en el From: que tu interlocutor lee. SPF no ve nada: nunca miró esa dirección.

Es un límite estructural, no un bug. SPF hace exactamente aquello para lo que fue diseñado — verificar quién tiene derecho a emitir desde una IP dada para un dominio de sobre. No dice nada sobre la coherencia entre el sobre y el From: mostrado. Esa coherencia se llama alineación, y es DMARC quien la exige.

El trío completo funciona así:

1. SPF — autoriza las IP emisoras (lado del sobre).
2. DKIM — adjunta una firma criptográfica al mensaje, que prueba que no se ha alterado y que viene de un dominio dado.
3. DMARC — vincula SPF y DKIM al From: visible e impone la alineación, y luego dice al destinatario qué hacer en caso de fallo (none, quarantine, reject).

Dicho de otro modo, SPF es necesario pero no suficiente. Es el cimiento; DKIM añade la prueba de integridad; DMARC pone el tejado que por fin protege la dirección que lee el humano. Publicar un buen SPF sin DMARC es como cerrar una ventana dejando la puerta abierta.

Tu hoja de ruta SPF

Para poner un SPF limpio y duradero, procede en este orden:

1. Inventaría tus emisores. Lista todo lo que envía en tu nombre: correo, marketing, facturación, soporte, aplicaciones internas. Siempre se olvida alguno — los informes DMARC ayudan a desenmascararlos.
2. Publica un registro único que empiece por v=spf1, con un include: por proveedor y un ip4:/ip6: por servidor propio.
3. Cuenta tus lookups. Mantente por debajo de 10. Si te pasas, aplana los include más glotones.
4. Termina con -all en cuanto estés seguro de tu inventario (pasa por ~all mientras validas, si prefieres la prudencia).
5. No publiques nunca dos registros ni +all.
6. Encadena con DKIM y luego DMARC — es el único camino hacia una verdadera protección.

No tienes que hacer todo esto a ciegas. Lanza una comprobación gratuita e instantánea de la postura SPF, DKIM y DMARC de tu dominio con nuestro analizador DMARC gratuito: te muestra tu SPF actual, cuenta tus lookups, detecta los duplicados y te da una nota clara. Y cuando quieras pasar de la vigilancia a la protección real, Thomas, tu CISO virtual, nombra cada emisor, genera el DNS exacto para pegar y te dice cuándo endurecer sin romper un solo correo legítimo.

Analiza tu dominio gratis → y ve en qué punto está tu SPF en unos segundos.