SPF (Sender Policy Framework) publica la lista de IPs autorizadas para enviar email por tu dominio. El problema es que la spec impone un límite de 10 DNS lookups por evaluación, y ese límite se agota rápidamente cuando usás más de 3-4 servicios cloud.

Ejemplo de SPF que rompe el límite

Este SPF, típico de una empresa mediana, agota los 10 lookups:

v=spf1 include:_spf.google.com include:spf.hubspot.com include:sendgrid.net include:mailgun.org include:mandrillapp.com include:_spf.salesforce.com include:_spf.zendesk.com ~all

Cada include: cuenta al menos 1 lookup y puede recursivamente resolver a más. Google solo (_spf.google.com) resuelve a 3-4 lookups internos. Al pasar los 10, el receiver devuelve PermError y ninguna IP pasa SPF — aunque estén en la lista.

Cómo detectarlo

En el dashboard, la sección SPF Health te muestra el conteo actual y las cadenas. Si ves un badge rojo con 10+ lookups, tenés un problema activo.

También en línea de comandos:

dig +short TXT tuempresa.com | grep 'v=spf1'
# Contá tantos "include:" como veas + los "a:" y "mx:" recursivos

Solución 1 — Consolidar servicios

Antes de tocar la spec: ¿realmente usás los 7 servicios? Muchos SPF acarrean legado de vendors que ya no se usan. Auditá con Discovery de la plataforma cuáles están efectivamente enviando en los últimos 90 días y remové los muertos.

Solución 2 — Flattening

Cuando no podés consolidar más, el flattening es la respuesta. Consiste en reemplazar los include: por las IPs concretas que resuelven, así:

v=spf1 ip4:209.85.128.0/17 ip4:216.58.192.0/19 ip4:104.192.0.0/18 ... ~all

El resultado es un SPF con 0 lookups (solo IPs literales). El costo: si un vendor cambia sus IPs, tu SPF queda desactualizado.

La plataforma resuelve esto con un flattener automático que regenera el SPF cada vez que uno de los includes cambia. En tu DNS publicás un CNAME al flattener y nosotros lo mantenemos:

tuempresa.com. IN TXT "v=spf1 redirect=_spf.emate.cloud/tk_abc123"

El TXT dinámico detrás del token se actualiza sin que vos toques nada.

Verificación

Después de cualquier cambio, esperá el TTL y ejecutá:

# Debería devolver "Pass" desde una IP autorizada.
dig +short TXT tuempresa.com
# En la plataforma: /email-security/domain/tuempresa.com/spf-health

Escenarios especiales

Sub-dominios con vendors distintos

Si mail.tuempresa.com usa SendGrid pero el root usa Google Workspace, publicá un SPF distinto en cada uno. No hereda — hay que ponerlo explícito en el subdominio.

~all vs -all

• ~all = softfail. El receiver recibe la señal pero típicamente entrega el correo igual (marca spam).
• -all = hardfail. El receiver rechaza si SPF falla.

Con DMARC en enforcement (p=quarantine o p=reject), la diferencia se vuelve menor — DMARC toma la decisión final. Usar -all es más seguro por defecto.