Registro SPF: la guía de referencia completa

La sintaxis de un registro SPF

Un registro SPF es una secuencia de mecanismos, cada uno precedido de un calificador opcional, eventualmente completada con modificadores. Un ejemplo representativo de una empresa que envía a través de una suite ofimática y de un servidor de aplicaciones propio:

ejemplo.es.  IN TXT  "v=spf1 include:_spf.google.com ip4:203.0.113.10 -all"

Los mecanismos

Mecanismo	Función	Coste en lookups DNS
ip4:	Autoriza una dirección IPv4 o un bloque CIDR (ip4:203.0.113.0/24)	0
ip6:	Autoriza una dirección IPv6 o un bloque CIDR	0
a	Autoriza las IP de los registros A/AAAA del dominio (o de otro: a:mail.ejemplo.es)	1
mx	Autoriza las IP de los servidores de recepción (registros MX) del dominio	1 (+ la resolución de cada nombre MX)
include:	Importa la política SPF de otro dominio — el mecanismo de delegación a los proveedores	1 + los lookups del dominio incluido
exists:	Coincide si el nombre construido (generalmente mediante macros) resuelve a un registro A — uso avanzado	1
all	Coincide siempre; colocado al final, decide la suerte de todo lo que no está listado arriba	0

Un octavo mecanismo, ptr, existe en la norma pero está explícitamente desaconsejado en ella: costoso y poco fiable, ya no debería aparecer en ningún registro actual.

Los calificadores

Cada mecanismo puede ir precedido de un calificador que determina el resultado en caso de coincidencia:

Calificador	Resultado si el mecanismo coincide	Uso típico
+ (por defecto)	pass	Implícito: escribir include: equivale a +include:
-	fail	-all: todo emisor no listado es rechazado
~	softfail	~all: sospechoso, aceptado pero marcado
?	neutral	Sin opinión — raramente justificado

En la práctica, el calificador casi solo se ve en all, donde su elección compromete toda la política — volvemos a ello en las buenas prácticas.

Los modificadores

Modificador	Función
redirect=	Sustituye por completo la evaluación por la del dominio designado (cuenta 1 lookup). Útil para centralizar la política de varios dominios en un solo lugar.
exp=	Apunta a un registro TXT cuyo texto sirve de mensaje de explicación en caso de fallo. Pocos destinatarios lo muestran realmente.

redirect= difiere de include: en un punto esencial: include: importa una política además del resto del registro, mientras que redirect= lo sustituye por completo (solo se aplica, además, cuando ningún mecanismo ha coincidido, y hace inútil un all local).

Un último detalle de sintaxis a menudo ignorado: una cadena TXT está limitada a 255 caracteres. Un registro más largo debe dividirse en varias cadenas dentro del mismo registro TXT — los destinatarios las concatenan. Lo que está prohibido es publicar dos registros SPF distintos, como veremos.

El límite de 10 lookups DNS y sus salidas

La RFC 7208 impone un tope estricto: la evaluación de un registro SPF no debe desencadenar más de 10 resoluciones DNS. Cuentan en este presupuesto los mecanismos include:, a, mx, ptr y exists:, así como el modificador redirect= — y el recuento es recursivo: un include: que contiene otros tres consume cuatro lookups él solo. Los mecanismos ip4:, ip6: y all no cuestan nada. La norma limita además a 2 las resoluciones «vacías» (que no devuelven ningún resultado), un segundo techo menos conocido que produce los mismos síntomas.

Superado el límite, el destinatario devuelve un permerror: el registro se considera inválido y SPF falla por completo, como si no existiera. El peligro es que la avería es silenciosa y diferida: el registro funciona durante meses por debajo de la barrera, luego la adición de un proveedor más la cruza, y el correo legítimo empieza a fallar sin que ningún mensaje de error llegue a nadie. Nuestra guía sobre el límite de lookups de SPF detalla las reglas exactas de recuento y el diagnóstico paso a paso.

Las salidas, por orden de preferencia:

1. Hacer inventario y podar. La mayoría de los registros hinchados contienen entradas include: de proveedores abandonados hace años. Cada mecanismo debe corresponder a un emisor real y actual.
2. Preferir ip4:/ip6: para los servidores con IP estable. Un servidor de aplicaciones propio no necesita un include:: su bloque de direcciones, publicado directamente, cuesta cero lookups.
3. Segmentar por subdominio. Enviar el marketing desde news.ejemplo.es y la facturación desde billing.ejemplo.es da a cada subdominio su propio registro — y por tanto su propio presupuesto de 10 lookups — aislando además las reputaciones.
4. Aplanar como último recurso. El flattening sustituye las entradas include: por los bloques IP a los que resuelven. La ganancia es inmediata, pero el riesgo es real: los proveedores cambian sus rangos de IP sin previo aviso, y un registro aplanado sin mantenimiento acaba rechazando correo legítimo. La técnica, sus variantes automatizadas y sus trampas se tratan en nuestra guía del aplanamiento SPF.

Una vía aún más avanzada — el mecanismo exists: combinado con las macros — permite validar una IP en un solo lookup; es potente pero compleja y se justifica sobre todo en infraestructuras de envío a muy gran escala.

Los resultados SPF: pass, fail, softfail y los demás

La evaluación SPF produce uno de los resultados siguientes, que el destinatario consigna en la cabecera Received-SPF (o Authentication-Results) del mensaje:

Resultado	Significado	Tratamiento habitual
pass	La IP emisora está autorizada por el registro	El mensaje sigue su camino; SPF es utilizable por DMARC
fail	La IP no está autorizada y la política es estricta (-)	Rechazo o fuerte penalización de filtrado
softfail	La IP no está autorizada, política indulgente (~)	Aceptado pero marcado; pesa en la puntuación antispam
neutral	El dominio no se pronuncia (?)	Tratado poco más o menos como una ausencia de SPF
temperror	Error DNS transitorio (timeout, servidor inaccesible)	Reintento posterior, generalmente sin consecuencias
permerror	Registro inválido: sintaxis, duplicado, exceso de lookups	SPF inutilizable — a menudo peor que no tener ninguno

Un séptimo caso, none, significa simplemente que no se ha encontrado ningún registro SPF para el dominio.

Dos de estos resultados merecen una vigilancia particular. softfail se deja a menudo en su sitio indefinidamente cuando solo debía ser una etapa de transición — debilita la postura sin que nada lo exija. Y permerror es el más insidioso: nunca proviene de un atacante sino siempre de un error de configuración del lado del dominio — registro duplicado, falta de sintaxis, exceso de lookups. Nuestro artículo dedicado al permerror de SPF recopila las causas reales y su corrección, caso por caso.

SPF por sí solo no basta: la alineación DMARC

Volvamos a la distinción planteada al principio: SPF valida el dominio del sobre, nunca el From: visible. Un atacante puede por tanto publicar un SPF irreprochable para su propio dominio, emitir desde sus servidores debidamente autorizados — SPF muestra pass — e inscribir su dominio de usted en el From: que leerá su víctima. SPF no ve nada raro: nunca ha mirado esa dirección.

Es DMARC quien cierra esta brecha exigiendo la alineación: para que SPF cuente a ojos de DMARC, el dominio del sobre validado debe corresponder al dominio del From: visible. En modo relaxed (el predeterminado), basta una correspondencia a nivel del dominio organizativo — bounces.ejemplo.es se alinea con ejemplo.es; en modo strict (aspf=s), la igualdad debe ser exacta. El funcionamiento completo de las políticas y de los informes se trata en nuestra página de referencia DMARC.

Esta dependencia revela el talón de Aquiles de SPF: el reenvío. Cuando un servidor intermedio reenvía un mensaje — redirección de un buzón, alias, listas de distribución —, lo reemite desde su propia IP, que evidentemente no figura en el SPF del dominio de origen: SPF falla. Los mecanismos de reescritura como SRS (Sender Rewriting Scheme) «reparan» SPF sustituyendo el dominio del reenviador en el sobre — pero ese dominio ya no se alinea con el From: original, y el fallo no hace más que cambiar de naturaleza.

La conclusión se impone por sí sola: SPF nunca debe cargar solo con la autenticación. DKIM, cuya firma criptográfica viaja dentro del mensaje y sobrevive a la mayoría de los reenvíos, toma el relevo precisamente allí donde SPF se rompe — nuestra página de referencia DKIM detalla su funcionamiento. Un dominio correctamente protegido combina los dos, y deja que DMARC exija que al menos uno de los dos pase alineado.

Recetas SPF: Microsoft 365 y Google Workspace

Las dos grandes suites de envío cubren la inmensa mayoría del correo de empresa; estos son sus registros canónicos.

Microsoft 365 publica el conjunto de sus IP de emisión detrás de un único include:

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

Google Workspace procede igual:

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

En ambos casos, el include del proveedor consume varios lookups él solo (se descompone en sub-includes): el presupuesto de 10 no queda gastado a medias, pero ya no está intacto. Una empresa en coexistencia — migración en curso, entidades separadas — combina los dos en un solo registro:

v=spf1 include:spf.protection.outlook.com include:_spf.google.com -all

Es legítimo y frecuente, pero el presupuesto de lookups restante se reduce en consecuencia: cada proveedor adicional (emailing, facturación, CRM, soporte) tendrá que encontrar su sitio en él. Los casos particulares — subdominios dedicados, conectores, enrutamiento híbrido, el recuento preciso de lookups de cada suite — se tratan en nuestra guía SPF para Microsoft 365 y Google Workspace.

Dos reglas transversales para todos los proveedores: añada solo el include documentado oficialmente por el proveedor (las variantes recogidas en foros son la primera fuente de duplicados y de mecanismos muertos), y añádalo dentro del registro existente — nunca como un segundo registro.

Buenas prácticas para un SPF duradero

Un solo registro SPF por dominio. La regla es absoluta: si existen dos registros TXT que comienzan por v=spf1, los destinatarios devuelven permerror y ambos son ignorados. Este duplicado nace casi siempre de una adición de proveedor hecha con prisas: se crea una nueva línea en lugar de completar la existente. Todo nuevo mecanismo se fusiona en el registro único.

Apunte a -all, tolere ~all en transición. El calificador final es su declaración de política: -all afirma que la lista es exhaustiva y que el resto debe ser rechazado; ~all dice «probablemente ilegítimo, pero déjelo pasar marcándolo». El softfail es un estado de obra en curso, útil mientras se consolida el inventario de emisores — no un destino. En cuanto a +all, autoriza al planeta entero a emitir para su dominio y debe corregirse en cuanto se detecta. Los matices entre estas variantes se diseccionan en SPF -all o ~all: la diferencia.

Cubra también los dominios que no envían nada. Un dominio aparcado se protege con la política vacía v=spf1 -all: ningún servidor está autorizado, y la suplantación se vuelve detectable de inmediato.

Vigile, no suponga. Un registro SPF vive: los proveedores cambian, los equipos añaden otros nuevos, las IP se mueven. Los informes agregados DMARC son el único medio de ver quién emite realmente en nombre del dominio y dónde falla SPF; una revisión periódica del registro a su luz evita la erosión silenciosa. Ante una duda inmediata, verificar su registro SPF solo lleva unos minutos, y nuestro comprobador SPF gratuito cuenta los lookups, detecta los duplicados y califica la postura completa del dominio en segundos.

Piense en la entregabilidad, no solo en la seguridad. Los grandes proveedores de buzones exigen hoy una autenticación correcta para aceptar correo en volumen, y un SPF endeble pesa directamente sobre la colocación en la bandeja de entrada. Si sus mensajes legítimos acaban en spam a pesar de un SPF válido, las causas suelen estar en otra parte — reputación, volumen, engagement — como explican nuestro diagnóstico correos en spam a pesar de SPF y DKIM y nuestra guía de entregabilidad de Gmail.

FAQ

¿Cuánto tarda en aplicarse un cambio en SPF?

El plazo es el de la propagación DNS: el valor de TTL del registro TXT, a menudo entre 5 minutos y 24 horas. Los servidores que tienen la versión antigua en caché siguen usándola hasta que expira. Antes de un cambio sensible (paso a -all, retirada de un include), baje temporalmente el TTL para poder dar marcha atrás con rapidez.

¿Se aplica SPF automáticamente a los subdominios?

No. A diferencia de DMARC, SPF no se hereda: cada subdominio que emite correo — o que aparece en una identidad HELO — necesita su propio registro. Un subdominio sin SPF devuelve none, lo que deja el campo libre a la suplantación. De ahí el interés de publicar v=spf1 -all en los subdominios que nunca envían nada.

¿Qué ocurre si mi dominio no tiene ningún registro SPF?

El resultado es none: el destinatario no tiene ningún elemento para juzgar, y la mayoría de los grandes proveedores de correo penalizan o rechazan hoy el correo en volumen no autenticado. Sobre todo, sin SPF ni DKIM, DMARC no puede validar nada: la protección del dominio es inexistente. Publicar un SPF es el primer paso, nunca el último.

¿Se pueden tener dos registros SPF en el mismo dominio?

No — es el error clásico. Dos registros TXT que comienzan por v=spf1 producen un permerror y la invalidación de ambos. Si un proveedor le pide «añadir su SPF», hay que fusionar su mecanismo en el registro existente, en una única y misma línea lógica.

¿SPF cifra o firma mis correos?

Tampoco. SPF es una pura lista de autorización de direcciones IP: no cifra nada, no firma nada y no garantiza la integridad del contenido. La prueba criptográfica de que un mensaje no ha sido alterado corresponde a DKIM, y la coherencia con la dirección visible corresponde a DMARC — los tres son complementarios, no intercambiables.

¿-all o ~all: cuál elegir en la práctica?

~all durante la fase de inventario, -all en régimen estable. Si su registro está completo y verificado con varias semanas de informes DMARC sin falsos negativos, nada justifica quedarse en softfail: -all hace su política exigible y priva a los suplantadores de la zona gris.