Su registro SPF podría estar saboteando la entregabilidad de sus correos electrónicos, y es posible que ni siquiera lo sepa. Mientras la mayoría de las organizaciones se centran en las políticas DMARC, una mala configuración oculta de SPF puede hacer que correos legítimos fallen en la autenticación y acaben en la carpeta de spam.

¿El culpable? El límite de 10 consultas de SPF: un tope estricto que rompe silenciosamente la autenticación cuando se supera, especialmente si utiliza múltiples proveedores de envío de correo (ESPs), herramientas de marketing y remitentes en la nube.

Cómo funciona el límite de 10 consultas de SPF

SPF (Sender Policy Framework) indica a los receptores qué hosts pueden enviar correo en nombre de su dominio. Según el RFC 7208, la evaluación de SPF puede realizar como máximo 10 consultas DNS. Si se supera ese número, los receptores deben tratar SPF como permerror.

Cuando esto ocurre, se producen:

  • Fallos inmediatos de autenticación DMARC
  • Correos legítimos marcados como spam
  • Caídas en la entregabilidad y daño a la reputación

¿Qué cuenta como una consulta?

Los mecanismos y modificadores que desencadenan consultas DNS son:

  • include:
  • a (sin un host literal)
  • mx
  • exists
  • redirect=

Cada include: puede encadenar más include:s en cascada, por lo que el presupuesto de consultas puede agotarse rápidamente.

Errores comunes en SPF

El SPF de "incluirlo todo"

v=spf1 include:_spf.google.com include:mailchimp.com include:spf.protection.outlook.com include:amazonses.com ~all

Parece ordenado, pero con frecuencia supera las 10 consultas debido al anidamiento.

Acumulación de proveedores heredados

Los proveedores antiguos que permanecen en el registro siguen consumiendo consultas sin necesidad.

Cadenas de inclusiones anidadas

Algunos ESPs hacen referencia a múltiples registros SPF internos, cada uno de los cuales añade más consultas.

Estrategias avanzadas de optimización de SPF

1) Aplanamiento de direcciones IP

Reemplace los include:s más costosos con sus rangos de IP actuales (cuando sean estables y estén documentados contractualmente).

Antes

v=spf1 include:_spf.google.com include:mailchimp.com ~all

Después

v=spf1 ip4:209.85.128.0/17 ip4:64.233.160.0/19 ip4:198.2.128.0/18 ~all

Esto puede reducir varias consultas a cero, pero requiere mantenimiento cuando los proveedores cambian sus IPs.

2) Delegación de SPF mediante subdominios

# Raíz
example.com: v=spf1 include:_spf.google.com redirect=spf.marketing.example.com

# Subdominio de marketing
spf.marketing.example.com: v=spf1 include:mailchimp.com include:servers.mcsv.net ~all

# Subdominio de soporte
spf.support.example.com: v=spf1 include:mail.zendesk.com ~all

3) Auditoría periódica de SPF

  • Elimine inclusiones y proveedores no utilizados
  • Mida el número de consultas (objetivo: ≤ 8 para mantener margen)
  • Valide trimestralmente los cambios en los registros SPF de sus proveedores

Plan de implementación (adaptado a pymes)

  1. Semana 1: Inventarie los proveedores; elimine las inclusiones obsoletas
  2. Semana 2: Aplane los proveedores con más consultas (documente las IPs)
  3. Semana 3: Delegue las configuraciones más pesadas a subdominios
  4. Semana 4: Supervise las tasas de superación de DMARC y la entrega en bandeja de entrada

SPF + DMARC: Por qué es importante

DMARC necesita SPF o DKIM en alineación. Si SPF produce frecuentemente permerror, está dependiendo en exceso de DKIM, lo que supone un único punto de fallo. Un SPF saludable aumenta las tasas de superación de DMARC y su estabilidad.

Señales de que su SPF ya ha superado el límite

Muchas organizaciones no se dan cuenta de que su SPF está roto hasta que detectan fallos inexplicables de DMARC en los informes agregados. Las señales de advertencia más habituales son:

  • Informes DMARC que muestran spf=permerror para una parte significativa de los mensajes
  • Correos de marketing legítimos que acaban en spam a pesar de enviarse desde un ESP autorizado
  • Comprobaciones de SPF que pasan en algunos receptores pero fallan en otros (los distintos resolutores pueden tener cachés diferentes)
  • La incorporación reciente de una nueva herramienta de marketing o CRM que le ha llevado a superar el límite

El enfoque más seguro es contar las consultas de forma proactiva, no reactiva. Mantenga un inventario documentado de cada servicio que envía correo electrónico en su nombre y asigne a cada uno su mecanismo SPF correspondiente. Revíselo trimestralmente, o cada vez que incorpore una nueva herramienta de correo electrónico.

Corrija su SPF en minutos
Cuente las consultas, aplane de forma segura y valide la alineación.

Preguntas frecuentes

¿Cómo compruebo mi número de consultas? Utilice el verificador SPF de DMARCFlow (o rastree con dig) y cuente cada mecanismo que resuelva DNS.

¿Puedo publicar varios registros SPF? No. Debe existir exactamente un registro TXT SPF en la raíz. Combínelos o aplánelos en su lugar.

¿Qué ocurre si supero 10? Los receptores pueden devolver permerror → DMARC suele fallar → pérdida de entrega en bandeja de entrada.

¿El aplanamiento es siempre la mejor opción? Es eficaz, pero requiere mantenimiento. Considere la delegación a subdominios para proveedores muy dinámicos.

¿Quiere saber qué tan protegido está realmente su dominio? Pruebe el análisis gratuito de dominios de DMARCFlow y obtenga un informe instantáneo.