Sintaxis del registro SPF: mecanismos, calificadores y límites

Un registro SPF es un único registro TXT de DNS, publicado en la raíz de tu dominio, que empieza por v=spf1, enumera los servidores de correo autorizados a enviar en tu nombre y termina con un mecanismo all que indica a los receptores qué hacer con todo lo demás. v=spf1 include:_spf.google.com ~all es un registro completo y válido. Todo lo demás en la sintaxis SPF son variaciones sobre esas tres partes, más un conjunto de límites estrictos que rompen en silencio registros que por lo demás parecen correctos.

Esos límites importan más de lo que la mayoría espera. En un análisis de 5.499.028 dominios de la lista Tranco realizado el 27 de febrero de 2026, DMARCguard encontró que el 56,0 % publica un registro SPF (por delante de DMARC, 30,4 %, y DKIM, 22,7 %), pero que el 4,8 % de esos registros SPF, 148.655 dominios, supera el techo de diez consultas DNS que fija la RFC 7208 y, por tanto, falla por completo en la evaluación.

Las tres partes de todo registro SPF

Todo registro válido se descompone igual:

v=spf1  ip4:203.0.113.10  include:_spf.google.com  -all
  |            |                    |               |
versión    mecanismo            mecanismo      resto del mundo

1. La etiqueta de versión. v=spf1 debe ser el primer término y coincidir exactamente. Cualquier otra cosa significa que el registro no es un registro SPF en absoluto.
2. Los mecanismos. Se evalúan estrictamente de izquierda a derecha. El primer mecanismo que coincide con la IP que conecta decide el resultado y la evaluación se detiene de inmediato: el orden no es cosmético.
3. El mecanismo final. Un all como último término. Todo lo que se publique después de all se ignora.

Conviene ser preciso en un punto: SPF comprueba el remitente del sobre usado en el comando SMTP MAIL FROM (el Return-Path) y la identidad HELO. No comprueba la cabecera From: que ve tu destinatario. Cerrar esa brecha es tarea de DMARC, y por eso ambos se despliegan siempre juntos. Si todavía estás trazando el conjunto, nuestra guía de configuración de seguridad DNS explica cómo encajan SPF, DKIM, DMARC y DNSSEC.

SPF tuvo en su día un tipo de registro DNS propio (el tipo 99). La RFC 7208 §3.1 lo retiró en abril de 2014: publica SPF únicamente como registro TXT.

Mecanismos SPF: la referencia completa

Un matiz que confunde a mucha gente: include: no es un pegado de texto. Ejecuta una evaluación SPF completa e independiente contra el dominio incluido y solo coincide si esa evaluación devuelve pass. Un -all dentro de un registro incluido no rechaza tu correo: simplemente hace que el include: no coincida, y la evaluación continúa con tu siguiente mecanismo.

Calificadores: cuatro caracteres que deciden el veredicto

Cualquier mecanismo puede llevar un calificador delante. La RFC 7208 §4.6.2 define exactamente cuatro, y el valor por defecto es +.

Nunca publiques +all. Autoriza a todo internet a enviar en nombre de tu dominio y es estrictamente peor que no tener registro SPF.

Modificadores: redirect y exp

Los modificadores son pares nombre/valor, no mecanismos, y solo pueden aparecer una vez cada uno.

• redirect=example.com sustituye por completo el resultado de tu registro por el del dominio de destino. Cuesta una consulta DNS y se ignora del todo si hay un mecanismo all, así que ambos no deberían convivir.
• exp=explain.example.com apunta a un registro TXT con un texto explicativo legible que se devuelve en caso de fail. No cuesta ninguna consulta en el momento de la evaluación.

Los límites que rompen registros por lo demás válidos

Aquí vive la mayoría de los fallos SPF reales. Todo lo siguiente sale directamente de la RFC 7208 §3.4 y §4.6.4:

• Diez términos que consultan DNS. Los mecanismos include, a, mx, ptr y exists y el modificador redirect consumen uno cada uno. Superar diez DEBE devolver permerror: un fallo duro, no un aviso. all, ip4, ip6 y exp son gratuitos.
• Dos consultas vacías. Una consulta que devuelve NXDOMAIN o una respuesta vacía es una "void lookup". Las implementaciones deben limitarlas a dos; superarlo también produce permerror. Los include: olvidados de servicios que ya no usas son el culpable habitual.
• Diez registros de dirección por mx o ptr. Además del presupuesto global, cada host MX individual está limitado a diez registros A/AAAA.
• Un solo registro por dominio. Si una consulta devuelve más de un registro v=spf1, el resultado es permerror. Fúsionalos en uno solo; nunca publiques dos.
• 255 caracteres por cadena, 450 octetos recomendados en total. Un registro TXT puede contener varias cadenas entrecomilladas que se concatenan sin espacios. La RFC 7208 §3.4 recomienda mantener toda la respuesta DNS por debajo de 450 octetos para que quepa en un paquete UDP.
• Un presupuesto de veinte segundos. Los receptores deben permitir al menos 20 segundos y devolver temperror a partir de ahí.

A dónde se van realmente tus diez consultas

Cada remitente externo que añades cuesta al menos una consulta, y algunos cuestan más porque sus propios registros anidan más includes.

Con seis o siete servicios ya estás en el techo. Las soluciones, por orden de preferencia: elimina los includes de servicios que ya no usas, mueve remitentes a subdominios dedicados con sus propios registros SPF y solo entonces plantéate aplanar los includes en rangos ip4: literales; aplanar elimina consultas, pero te obliga a seguir tú mismo los cambios de IP de tus proveedores.

Porcentaje de dominios que publican un registro SPF, por dominio de primer nivel. Fuente: DMARCguard, "State of Email Authentication 2026", análisis de 5.499.028 dominios Tranco, 27 de febrero de 2026.

Cinco errores de sintaxis que provocan PermError

1. Dos registros v=spf1 en el mismo nombre. Habitual tras una migración. Fúsionalos, no los apiles.
2. Un calificador en all que contradice la intención: ?all parece prudente pero no dice nada a los receptores, así que el correo suplantado pasa sin fricción.
3. Términos después de all. Todo lo que esté a la derecha de all es texto muerto.
4. Un ptr olvidado. Desaconsejado desde 2014, lento, y quema una consulta sin aportar nada.
5. Includes de proveedores que ya no usas. Cuestan una consulta cada uno y pueden convertirse en consultas vacías cuando el proveedor retira su registro.

Cómo comprobar tu propio registro

Lee tu registro directamente del DNS con una sola consulta:

dig +short TXT example.com

En Windows, el equivalente es nslookup -type=TXT example.com. Busca exactamente una cadena que empiece por v=spf1 y cuenta a mano los términos que consumen consultas, sin olvidar los que se esconden dentro de cada include:.

Desde febrero de 2024, Google y Yahoo exigen que los remitentes masivos (en torno a 5.000 mensajes diarios o más) autentiquen con SPF y DKIM y publiquen un registro DMARC de al menos p=none. Un permerror de un registro SPF roto pone en riesgo ese cumplimiento, así que conviene verificarlo en lugar de darlo por hecho.

Ejecuta un escaneo gratuito de FortifyNet de 60 segundos y comprobaremos tu registro SPF junto con DKIM, DMARC, tu configuración TLS, las cabeceras de seguridad y la exposición en la dark web, sin registro previo.

Preguntas frecuentes

¿Puede un dominio tener dos registros SPF? No. Si una consulta devuelve más de un registro v=spf1, la RFC 7208 §4.5 exige que el receptor devuelva permerror, lo que hace fallar SPF por completo. Combina los mecanismos en un solo registro.

¿Debo usar -all o ~all? Empieza con ~all mientras confirmas que todos los remitentes legítimos están listados y pasa después a -all. -all es la señal más fuerte contra la suplantación, pero solo cuando tu inventario de remitentes esté realmente completo.

¿Las entradas ip4: cuentan para el límite de diez consultas? No. ip4:, ip6:, all y exp no generan consultas DNS durante la evaluación y quedan exentos. Solo cuentan include, a, mx, ptr, exists y redirect.

¿SPF por sí solo detiene la suplantación? No. SPF valida el remitente del sobre, no la cabecera From: que lee el destinatario. Un atacante puede superar SPF en un dominio que controla mientras muestra el tuyo. DMARC ata ambas identidades, y eso es lo que cierra la brecha de verdad.

¿Cuánto puede medir un registro SPF? Cada cadena individual de un registro TXT está limitada a 255 caracteres, aunque varias cadenas se concatenan. La RFC 7208 recomienda mantener toda la respuesta DNS por debajo de 450 octetos para que sobreviva en un paquete UDP.

Guías relacionadas

• Verificador de registros SPF: cómo probar, leer y corregir tu SPF
• Cómo configurar DMARC paso a paso
• ¿Qué es DKIM? DomainKeys Identified Mail explicado

---

Fuentes: RFC 7208, Sender Policy Framework (SPF) versión 1, IETF, abril de 2014 (§3.1, §3.4, §4.5, §4.6.2, §4.6.4, §5.5, §6.1, §6.2) · DMARCguard, "State of Email Authentication 2026", análisis de 5.499.028 dominios Tranco, 27 de febrero de 2026 · Requisitos de Google y Yahoo para remitentes masivos, vigentes desde febrero de 2024.