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

Cómo es un registro SPF

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

ejemplo.es.  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, el proveedor de emailing.
• ip4:203.0.113.10 — una IP concreta, el 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: el proveedor (Google, Microsoft 365, SendGrid, Mailchimp…) publica su propio SPF, que basta con importar. No hace falta 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 los servidores propios, cuya IP es estable.
• a — autoriza las IP presentes en los registros A (o AAAA) del dominio. Práctico cuando el servidor web también envía correo.
• mx — autoriza las IP de los 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 deje pasar marcándolo». Útil en fase de despliegue, mientras se inventaría 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 el dominio. Es el equivalente de una puerta abierta de par en par. Allí donde aparezca, la corrección es inmediata.

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, la plataforma de marketing unos cuantos, la herramienta de facturación otro tanto, la atención al cliente aún más… y el registro supera los 10 sin que nadie se dé cuenta. Por encima, el destinatario devuelve un permerror (error permanente): SPF falla por completo, como si no existiera. El correo legítimo puede entonces quedar marcado como sospechoso.

La trampa es traicionera porque el registro parece correcto y funciona mientras se mantiene por debajo del límite — y luego, un día, se añade un proveedor más, se cruza 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 para entender el propio mensaje de error, qué es un permerror SPF lo aborda paso a paso.

La solución se llama aplanamiento (flattening): consiste en reemplazar los include: glotones por los bloques ip4:/ip6: correspondientes, resueltos de una vez por todas. Ahorra lookups a cambio de un mantenimiento: si el proveedor cambia sus IP, hay 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. Publicar un segundo — a menudo al añadir un proveedor sin tocar el existente — hace que el destinatario devuelva un permerror y que los dos se ignoren. La regla: todo se fusiona 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.

Ante la duda sobre el estado de un dominio, nada de adivinar: verificar el registro SPF lleva unos segundos. Y para quien hace 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í:

ejemplo.es.  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, el registro ya va por la mitad del presupuesto de 10 lookups. Añadiendo la facturación, el emailing de marketing y el soporte, el permerror 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 vigilancia antes de que muerda.

Por qué SPF por sí solo no basta

Volvamos 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 el dominio de otro en el From: que el destinatario 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.

La hoja de ruta SPF

Para poner un SPF limpio y duradero, el orden es este:

1. Inventariar los emisores. Listar todo lo que envía en nombre del dominio: correo, marketing, facturación, soporte, aplicaciones internas. Siempre se olvida alguno — los informes DMARC ayudan a desenmascararlos.
2. Publicar un registro único que empiece por v=spf1, con un include: por proveedor y un ip4:/ip6: por servidor propio.
3. Contar los lookups. Mantenerse por debajo de 10. Si el registro se pasa, aplanar los include más glotones.
4. Terminar con -all en cuanto el inventario sea seguro (pasar por ~all durante la validación, si se prefiere la prudencia).
5. No publicar nunca dos registros ni +all.
6. Encadenar con DKIM y luego DMARC — es el único camino hacia una verdadera protección.

Nada de esto se hace a ciegas. Una comprobación gratuita e instantánea de la postura SPF, DKIM y DMARC con nuestro analizador DMARC gratuito muestra el SPF actual, cuenta los lookups, detecta los duplicados y da una nota clara. Y a la hora de pasar de la vigilancia a la protección real, Thomas, el CISO virtual, nombra cada emisor, genera el DNS exacto para pegar e indica cuándo endurecer sin romper un solo correo legítimo.

Analizar un dominio gratis y ver en qué punto está su SPF en unos segundos.