"SPF Record Not Found" — ¿pero usted tiene uno? Las 5 causas reales (2026)

Publicado 2026-07-08

Cifras a fecha de 2026-06-29 · metodología v7. Datos agregados del censo sobre 261 millones de dominios calificados. Consulte cómo calificamos.

Si un verificador dice “SPF record not found” pero usted está seguro de haber publicado uno, el registro normalmente está invisible, no ausente: 1.013.416 dominios — aproximadamente uno de cada 138 de los que intentan SPF — publican dos o más registros SPF, un PermError (RFC 7208 §3.2) que muchos verificadores reportan como no encontrado, según el censo de Defaults.Exposed de 261 millones de dominios.

Hay cinco causas reales, todas arreglables en una sola sentada: host equivocado, registro duplicado, tipo de DNS incorrecto o comillas destrozadas, servidores de nombres incoherentes, o una colisión de longitud/CNAME. A continuación: la prueba de 60 segundos para cada una, en el orden en que comprobarlas, y luego los pasos de reparación.

¿Está seguro de que el registro existe de verdad?

Empiece por la posibilidad menos halagadora, porque es con diferencia la más común: de los 261.086.232 dominios calificados en el censo de Defaults.Exposed, 121.145.609 — el 46,4% — no tienen ningún registro SPF. Muchos casos de “pero si yo lo configuré” resultan ser un registro añadido a una zona de pruebas o a un proveedor de DNS antiguo que ya no es autoritativo. Compruebe en el proveedor de DNS al que apuntan realmente sus servidores de nombres (a menudo no es su registrador) si hay un registro TXT que empiece por v=spf1. Si de verdad no está ahí, sáltese el trabajo detectivesco y vaya directamente a arreglar su registro SPF.

¿Cómo se comprueba un registro SPF correctamente?

Los verificadores web consultan el DNS a través de su propio resolutor con caché. Para ver la verdad, pregunte directamente al servidor de nombres autoritativo de su dominio:

# find the authoritative nameservers
dig NS yourdomain.com +short

# ask one of them directly for TXT records
dig TXT yourdomain.com @ns1.yourdnshost.com +short

En Windows: nslookup -type=TXT yourdomain.com ns1.yourdnshost.com.

Dos reglas de interpretación. Primera, cuente las líneas que empiezan por v=spf1 — el recuento importa tanto como el contenido. Segunda, compruebe que consultó el nombre correcto: los receptores evalúan SPF contra el dominio del Return-Path (RFC5321.MailFrom, el “envelope from”) — no la dirección From que ven los destinatarios. Si su herramienta de boletines rebota el correo vía bounce.yourdomain.com, un registro perfecto en el dominio raíz (apex) no es el registro que los receptores consultan.

¿Cuáles son las cinco causas reales?

#	Causa	La prueba de 60 segundos	La solución
1	Registro en el host equivocado (subdominio vs. dominio raíz)	Haga `dig TXT` del dominio exacto de su Return-Path	Publique en el nombre que envía realmente
2	Dos o más registros `v=spf1` = PermError	`dig TXT` devuelve 2+ líneas `v=spf1`	Fusiónelos en exactamente un registro
3	Publicado como registro tipo 99, o comillas destrozadas	Compruebe el tipo de registro y las comillas sueltas	Republique como un único registro TXT limpio
4	Cachés obsoletas / servidores de nombres incoherentes	Consulte cada NS directamente; compare las respuestas	Arregle el servidor rezagado, deje expirar el TTL antiguo
5	División por >255 caracteres o conflicto con un CNAME	Busque fragmentos de cadena rotos o un CNAME en el mismo nombre	Deje que el proveedor divida las cadenas correctamente; mueva el registro fuera del nombre con CNAME

Datos a fecha de 2026-06-29.

1. ¿Está el registro en el host equivocado?

El clásico: SPF añadido en mail.yourdomain.com cuando el correo dice venir de yourdomain.com, o al revés. SPF no se hereda hacia abajo — un registro en el dominio raíz no dice nada sobre los subdominios, y viceversa. Publique exactamente en el nombre de su Return-Path. Un proveedor que envía desde su propio subdominio de rebote necesita un registro en ese subdominio — normalmente un CNAME o TXT que el proveedor facilita (la guía de configuración de SPF en GoDaddy muestra dónde están esos campos).

2. ¿Tiene dos registros SPF?

La causa estrella, y el mensaje de error más engañoso de la autenticación de correo. El RFC 7208 §3.2 es tajante: un dominio debe tener exactamente un registro SPF. Dos o más es un PermError — los receptores tratan su SPF como anulado. Algunos verificadores reportan ese estado con precisión (“multiple records found”); otros reportan el efecto neto: no valid SPF record found. Usted ve un registro en su panel y concluye que el verificador está roto. No lo está — usted tiene un registro de más.

El censo encontró 1.013.416 dominios con dos o más registros SPF — aproximadamente uno de cada 138 de los dominios que intentan SPF — todos ellos con SPF efectivamente apagado. Suele ocurrir durante un cambio de proveedor: el asistente del proveedor nuevo añade un registro nuevo en lugar de editar el antiguo. La solución es una fusión, nunca un segundo registro: combine todo en una única línea v=spf1 … ~all y borre el resto. Nuestro informe de datos dos registros SPF equivalen a ninguno desglosa cómo un millón de dominios llegaron aquí; si empezó tras una migración, vea SPF dejó de funcionar tras cambiar de proveedor. Al fusionar, no concatene a ciegas cada include: — cada uno cuesta consultas DNS contra el límite estricto de SPF de 10, cambiando un no-encontrado por un PermError: too many DNS lookups.

3. ¿Publicó el tipo de registro equivocado — o la interfaz lo destrozó?

El SPF primitivo tenía su propio tipo de registro DNS (tipo 99, literalmente llamado “SPF”). Quedó obsoleto: el RFC 7208 exige TXT, y los receptores no consultan el tipo 99. Algunos paneles DNS todavía ofrecen “SPF” en el desplegable de tipo de registro; elíjalo y su registro será real, bien formado e invisible. Compruebe la columna de tipo y republique como TXT.

El hermano más sutil son las comillas. Pegar un valor envuelto en comillas en un campo que añade sus propias comillas produce ""v=spf1 …"" — que ya no empieza por v=spf1, así que para un verificador no existe. Su salida de dig muestra la verdad; el panel DNS a menudo la oculta cosméticamente.

4. ¿De verdad “sigue propagándose”?

“Dele 24–48 horas para propagarse” es el consejo más sobrerrecetado del DNS. La propagación es solo cachés que expiran: una vez transcurrido el TTL del registro (normalmente 1 hora, rara vez más de 24), todos los resolutores pueden ver la respuesta nueva. ¿Sigue en no-encontrado pasadas 24 horas? La propagación no es la causa.

Los dos culpables reales: el caché negativo — un resolutor que le consultó antes de que añadiera el registro guarda en caché la respuesta “no existe tal registro” hasta que expira el TTL negativo — y los servidores de nombres incoherentes tras una migración, cuando el dominio todavía lista los servidores de nombres del proveedor antiguo junto a los nuevos y medio mundo lee una zona que usted ya no edita. Consulte directamente cada servidor de nombres listado; si las respuestas difieren, ya lo encontró. Arregle la delegación NS en el registrador para que solo sea autoritativo el proveedor que usted edita de verdad.

5. ¿Es el registro demasiado largo, o lo bloquea un CNAME?

Una sola cadena en un registro TXT tiene un máximo de 255 caracteres. Los registros SPF más largos son legales pero deben dividirse en varias cadenas entrecomilladas dentro de un mismo registro — y las interfaces de los proveedores DNS chapucean la división con regularidad, truncando el valor o partiéndolo a mitad de mecanismo de modo que ya no se puede interpretar. Si su registro es largo, busque en la salida de dig un valor que termine abruptamente.

Por separado, el DNS prohíbe un registro TXT en un nombre que ya tiene un CNAME. Si mail.yourdomain.com es un CNAME hacia su proveedor, no puede poner también SPF ahí — algunos paneles lo aceptan y luego sirven solo el CNAME. Ponga el registro donde apunta el CNAME (si lo controla), o reestructure para que el nombre que envía no tenga CNAME. Los proveedores con un manejo limpio de TXT facilitan ambas cosas — vea la guía de configuración de SPF en Cloudflare.

¿Cómo se arregla, paso a paso?

Ejecute el análisis gratuito en defaults.exposed — lee su DNS en vivo y le dice en cuál de los cinco estados está antes de tocar nada.
Confirme qué servidores de nombres son autoritativos (dig NS) y que todos coinciden.
Consulte los TXT en el servidor de nombres autoritativo para el dominio exacto del Return-Path.
Cuente las líneas v=spf1: cero → publique una; dos o más → fusiónelas en una.
Verifique que el tipo es TXT, que el valor empieza exactamente por v=spf1 y que no se colaron comillas sueltas ni truncamientos.
Deje pasar un TTL y luego vuelva a analizar para confirmar que se resuelve limpiamente en todas partes.

Preguntas frecuentes

¿Por qué el verificador dice “not found” si yo veo el registro en mi panel DNS? Normalmente es la causa 2 o la 4: un segundo registro v=spf1 anula ambos — un PermError que algunas herramientas reportan como no encontrado, el estado en que están 1.013.416 dominios a fecha de 2026-06-29 — o su panel no es el DNS realmente autoritativo.

¿Cuánto tardan los verificadores en ver mi arreglo? Un TTL — normalmente una hora, como máximo 24. Más allá de eso, la “propagación” no es la explicación; repase las cinco causas, empezando por la coherencia de los servidores de nombres.

¿Debería usar el tipo de registro “SPF” que ofrece mi panel DNS? No. El tipo 99 está obsoleto; el RFC 7208 exige únicamente TXT. Un registro de tipo 99 es invisible para los receptores modernos.

El registro ya aparece — ¿por qué mi correo sigue fallando SPF? Porque SPF se comprueba contra el dominio del Return-Path, no la cabecera From, y el registro tiene que listar de verdad los servidores que envían por usted. Que aparezca es el paso uno; la guía arreglar su registro SPF cubre cómo conseguir que pase.

¿De verdad es tan común no tener registro SPF? Sí — 121.145.609 dominios, el 46,4% de los 261.086.232 calificados en el censo de Defaults.Exposed (a fecha de 2026-06-29), no publican SPF en absoluto. El no-encontrado es el estado por defecto de internet.

Envíe el informe al propietario

Cuando el registro se resuelva limpiamente, vuelva a ejecutar el análisis y reenvíe el informe calificado al propietario del negocio o al cliente dueño del dominio. Muestra, en lenguaje claro, qué estaba roto, qué arregló usted y dónde está ahora el dominio — exactamente la prueba que le pedirán en las renovaciones del ciberseguro y en los cuestionarios de seguridad de proveedores. El informe es el recibo del trabajo.

Compruebe su registro SPF gratis

Vea en cuál de los cinco estados de no-encontrado está su dominio — de forma privada y solo para el propietario.

Compruebe su dominio → · Arreglar SPF → · SPF se rompió tras cambiar de proveedor → · Cómo calificamos → · Solo datos agregados. Datos almacenados y procesados en la UE.