Registro SPF no encontrado: por qué ocurre y cómo solucionarlo

Un verificador dice «no SPF record found», o la cabecera de un mensaje muestra spf=none. Ambos avisos significan lo mismo: el resolvedor pidió los registros TXT de un nombre concreto y ninguno empezaba por v=spf1. No le pasa nada a tu servidor de correo. La pregunta es por qué la respuesta salió vacía, y casi siempre se reduce a haber consultado, o publicado, en el nombre equivocado.

Este artículo es la guía de diagnóstico para esa respuesta vacía. Si tu problema es un registro que existe pero falla, consulta mejor los artículos sobre demasiadas consultas DNS y el límite de 10 consultas.

Qué significa realmente «no encontrado»

SPF vive en un registro TXT normal. El receptor toma el dominio del mensaje (normalmente el remitente del sobre, también llamado dirección de rebote o Return-Path), solicita sus registros TXT y conserva solo aquellos cuyo texto empieza por v=spf1. Si esa lista filtrada queda vacía, el resultado es none. No es un error de sintaxis; es la ausencia de una política.

Es distinto de las otras dos situaciones con las que la gente lo confunde. Cada una tiene su propio resultado y su propia solución.

Causa 1: el registro está en el nombre equivocado

SPF se consulta en el dominio usado en el correo y en ningún otro sitio. No se hereda de un dominio superior ni se busca en www. Un registro publicado en www.example.com no sirve de nada para el correo enviado desde @example.com, y un registro en example.com no sirve para el correo enviado desde @news.example.com.

El error clásico ocurre en los paneles DNS. Para un registro en el apex (el dominio sin subdominio) el campo de host suele ser @, aunque algunos paneles piden dejarlo en blanco o escribir el dominio completo. Lee el texto de ayuda del panel y confirma con una consulta en lugar de fiarte del formulario.

• Registro en www o mail: texto correcto, host equivocado. Muévelo al apex si envías desde @example.com.
• Dominio duplicado: un panel que añade la zona automáticamente convierte example.com en example.com.example.com. Consulta ese nombre y encontrarás ahí tu registro.
• Dominio de envío equivocado: revisaste example.com, pero el remitente del sobre es bounce.example.net o mail.example.com. El receptor miró ese nombre, no el tuyo.

Causa 2: estás revisando un dominio distinto del que usa el correo

La dirección que la gente ve en la cabecera From es una cosa. El remitente del sobre, que es el que evalúa SPF, puede ser otra. Muchos proveedores de servicios de correo usan un dominio de rebote personalizado, y algunos usan su propio dominio por defecto. Entonces SPF se evalúa sobre ese nombre y tu propio registro ni siquiera se consulta en la comprobación.

La cabecera del mensaje indica qué dominio se evaluó (más abajo se explica). Si es un subdominio tuyo, ese subdominio necesita su propio registro aunque el dominio principal tenga uno perfecto. Un subdominio que nunca envía puede publicar v=spf1 -all.

Causa 3: el texto no es una cadena SPF válida

El verificador es estricto con el inicio del valor. El texto debe empezar por v=spf1, con el signo igual y sin espacios dentro. Todos estos casi-aciertos producen «no encontrado»:

• spf1 include:_spf.example.net ~all (falta el v=)
• v=spf include:_spf.example.net ~all (la versión debe ser spf1)
• v = spf1 ... (espacios alrededor del signo igual)
• Texto pegado con comillas tipográficas «inteligentes» copiadas de un documento o de un chat

Las comillas merecen una nota. La mayoría de los paneles DNS alojados añaden las comillas dobles rectas por ti, así que si escribes las tuyas pueden guardarse como caracteres literales. Si una respuesta de dig muestra dos capas de comillas, quita las que escribiste.

Causa 4: la zona que editaste no es la activa

Esta engaña incluso a gente con experiencia. Puedes añadir un registro TXT perfecto en un panel DNS y aun así no ver nada en el DNS público, porque ese panel no es el que consulta internet. El motivo habitual es la delegación.

• Registrador frente a host DNS: el dominio está registrado en una empresa, pero sus servidores de nombres apuntan a otra (una CDN, un proveedor de hosting, un proveedor DNS independiente). Solo está activa la zona de los servidores de nombres delegados. Los registros añadidos en la página DNS del propio registrador, o en una zona olvidada en un proveedor anterior, se ignoran.

Averigua los servidores de nombres delegados con la consulta NS y edita la zona exactamente en ese proveedor. Esto suele explicar mejor que la propagación el típico «lo añadí hace una hora y sigue sin aparecer».

Causa 5: tipo de registro heredado, caché o tiempo

Los primeros borradores de SPF usaban un tipo de registro propio (número 99, llamado SPF). Ese tipo está obsoleto y los receptores evalúan registros TXT, así que un registro publicado solo como tipo SPF es invisible para las comprobaciones modernas. Publica un registro TXT aunque tu proveedor DNS siga ofreciendo un tipo SPF.

El tiempo es el último sospechoso y el más débil. Si un resolvedor ya aprendió que el nombre no tenía registro TXT, puede seguir sirviendo esa respuesta vacía durante un periodo ligado a la configuración de caché negativa de la zona. Consultar directamente al servidor de nombres autoritativo elimina la duda. Nuestro artículo sobre cuánto tarda la propagación DNS explica el mecanismo.

Confirma qué devuelve realmente el DNS

Antes de cambiar nada, hazle al DNS la misma pregunta que hizo el receptor. En Linux o macOS:

dig TXT example.com +short
# a healthy answer includes a line like:
# "v=spf1 include:_spf.example.net ~all"

nslookup -type=TXT example.com

Una respuesta vacía, o respuestas que solo contienen cosas como tokens de verificación de sitio, confirma «no encontrado». Para saltarte la caché de tu propio resolvedor, pregunta directamente a un servidor de nombres: dig TXT example.com @ns1.example.net +short, usando un servidor de nombres obtenido en la consulta NS. Si eso devuelve el registro y tu consulta normal no, se trata de caché. Si ninguna lo devuelve, el registro no está en la zona activa.

El verificador SPF de este sitio consulta los registros TXT del dominio que introduces, conserva los que empiezan por v=spf1 e informa «No SPF record» cuando no encuentra ninguno. Si encuentra uno, además recorre los include y cuenta las consultas. La consulta TXT muestra todos los valores TXT de un nombre, lo que ayuda cuando el registro existe pero está mal formado, porque puedes ver el texto sin procesar.

Lee la cabecera de un mensaje que falló

Abre el origen original de un mensaje entregado y busca la cabecera Authentication-Results que añade el servidor receptor. La parte de SPF indica el resultado y, normalmente, el dominio evaluado. La redacción de la cabecera varía según el receptor, así que toma los ejemplos como un patrón, no como un formato exacto.

spf=none (example.com does not designate permitted sender hosts)
spf=fail smtp.mailfrom=example.com
spf=permerror smtp.mailfrom=example.com

• spf=none: no hay registro en el dominio evaluado. Usa este artículo.
• spf=fail o softfail: existe un registro, pero la IP de envío no está autorizada. Añade el remitente o corrige la política.
• spf=permerror: el registro está roto, ya sea por dos registros o por demasiadas consultas.

Fíjate en el dominio de smtp.mailfrom (o Return-Path). Ese, y no la dirección From, es lo que evaluó SPF. Para ver cómo leer las cabeceras completas, consulta cómo rastrear el remitente original de un correo.

Publica un registro mínimo y seguro

Publica un único registro TXT en el nombre usado en el remitente del sobre. Un registro es una lista de mecanismos que se leen de izquierda a derecha y terminan con un valor por defecto para todos los demás.

• ip4 / ip6: autoriza una dirección o un rango, por ejemplo ip4:203.0.113.25. No cuesta ninguna consulta DNS.
• include: autoriza lo que autorice el registro SPF de otro dominio, por ejemplo include:_spf.example.net. Cuesta una consulta.
• a: autoriza las direcciones IP del registro A (o AAAA) del propio dominio. Cuesta una consulta.
• mx: autoriza los hosts indicados en los registros MX del dominio. Cuesta una consulta; es incorrecto cuando tu host de entrada no es el que envía.
• ~all, -all, ?all: el valor por defecto. ~all es softfail, -all es fail, ?all es neutral.

Empieza con ~all mientras confirmas que todos los remitentes están incluidos y plantéate -all cuando estés seguro. ?all no afirma nada y es sobre todo transitorio. Una lista correcta importa más que el final, ya que los receptores valoran SPF junto con DKIM y DMARC.

Indicaciones rápidas para plataformas habituales

Los menús difieren y cambian, pero los patrones de fallo se repiten. Revisa esto en cada tipo de configuración.

• Microsoft 365 y Google Workspace: ambos publican un include que puedes copiar desde la consola de administración o la guía de configuración. Un «no encontrado» ahí suele significar que el registro fue al proveedor DNS o al host equivocado.
• GoDaddy y otros registradores: si los servidores de nombres se cambiaron a una CDN o a una empresa de hosting, la página DNS del registrador ya no es autoritativa. Edita los registros en el proveedor que muestre la consulta NS.
• Cloudflare: cuando el dominio usa los servidores de nombres de Cloudflare, añade el registro TXT en la pestaña DNS de Cloudflare.

Qué hacen los receptores cuando no hay SPF

SPF none no es un rechazo automático. El estándar deja la decisión a la política local del receptor, así que los resultados varían. Es más probable que el correo sin SPF y sin DKIM ni DMARC que lo compensen parezca sospechoso, y algunos proveedores publican requisitos de autenticación para remitentes masivos. Consulta las reglas vigentes de los proveedores a los que envías.

SPF comprueba el remitente del sobre, así que por sí solo no impide que alguien falsifique tu dirección From visible; eso es trabajo de DMARC. Consulta SPF, DKIM y DMARC explicados y cómo comprobar un registro SPF.