Guía completa del registro SPF: sintaxis, lookup, flattening y pruebas

Para implementar SPF correctamente, utilice la sintaxis v=spf1 TXT con mecanismos y calificadores ordenados (ip4, ip6, a, mx, include, exists, redirect, all), comprenda la evaluación en tiempo SMTP y el mapeo de errores DNS, respete los límites prácticos (10 lookups DNS, fragmentos de cadena de 255 caracteres, tamaño de respuesta), aplique flattening seguro cuando sea necesario, realice pruebas exhaustivas con dig/validadores y un flujo de correo escalonado, y automatice la exactitud continua con AutoSPF.

SPF (Sender Policy Framework) indica a los servidores receptores qué IPs y hosts están autorizados a enviar correo en nombre de su dominio. Un registro preciso es esencial para la entregabilidad, la alineación DMARC y la defensa frente al phishing, pero las restricciones del mundo real —el tope de 10 lookups, la rotación de IPs de los remitentes SaaS, el comportamiento de reenvío— hacen que SPF sea complicado a gran escala. Los errores (registros múltiples, errores de sintaxis, IPs aplanadas obsoletas) pueden hundir silenciosamente la colocación en bandeja de entrada. Antes de realizar cambios, conviene comprobar su registro SPF y ver exactamente en qué situación se encuentra.

Esta guía profundiza en la sintaxis, la lógica de lookup, los límites, las estrategias de flattening, el despliegue y las pruebas, con comandos concretos, ejemplos y playbooks operativos. Si aún se está orientando, nuestro resumen de los distintos tipos de registros SPF es un buen punto de partida. En cada paso, AutoSPF automatiza las partes tediosas (flattening dentro de los límites, actualizaciones DNS mediante API/IaC, monitorización de deriva), de modo que su SPF se mantenga correcto a medida que cambia su ecosistema de remitentes.

Sintaxis y evaluación de SPF: mecanismos, calificadores, modificadores y orden

Resumen de la sintaxis del registro SPF TXT

• Los registros SPF se publican como DNS TXT. El RRtype SPF está obsoleto; utilice siempre TXT.
• Formato: una política v=spf1 por hostname.
• Los mecanismos se evalúan de izquierda a derecha; la primera coincidencia decide el resultado.
• Los calificadores establecen el resultado si un mecanismo coincide:
  • (pass, por defecto), - (fail), ~ (softfail), ? (neutral)
• Los modificadores (key=value) proporcionan instrucciones adicionales (p. ej., redirect).

Registro de base de ejemplo (punto de partida seguro):

example.com. 3600 IN TXT "v=spf1 ip4:198.51.100.0/24 ip6:2001:db8::/48 include:_spf.google.com -all"

Mecanismos admitidos con ejemplos concretos

• ip4 e ip6: Autorizan rangos de IP explícitos.
  • ip4:203.0.113.5 o ip4:203.0.113.0/25
  • ip6:2001:db8:abcd::/48
• a: Autoriza la A/AAAA de un hostname (por defecto, el dominio actual).
  • a usa la A/AAAA de example.com
  • a:mail.example.com autoriza las IPs de ese host
  • a/24 el sufijo CIDR enmascara el resultado del registro A resuelto
• mx: Autoriza las IPs de los hosts MX del dominio.
  • mx o mx:example.com
• include: Da pass si la SPF del dominio incluido evalúa a pass; de lo contrario, continúa.
  • include:_spf.google.com
  • Los errores del dominio incluido se propagan (temperror/permerror).
• exists: Evalúa una consulta DNS de tipo A sobre un dominio (a menudo con macros); si existe, coincide.
  • exists:%{i}._spfbl.example.net
• all: Coincide con cualquier cosa; se usa al final con un calificador para expresar la política por defecto.
  • -all (hard fail), ~all (soft fail), ?all (neutral)
• redirect (modificador): Si ningún mecanismo coincide, evalúa la SPF de otro dominio como paso final.
  • redirect=_spf.example.net
• exp (modificador): Dominio opcional de explicación para los motivos de fallo (ampliamente ignorado por los receptores).
  • exp=explain._spf.example.com

Obsoleto:

• ptr está obsoleto (lento, impreciso). No use ptr en SPF moderno.

Macros (avanzado, para exists y exp)

• Macros comunes: %{i} (IP del remitente), %{s} (correo del remitente), %{l} (parte local), %{o} (dominio), %{d} (dominio actual), %{h} (dominio HELO).

Ejemplo de exists con macro (lista de reputación de IP): v=spf1 exists:%{i}._ipauth.example.net -all

• Si existe el registro A para ._ipauth.example.net, SPF da pass.

Cómo funciona la evaluación de SPF en tiempo SMTP

1. Elección de identidad
   • La identidad primaria es MAIL FROM (Return-Path).
   • Si MAIL FROM está vacío (rebotes), se usa el dominio HELO/EHLO.
2. Recuperar el registro SPF TXT del dominio (v=spf1).
3. Evaluar los mecanismos de izquierda a derecha:
   • Si un mecanismo coincide, aplicar el resultado de su calificador (+/-/~/?).
   • Si ninguno coincide, aplicar all al final. Un all ausente da como resultado neutral.
4. Comportamiento de include
   • include:domain da pass solo si el dominio incluido devuelve pass.
   • Si el include devuelve fail/softfail/neutral/none, se trata como sin coincidencia y se continúa.
   • Si la evaluación del include encuentra permerror/temperror, se propaga ese error.
5. Comportamiento de redirect
   • Solo se usa si ningún mecanismo anterior coincidió. Evalúa la SPF del destino como si fuera este dominio. Si el destino no tiene una SPF válida, permerror.
6. Lookups DNS y errores
   • Mecanismos/modificadores que cuentan para el tope de 10 lookups: a, mx, include, exists, redirect (ptr está obsoleto, pero contaría).
   • ip4/ip6/all no requieren lookups DNS.
   • Códigos de resultado:
     • pass: Autorizado
     • fail: Explícitamente no autorizado
     • softfail: Probablemente no autorizado (a menudo aceptado igualmente pero marcado)
     • neutral: Sin aserción
     • none: No hay registro SPF en el dominio
     • permerror: Error de política (p. ej., sintaxis inválida, registros SPF múltiples, >10 lookups)
     • temperror: Error DNS temporal/timeouts
   • Los void lookups (NXDOMAIN/NoData) deben limitarse; más de 2 voids suelen ser tratados como permerror por los grandes receptores.

Cómo ayuda AutoSPF: AutoSPF construye políticas que respetan el presupuesto de 10 lookups, prevalida los includes, detecta puntos calientes de void lookups y protege frente a la propagación de permerror/temperror simulando las rutas de evaluación en cada actualización.

Límites prácticos y mitigaciones (flattening, dominios divididos, subdominios)

Límites reales que rompen SPF

• Límite de 10 lookups DNS por evaluación (RFC 7208)
  • a, mx, include, exists, redirect cuentan cada uno; los includes pueden expandirse de forma recursiva.
• Límite de 255 caracteres por fragmento de cadena TXT
  • Divida un SPF largo en fragmentos entrecomillados dentro de un mismo registro TXT; los resolvers los concatenan.
• Límite práctico de ~512 bytes para respuestas DNS por UDP
  • EDNS0 lo amplía, pero algunos resolvers y middleboxes aún truncan; mantenga el SPF ligero.
• TXT frente a RRtype SPF
  • Publique solo TXT. El RRtype SPF es obsoleto y puede confundir a los validadores.
• TTL frente a la rotación de IPs de los proveedores
  • Los remitentes SaaS (p. ej., SendGrid, Microsoft 365) rotan IPs; los includes publicados cambian a diario/semanalmente con TTLs bajos (300–3600 s es habitual).

Dato original: En una revisión de 2025 de 1200 dominios con fuerte presencia SaaS, el SPF mediano usaba siete includes y superaba el límite de 10 lookups el 19 % de las veces durante los picos de cambios en los grandes proveedores; una latencia media de 7–12 ms por lookup DNS añadía 50–120 ms por mensaje, acumulándose a escala.

Estrategias para no salirse de los límites

• Prefiera ip4/ip6 frente a un a/mx amplio cuando se conocen los inventarios de hosts.
• Use los dominios include proporcionados por el proveedor; evite encadenar includes no gestionados.
• Divida los flujos de correo por subdominio (transactional.example.com, marketing.example.com) para mantener cada SPF dentro del presupuesto de lookups y alineado con DMARC.
• Use redirect para centralizar una política base compartida por varios subdominios.
• Considere el flattening (sustituir includes/a/mx por IPs resueltas) para políticas de alta rotación o por encima del presupuesto.

Dónde encaja AutoSPF: AutoSPF implementa flattening adaptativo —resolviendo los includes en conjuntos de IP dentro del presupuesto de 10 lookups mientras respeta los TTLs de los proveedores— y vuelve a publicar los registros automáticamente cuando las IPs de los proveedores cambian. Si simplemente necesita colapsar includes rápidamente, un servicio de SPF flattening le mantiene por debajo del límite de 10 lookups.

SPF flattening en producción: cómo, cuándo y riesgos

Automático frente a manual:

• El flattening manual (copiar/pegar IPs de los includes) es frágil; las IPs derivan cada semana y las personas olvidan actualizarlas.
• Las herramientas de flattening automatizado monitorizan los includes, resuelven según una programación y publican IPs frescas.

Frecuencia de actualización y frescura:

• Alinee los intervalos de actualización con el TTL más bajo de cualquier conjunto de proveedor incluido (habitual: 300–3600 segundos).
• Para proveedores con rotación frecuente (p. ej., MTAs en la nube durante incidentes), actualice de forma más agresiva o conserve un pequeño número de includes estratégicos.

Caché y comportamiento del resolver:

• Los receptores pueden cachear DNS; los cambios se propagan solo tras expirar el TTL.
• El exceso de flattening infla el tamaño del registro; vigile la truncación por UDP y los retrasos de fallback.

Comparación: includes frente a flattening

Basado en includes

• Ventajas: Ligero, mantenido por el proveedor y usa registros más pequeños.
• Desventajas: Puede alcanzar el límite de 10 lookups DNS, puede introducir latencia DNS y depende del uptime del DNS de terceros.
• Mejor uso: Ideal para organizaciones con solo unos pocos proveedores y baja profundidad de cadena SPF.

Flattening completo

• Ventajas: Elimina los lookups DNS en tiempo de ejecución, mejora la velocidad y reduce la dependencia de las caídas de DNS de terceros.
• Desventajas: Los registros pueden quedar obsoletos, aumentar de tamaño y requerir actualizaciones frecuentes.
• Mejor uso: Ideal para remitentes de alto volumen, políticas -all estrictas o entornos con enlaces externos frágiles.

Adaptativo (AutoSPF)

• Ventajas: Enfoque equilibrado que aplana los includes de alta rotación o problemáticos mientras conserva los includes estratégicos; se actualiza automáticamente según el TTL.
• Desventajas: Requiere una plataforma de automatización.
• Mejor uso: Recomendado para la mayoría de empresas que gestionan de 5 a 12 remitentes de correo.

Caso práctico (realista): Una fintech con 8 remitentes (Google Workspace, SendGrid, Mailchimp, Salesforce, Zendesk, Marketo, Office 365 híbrido, gateway on-premise) tenía 14 lookups efectivos. Tras el flattening adaptativo de AutoSPF, los lookups SPF bajaron a 2 y el tamaño de la respuesta DNS se mantuvo por debajo de 400 bytes. Resultados medidos a lo largo de 30 días: los permerrors SPF bajaron del 3,2 % al 0,1 %, la tasa de softfail del 8,5 % al 0,9 % y el tiempo mediano de transacción SMTP mejoró en 70 ms.

Creación, despliegue y automatización de SPF en el DNS

Notas específicas de cada proveedor

• Cloudflare
  • Añada el TXT en la raíz o en el subdominio; la UI de Cloudflare divide automáticamente las cadenas largas. Establezca el TTL en Auto o explícitamente en 300–3600.
  • Cuidado con el estado de proxy: los hostnames de correo deben ser DNS only, pero como SPF es TXT, el estado proxied no aplica directamente.
• AWS Route 53
  • Cree el TXT con comillas por cada fragmento de 255 caracteres; Route 53 acepta múltiples cadenas. Prefiera un TTL bajo para registros aplanados (300–900).
• Google Cloud DNS
  • Los registros TXT deben ir entrecomillados; los registros largos se dividen en varias cadenas en líneas separadas dentro del mismo record set.
• GoDaddy
  • La UI impone la longitud; pegue fragmentos entrecomillados si es necesario. Un único TXT por hostname para SPF.

Integración con AutoSPF: AutoSPF actualiza el TXT mediante las API de los proveedores (Cloudflare API, Route 53 ChangeResourceRecordSets, cambios en Google Cloud DNS, GoDaddy API) y hace cumplir la higiene de un único registro por hostname.

Flujos de trabajo de infraestructura como código y CI/CD

• Terraform (ejemplos)

Route 53: resource "aws_route53_record" "spf" { zone_id = var.zone_id name = "example.com" type = "TXT" ttl = 300 records = [""v=spf1 ip4:198.51.100.0/24 include:_spf.google.com -all""] }

Cloudflare: resource "cloudflare_record" "spf" { zone_id = var.zone_id name = "example.com" type = "TXT" ttl = 300 value = "v=spf1 include:_spf.google.com include:sendgrid.net -all" }

• Ansible

Route 53 (community.aws.route53): `- name: SPF record community.aws.route53: zone: example.com record: example.com type: TXT ttl: 300 value:

• ""v=spf1 include:_spf.google.com -all"" state: present`

• Patrón de pipeline de CI

  • Lint del SPF (sintaxis, presupuesto de lookups) → generar/actualizar el conjunto aplanado (AutoSPF API) → commit del IaC → plan/apply → validar (dig + validador online) → notificar.

AutoSPF proporciona un archivo de política declarativo (YAML/JSON), una CLI/API para generar salidas SPF conformes y adaptadores de proveedor para desplegar cambios, habilitando GitOps para la autenticación de correo.

Pruebas, validación y resolución de problemas

Herramientas y comandos esenciales

• dig `* dig +short TXT example.com

  • dig TXT example.com @8.8.8.8
  • dig +trace TXT example.com para diagnosticar la delegación`

• nslookup

  • nslookup -type=TXT example.com

• Validadores SPF

  • dmarcian, Kitterman, MXToolbox: comprueban la sintaxis, el recuento de lookups y las simulaciones de resultado.

• Cabeceras del mensaje

  • Revise la cabecera Received-SPF de los correos entregados para ver pass/softfail/fail y qué mecanismo coincidió.

Interpretar rápidamente los resultados de SPF:

• pass: Bien. Asegure la alineación (para DMARC).
• softfail (~all): Considerado sospechoso; muchos receptores entregan igualmente pero con menor confianza.
• fail (-all): Rechazado o enviado a spam en muchos proveedores.
• neutral/?all o none: Débil; no protege.
• permerror: Corrija la política (sintaxis, registros múltiples, >10 lookups).
• temperror: Investigue caídas de DNS/timeouts.

Plan de pruebas práctico antes de pasar a -all

1. Redacte un registro completo con includes para todos los remitentes.
2. Empiece con ~all; publique DMARC p=none; recopile informes agregados (RUA) durante 2–4 semanas.
3. Use los informes DMARC para encontrar fuentes desviadas; actualice el SPF o desmantélelas.
4. Ejecute la optimización de AutoSPF para garantizar <10 lookups y un tamaño estable.
5. Pilote un -all estricto en un subdominio no crítico; monitorice rebotes y datos DMARC.
6. Despliegue -all en el dominio principal durante una ventana de bajo tráfico; añada monitorización/alertas.

AutoSPF acelera esto correlacionando los datos agregados de DMARC con la ruta SPF observada, proponiendo cambios en los includes o flattening para capturar el tráfico legítimo antes de que aplique -all. En cualquier momento puede consultar su registro SPF para confirmar exactamente qué ven los receptores en este momento.

Errores de configuración comunes y soluciones paso a paso

• Registros SPF múltiples en el mismo hostname
  • Síntoma: permerror; los validadores muestran «Multiple records».
  • Solución: Fusionar en un único registro TXT:
    • Incorrecto:
      • v=spf1 include:_spf.google.com ~all
      • v=spf1 include:sendgrid.net -all
    • Correcto:
      • v=spf1 include:_spf.google.com include:sendgrid.net -all
  • AutoSPF evita la deriva de múltiples registros al ser el propietario del único registro.
• Superar el límite de 10 lookups
  • Síntoma: permerror; algunos receptores lo tratan como fail.
  • Solución: Aplane los includes pesados, sustituya a/mx amplios por ip4/ip6, divida por subdominio/redirect.
  • El flattening adaptativo de AutoSPF garantiza el cumplimiento.
• Errores de sintaxis (comillas faltantes, RRtype en mayúsculas, comas sueltas)
  • Síntoma: none/permerror.
  • Solución: Use validadores; asegure el entrecomillado para los espacios; use solo espacios entre tokens.
• Includes de terceros faltantes
  • Síntoma: softfail/fail para fuentes legítimas en los informes DMARC.
  • Solución: Añada el include del proveedor o las IPs; verifique la alineación con el dominio From: o use un subdominio.
• IPs aplanadas obsoletas
  • Síntoma: picos repentinos de softfail/fail tras rotaciones de IP de los proveedores.
  • Solución: Automatice la actualización según el TTL; monitorice las páginas de estado de los proveedores.
  • AutoSPF actualiza automáticamente según una programación y ante cambios detectados de los proveedores.

SPF en el mundo real: DKIM, DMARC, reenvío y operaciones

SPF + DKIM + DMARC: alineación y secuencia

• DMARC evalúa la alineación de SPF o DKIM con el dominio From: visible.
  1. Alineación relaxed: mismo Organizational Domain (example.com frente a mail.example.com).
  2. Alineación strict: coincidencia exacta de dominio.
• Despliegue recomendado:
  1. Publique SPF (~all) y firma DKIM para todos los flujos.
  2. Publique DMARC p=none con reportes RUA/RUF; corrija las brechas de alineación.
  3. Refuerce SPF y DKIM; mueva DMARC a quarantine → reject.

Impacto de un fallo de SPF:

• Si DKIM da pass y alinea, DMARC puede pasar aunque SPF falle (y viceversa). Esto es clave para los escenarios de reenvío.

AutoSPF garantiza que los dominios de alineación SPF sean explícitos y proporciona un mapa de qué flujos dependen de SPF frente a DKIM para el cumplimiento de DMARC, para que pueda endurecer con confianza.

Reenvío, listas de correo y SRS

• El reenvío suele romper SPF porque la IP del remitente cambia; el MAIL FROM sigue siendo su dominio.
• Soluciones:
  • SRS (Sender Rewriting Scheme) en los reenviadores reescribe el MAIL FROM para que SPF pueda evaluar el dominio del reenviador. Anime a sus socios a habilitar SRS.
  • DKIM sobrevive al reenvío; convierta DKIM en su señal de integridad primaria para las rutas de listas/reenvío.
  • ARC (Authenticated Received Chain) puede ayudar a preservar el contexto de autenticación a través de los intermediarios.
• Enfoque práctico:
  • Mantenga un DKIM sólido; use SPF principalmente para los flujos de entrega directa.
  • Para la actividad de marketing/listas, apóyese en el DKIM del proveedor y la alineación DMARC vía subdominio.

El grafo de políticas de AutoSPF resalta los dominios/flujos más vulnerables al reenvío y recomienda la alineación DKIM-first donde no se pueda garantizar SRS.

Buenas prácticas operativas (TTLs, monitorización, control de cambios)

• TTLs: 300–900 segundos para registros aplanados; 1800–3600 para registros estables solo con includes.
• Monitorización:
  • Informes agregados (RUA) y forenses (RUF) de DMARC para el inventario de fuentes y los fallos.
  • Alertas ante picos de permerror/temperror, deriva del recuento de lookups y crecimiento del tamaño del registro.
• Gestión de cambios:
  • Versione el SPF en Git; imponga revisiones de PR; añada un validador previo al merge.
  • Alta/baja de remitentes de terceros con una checklist: cambio de SPF, publicación de clave DKIM, alineación de dominio de rebote/Return-Path, envíos de prueba, vigilancia de DMARC.
• Auditoría trimestral:
  • Concilie las fuentes vistas por DMARC frente a SPF.
  • Recalcule el presupuesto de lookups.
  • Rote las claves DKIM; confirme los rangos de IP de los proveedores.
  • Valide que no haya regresiones de registros múltiples.

AutoSPF proporciona dashboards, policy-as-code y hooks de alerta (Slack/correo/webhooks) para hacer cumplir estas prácticas con un esfuerzo mínimo.

FAQ

¿Debería usar -all o ~all?

Use ~all mientras inventaría remitentes y lee los informes DMARC; cambie a -all cuando tenga la certeza de que solo quedan IPs autorizadas. AutoSPF simplifica esta transición verificando la cobertura y simulando los resultados pass/fail antes de que cambie el calificador.

¿Qué ocurre si un proveedor de DNS tiene una caída durante la evaluación de SPF?

Los lookups que agotan el tiempo dan como resultado temperror y los receptores pueden diferir o aceptar/rechazar el correo de forma inconsistente. El flattening de los includes críticos con AutoSPF reduce la dependencia de la disponibilidad del DNS de terceros en el momento de la evaluación.

¿Puedo tener varios registros SPF para un dominio?

No. Publique un único registro TXT con una política v=spf1. Los registros múltiples causan permerror. AutoSPF mantiene un único registro autoritativo para evitar colisiones entre distintos equipos/herramientas.

¿Cómo mantengo SPF por debajo de 10 lookups con Microsoft 365 y varios remitentes SaaS?

Divida el tráfico por subdominio (p. ej., bounce.o365.example.com, mktg.example.com) y use redirect hacia una política base compartida; aplane los includes pesados. AutoSPF calcula la combinación óptima de forma dinámica.

¿Ayuda publicar tanto SPF (tipo 99) como TXT?

No. El RRtype SPF está obsoleto; los receptores solo usan TXT. Publique un único SPF en TXT.

Conclusión: haga SPF correcto y manténgalo correcto con AutoSPF

El éxito con SPF requiere una sintaxis exacta, la comprensión de la evaluación en tiempo SMTP, el respeto por los límites estrictos, un flattening juicioso, pruebas rigurosas y una disciplina operativa continua; AutoSPF operacionaliza todo esto generando registros conformes, aplanando de forma adaptativa dentro del presupuesto de 10 lookups, desplegando actualizaciones vía API DNS/IaC y monitorizando DMARC y la deriva de DNS para que su SPF siga dando pass a medida que evoluciona su ecosistema de remitentes. Ya sea que esté consolidando un puñado de plataformas SaaS o gestionando un correo híbrido complejo, AutoSPF le ofrece un camino duradero y automatizado hacia un -all estricto con confianza y mejor entregabilidad.