SPF deep dive: por qué el registro 'v=spf1 include' colapsa y cómo aplanarlo correctamente

Por qué este problema es invisible hasta que ya es grave

El registro SPF es uno de los pocos componentes de email donde podés tener una sintaxis válida, pasar todos los tests de “syntax check”, y aun así estar fallando en producción para el 100% de los receptores. La razón: el límite de 10 lookups DNS no es de sintaxis, es de procesamiento, y solo se hace evidente cuando un receptor real intenta validar tu registro.

En las auditorías de deliverability de CMP, encontramos SPF roto por exceso de lookups en aproximadamente el 35% de operaciones con más de 3 años de antigüedad. La mayoría no lo saben porque los emails siguen llegando (DKIM compensa parcialmente), pero la reputación del dominio se construye sobre dos firmas y solo tiene una funcionando.

Este post explica cómo funciona el límite, cómo diagnosticarlo correctamente, cómo aplanar el SPF de forma sostenible y qué errores operativos hay que evitar al hacerlo.

El RFC 7208 sección 4.6.4: el origen del límite

El RFC 7208 (especificación oficial de SPF) define el límite explícitamente:

SPF implementations MUST limit the total number of mechanisms and modifiers that do DNS lookups to at most 10 per SPF check, including any lookups caused by the use of the include mechanism or the redirect modifier.

La razón histórica del límite: prevenir ataques DoS. Sin el límite, un atacante podría crear un SPF malicioso con includes anidados infinitamente, forzando al validador a hacer miles de lookups DNS por cada email. El límite de 10 es arbitrariamente conservador pero suficiente para el 80% de casos legítimos.

Los mecanismos que cuentan como lookup:

• include:dominio.com — 1 lookup base + lookups internos del registro incluido
• a (sin parámetro) — 1 lookup
• a:dominio.com — 1 lookup
• mx — 1 lookup + 1 lookup por cada registro MX retornado
• ptr (deprecado pero todavía usado) — múltiples lookups
• exists:dominio.com — 1 lookup
• redirect=dominio.com — 1 lookup + lookups internos

Los mecanismos que NO cuentan:

• ip4:1.2.3.4 — 0 lookups (es una IP literal)
• ip4:1.2.3.0/24 — 0 lookups
• ip6:2001:db8::/32 — 0 lookups
• all, +all, -all, ~all — 0 lookups

La aritmética real: por qué pasás 10 sin darte cuenta

Suponé este SPF típico de una operación panameña mediana:

v=spf1 include:_spf.google.com include:servers.mcsv.net include:spf.mtasv.net include:_spf.salesforce.com include:_spf.intuit.com -all

Cinco includes parece poco. Pero cada include tiene su propio SPF interno:

_spf.google.com retorna:

v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all

3 includes adicionales = 4 lookups totales (1 inicial + 3 sub).

servers.mcsv.net (Mailchimp) retorna:

v=spf1 include:_spf.mandrillapp.com ip4:205.201.128.0/20 ~all

1 include adicional = 2 lookups (1 inicial + 1 sub).

spf.mtasv.net (Postmark) retorna típicamente solo IPs = 1 lookup.

_spf.salesforce.com retorna múltiples includes = 4-5 lookups.

_spf.intuit.com (QuickBooks) retorna includes adicionales = 3-4 lookups.

Total real: 14-17 lookups. Pasamos 10 hace tres includes.

El SPF tiene sintaxis válida. Pasaría cualquier validador de sintaxis. Pero en producción, Gmail abandona la validación al lookup 11 y devuelve PermError.

Cómo diagnosticar correctamente

Tres pasos obligatorios:

Paso 1: validar conteo exacto

Usar MXToolbox SPF Lookup (https://mxtoolbox.com/spf.aspx) o dmarcian SPF Surveyor. Pegar el dominio. La herramienta retorna el conteo exacto y marca en rojo cualquier exceso.

Salida típica problemática:

SPF Result: Permanent Error
Detected DNS Lookups: 13 (exceeds 10 limit)

Paso 2: identificar qué include consume más

dmarcian SPF Surveyor muestra árbol expandido:

empresa.com
├── include:_spf.google.com (4 lookups)
│   ├── include:_netblocks.google.com
│   ├── include:_netblocks2.google.com
│   └── include:_netblocks3.google.com
├── include:servers.mcsv.net (2 lookups)
├── include:_spf.salesforce.com (5 lookups)  ← culpable principal
└── include:_spf.intuit.com (4 lookups)      ← culpable secundario

Salesforce y QuickBooks son los principales consumidores. Esto es información para decidir el orden de aplanado.

Paso 3: validar en Postmaster Tools

Si tenés acceso a Google Postmaster Tools del dominio, ir a Authentication. Si SPF muestra menos de 95% de pass rate mientras DKIM muestra 99%+, es señal definitiva de problema de lookups (no de configuración incorrecta de los proveedores).

La solución técnica: aplanado dinámico

Aplanar SPF significa reemplazar include:dominio.com por las IPs reales que ese include resuelve. Ejemplo:

Antes:

v=spf1 include:_spf.salesforce.com -all

Después (aplanado):

v=spf1 ip4:13.111.0.0/16 ip4:96.43.144.0/20 ip4:182.50.78.0/22 ip4:204.14.232.0/22 -all

El aplanado quita la necesidad del lookup a _spf.salesforce.com (que internamente tenía 5 lookups más). Ahora son 0 lookups para Salesforce.

Pero acá está el problema: Salesforce puede cambiar sus IPs sin avisar. La próxima vez que agreguen un rango nuevo, tu SPF aplanado queda desactualizado y empezás a fallar autenticación silenciosamente.

Opciones de aplanado sostenible

Opción 1 — Aplanado manual con revisión periódica

Reemplazás los includes problemáticos con sus IPs. Configurás un recordatorio trimestral para revisar si las IPs cambiaron. Costo: 0. Riesgo: alto (fácil olvidar).

Opción 2 — Servicio de SPF flattening dinámico

Servicios como dmarcian Hosted SPF, EasyDMARC SPF Manager, Valimail Monitor mantienen un registro SPF actualizado en su DNS y vos solo apuntás un CNAME desde tu dominio:

TXT  empresa.com  "v=spf1 include:_spf.dmarcian.com -all"

_spf.dmarcian.com (gestionado por dmarcian) contiene el SPF aplanado con todas las IPs actualizadas automáticamente. Solo consume 1 lookup para tu dominio.

Costo: USD 15-50/mes según volumen y vendor. Sostenible operativamente.

Opción 3 — Aplanado con macros SPF

Técnica avanzada usando macros del RFC 4408. Requiere infraestructura DNS dinámica propia. Sostenible pero complejo. Solo recomendado para operaciones muy grandes con equipo DNS dedicado.

La trampa del aplanado en el orden incorrecto

Un error frecuente al aplanar: empezar por los includes más simples y dejar los complejos para el final. El resultado es contraproducente.

Estrategia correcta: aplanar primero los includes que consumen más sub-lookups.

Si Salesforce consume 5 lookups y Google consume 4, aplanar Salesforce primero (libera 4 lookups, deja Google intacto consumiendo sus 4). Aplanar Google primero (libera 3 lookups, deja Salesforce sin aplanar consumiendo 4) deja la operación todavía sobre el límite.

Mantenimiento del SPF después del aplanado

Una vez aplanado, tres reglas operativas:

Regla 1: Auditar antes de agregar cualquier proveedor

Antes de incorporar un nuevo proveedor de email (CRM, herramienta de encuestas, calendario), validar el SPF actual con MXToolbox y verificar margen disponible. Agregar un include nuevo a un SPF que está en 9 lookups lo rompe inmediatamente.

Regla 2: Revisar mensualmente con Postmaster Tools

Configurar alerta semanal: si el porcentaje de SPF pass baja del 95%, investigar. Puede ser que un proveedor cambió sus IPs y el aplanado quedó desactualizado.

Regla 3: Mantener un dominio de testing

Para validar cambios en SPF antes de aplicarlos en producción, mantener un subdominio de testing (test.empresa.com) con SPF idéntico al de producción. Probar agregados ahí antes de modificar el de producción. Esto evita romper deliverability mientras se experimenta.

SPF aplanado y DMARC: la relación que muchos olvidan

DMARC verifica que SPF y/o DKIM pasen Y estén alineados con el From. SPF aplanado correctamente sigue cumpliendo ambos requisitos:

• Pasa: el receptor verifica que la IP origen está autorizada
• Alineado: el dominio del Return-Path coincide con el dominio del From (o subdominio)

Aplanar SPF no rompe alineación DMARC. Pero hay un caso edge: si aplanás todas las IPs pero olvidás incluir las de un proveedor específico, los emails de ese proveedor fallan SPF, fallan alineación DMARC si DKIM también falla, y con política DMARC en p=reject van rechazados.

Por eso la auditoría post-aplanado debe verificar que TODOS los flujos siguen autenticando bien. No solo “el SPF tiene sintaxis válida”.

Diagnóstico de campo: cómo se ve un SPF roto en la práctica

En auditorías, el patrón visible es:

• DKIM pass rate: 98-99%
• SPF pass rate: 60-75%
• DMARC pass rate: 96-98% (porque DKIM compensa)
• Reputación general: Medium o Low

El dueño del dominio piensa: “DMARC pasa al 96%, todo bien”. Pero el 25-40% que no autentica por SPF es un drag permanente en reputación. Cuando ese 25% cae a un receptor más estricto (algunos B2B europeos), va a spam o se rechaza.

Aplanar SPF correctamente sube el SPF pass rate al 98%+. La diferencia se nota en deliverability medible, especialmente en cuentas corporativas con políticas de email estrictas.

Tres casos reales de SPF roto en Panamá

Caso 1: agencia digital con 9 herramientas integradas

Agencia que gestionaba marketing de 14 clientes desde su propio dominio. SPF original:

v=spf1 include:_spf.google.com include:servers.mcsv.net include:sendgrid.net 
include:_spf.salesforce.com include:_spf.intuit.com include:_spf.zoho.com 
include:spf.hubspot.com include:_spf.klaviyo.com include:spf.mtasv.net -all

9 includes. Cada uno sumando sub-lookups: 4+2+3+5+4+3+5+3+1 = 30 lookups efectivos. Pasaba el límite por 3x.

Síntoma observado: open rate del newsletter mensual caía consistentemente cada semana. El equipo asumía “burnout de la lista”. Postmaster Tools mostraba reputación cayendo de High a Medium-Low en 4 meses.

Diagnóstico real: SPF rompía para 100% de los envíos. DKIM compensaba parcialmente, pero la falta de pasaje SPF dañaba el peso del sender en el algoritmo de Gmail.

Solución: contratación de dmarcian Hosted SPF (USD 39/mes), aplanado dinámico, registro reducido a:

v=spf1 include:_spf.dmarcian.com -all

1 lookup total. Resultado a las 4 semanas: SPF pass rate subió de 23% a 99.2%. Reputación recuperó a High en 9 semanas.

Caso 2: e-commerce mediano sin saberlo

Tienda online con Shopify, Klaviyo, Recharge (subscriptions), Yotpo (reviews), Postmark (transaccional). Cada herramienta envía emails con dominio remitente del shop.

SPF inicial:

v=spf1 include:shops.shopify.com include:_spf.klaviyo.com include:_spf.recharge.com 
include:spf.yotpo.com include:spf.mtasv.net -all

5 includes. Conteo real: 3+3+2+2+1 = 11. Pasa el límite por 1.

Síntoma: emails post-compra de Yotpo (pedidos de review) tenían open rate 8%, cuando el benchmark del sector es 35-45%. El equipo culpaba al copy, hizo A/B testing, no mejoró.

Diagnóstico: emails de Yotpo enviados con IPs de Yotpo, pero SPF de la tienda no autenticaba esas IPs (porque el include de Yotpo era el 5º y caía después del lookup 10 en algunas validaciones). Yahoo y Microsoft enviaban a Spam o Junk.

Solución: aplanado del include de Salesforce/HubSpot innecesario (la tienda no los usaba, eran legacy de un setup viejo), reducción a 4 includes activos. 8 lookups totales. Margen para crecer.

Resultado: open rate de Yotpo subió de 8% a 42% en 6 semanas (recuperación de reputación).

Caso 3: organización sin fines de lucro con Google Workspace + Mailchimp

Caso aparentemente simple: solo dos proveedores. SPF inicial:

v=spf1 include:_spf.google.com include:servers.mcsv.net -all

Total: 4 + 2 = 6 lookups. Dentro del límite.

Pero: la organización había configurado MailerLite hace 2 años para una campaña específica, después dejó de usarlo, pero el include quedó en SPF. Y agregó Wix Forms recientemente para captación, que agregó otro include.

SPF real (actualizado sin auditoría):

v=spf1 include:_spf.google.com include:servers.mcsv.net include:_spf.mailerlite.com 
include:_spf.wix.com -all

Conteo: 4 + 2 + 3 + 4 = 13 lookups. Pasaba el límite por 3.

Diagnóstico: solo MailerLite y Wix tenían cero envíos reales en los últimos 6 meses. Ambos includes eran legacy innecesarios.

Solución: cleanup de SPF, eliminación de includes muertos. SPF final:

v=spf1 include:_spf.google.com include:servers.mcsv.net -all

Vuelve a 6 lookups. Sin servicio externo necesario.

Lección operativa: muchos casos de SPF roto se resuelven con cleanup, no con servicios pagos. Pero requiere auditoría periódica del SPF (cada 6 meses recomendado).

El parser SPF en detalle: cómo lee el receptor

Para entender mejor las reglas de aplanado, vale entender cómo procesa el receptor:

1. Receptor obtiene email del remitente [email protected]
2. Lee el envelope MAIL FROM: (puede ser distinto al From: header)
3. Consulta el SPF del dominio del MAIL FROM
4. Empieza a evaluar cada mecanismo de izquierda a derecha:
   • +ip4:1.2.3.4 → ¿la IP origen coincide? Si sí, pass. Si no, siguiente.
   • include:dominio.com → consulta SPF de dominio.com, hace recursión
   • ~all (softfail) o -all (fail) al final
5. El primer mecanismo que matchea decide el resultado
6. Si hace más de 10 lookups en el proceso, abandona y devuelve PermError

El detalle importante: el receptor evalúa en orden. Si tu SPF empieza con un ip4:1.2.3.4 que matchea tu IP de envío, el receptor llega a pass sin procesar los includes. Si tu SPF empieza con include:_spf.google.com y tu IP de envío es de Mailchimp (que está en include:servers.mcsv.net al final), el receptor hace todos los lookups de Google primero, después los de Mailchimp.

Optimización táctica: poner los includes que generan más volumen al principio del SPF. Si tu marketing genera 80% del volumen y va por Mailchimp, poner include:servers.mcsv.net antes que include:_spf.google.com. Esto reduce el promedio de lookups por email evaluado (aunque no cambia el conteo total del registro).

Monitoreo automatizado de SPF en el tiempo

Tres herramientas que vale la pena configurar:

dmarcian SPF Surveyor (gratis)

Para auditoría puntual. Pegás el dominio y obtenés el árbol completo con conteos.

URL: https://dmarcian.com/spf-survey/

Postmaster Tools (gratis)

Pestaña Authentication. Métrica SPF pass rate debería estar 95%+. Si baja, alerta.

MXToolbox SPF Monitor (pago, ~USD 15/mes)

Configurás el dominio, te avisa por email si:

• El SPF cambia
• El conteo de lookups pasa cierto umbral (ej: 8)
• El registro tiene errores de sintaxis

Útil para operaciones donde el SPF lo gestionan varias personas y los cambios pueden ocurrir sin notificación.

El error de las migraciones de proveedor

Cuando una operación migra de un proveedor a otro (ej: Mailchimp → Klaviyo), el proceso típico:

1. Setup de Klaviyo en paralelo
2. Agregar include:_spf.klaviyo.com al SPF
3. Hacer migración de listas
4. Empezar a enviar desde Klaviyo
5. Olvidarse de quitar include:servers.mcsv.net del SPF

El SPF queda con includes de los DOS proveedores indefinidamente. Si la operación hace esto con 3 migraciones en 4 años, termina con SPF de 6-9 includes legacy + 2-3 activos.

Mejor práctica: agregar al checklist de migración el paso “quitar include del proveedor anterior tras 30 días de validar el nuevo”. Si nadie le da seguimiento, los includes muertos quedan acumulándose.

Cómo afecta SPF a la velocidad de entrega

Un detalle subestimado: cuando un receptor evalúa SPF, el tiempo de procesamiento DNS afecta la latencia de entrega.

SPF con 3 lookups: ~50-100ms de procesamiento por email SPF con 8 lookups: ~150-300ms SPF con 11+ lookups (que falla): ~500-2000ms antes de abandonar

Para volúmenes altos (>500K envíos), esa diferencia se acumula. Operaciones de transaccional crítico (códigos OTP, password resets) necesitan SPF eficiente para mantener latencia <2 segundos en 99% de casos.

Aplanar SPF también es optimización de velocidad, no solo de validación.

Cuándo aplanar vs cuándo cleanup

Dos estrategias diferentes:

Cleanup (gratis): revisar el SPF actual, identificar includes innecesarios (proveedores que ya no se usan), eliminarlos. Funciona si el problema es acumulación histórica.

Aplanado (USD 15-50/mes con servicio): mantener todos los includes activos pero reemplazarlos por sus IPs reales actualizadas dinámicamente. Funciona si el problema es que hay muchos proveedores legítimos activos.

La diferencia operativa:

Antes de pagar un servicio de aplanado, hacer cleanup. Muchas veces es suficiente.

Resumen operativo

Tres acciones para esta semana:

1. Auditar el SPF actual del dominio principal con MXToolbox. Si pasa de 10 lookups, está roto silenciosamente.

2. Decidir entre aplanado manual o dinámico. Para operaciones con menos de 3 proveedores y poco crecimiento esperado, manual con revisión trimestral. Para operaciones con 4+ proveedores o crecimiento activo, servicio dinámico USD 15-50/mes.

3. Configurar alerta en Postmaster Tools para que si SPF pass rate baja del 95%, alguien lo vea en menos de 7 días.

El SPF es de los componentes más subestimados de email. No se nota cuando funciona, pero cuando falla, falla en silencio durante meses y la reputación se erosiona sin causa aparente.