Un cliente me escribió el otro día en pánico: "Bruno, ninguno de mis emails llega a Gmail. Ni al spam. Directamente los rechazan". Miré su SPF y estaba clarísimo:

"v=spf1 ip4:52.30.55.60 include:_spf.mail.hostinger.com include:mailgun.org include:_spf.google.com include:servers.mcsv.net include:sendgrid.net include:spf.brevo.com include:_spf.klaviyo.com include:_spf.zoho.eu include:_spf.freshdesk.com ~all"

Contaba 12 include. El límite máximo del SPF son 10 lookups DNS. Todo lo que supere 10 devuelve PERMERROR y Gmail lo trata como fallo total. Sus emails técnicamente no estaban autenticados, aunque el SPF existía y estaba escrito con "buena intención".

Este es solo uno de los 5 errores típicos que veo en el 80 % de los SPF que audito. Este artículo te enseña a diagnosticar cuál te está pasando y cómo arreglarlo.

Qué hace un SPF (y por qué es tan frágil)

El SPF (Sender Policy Framework) es un registro TXT en tu DNS que declara qué servidores están autorizados para enviar emails con tu dominio. Cuando Gmail recibe un email de pedro@midominio.com, mira el TXT midominio.com, comprueba si la IP que le está entregando el email está en la lista autorizada y decide: pass, fail, softfail, neutral, permerror.

Es un mecanismo simple, pero muy frágil. Los 5 errores más comunes:

Error 1: Dos SPFs en el mismo dominio

Alguien añadió un SPF para Google Workspace hace años. Ahora añades otro para tu ESP. Sintaxis inválida. Ambos ignorados. Gmail lo trata como sin SPF.

Cómo detectarlo:

dig +short TXT midominio.com | grep spf

Si ves dos líneas con v=spf1, tienes el problema.

Solución: fúndelos en uno solo. Combina los include: de ambos:

v=spf1 include:_spf.google.com include:_spf.mail.hostinger.com ~all

Error 2: PERMERROR por exceso de lookups

Cada include:, redirect=, mx, a cuenta como un lookup DNS. Máximo 10 en total, contando los lookups de los include: que a su vez hacen include: de otros dominios.

Cómo detectarlo: herramientas como MXToolbox o nuestro comprobador SPF gratis te dicen exactamente cuántos lookups estás gastando.

Soluciones:

  • Reducir senders: ¿realmente sigues usando todos? Elimina el SPF de servicios que ya no usas.
  • SPF flatting: reemplazar include:mailgun.org por sus IPs concretas (ip4:...). Ahorra lookups. Pero requiere mantener las IPs actualizadas.
  • Servicio de flatting: hay servicios como MacroLab, PowerDMARC, EasyDMARC que gestionan el flatting automáticamente. De pago.

Error 3: SPF válido pero sin el sender real

El caso típico: cambiaste de MailChimp a Klaviyo hace seis meses. El SPF sigue autorizando MailChimp pero no Klaviyo. Todos los emails de tu marketing fallan la autenticación.

Cómo detectarlo: enumera cada servicio que envía emails con tu dominio (marketing, transaccional, soporte, help desk, cold outbound). Comprueba que cada uno esté en tu SPF.

Solución: añadir el include: del sender que falta. Si en el proceso superas 10 lookups, tocará flatting.

Error 4: SPF terminado en +all

He visto varias veces senders novatos poner +all al final "por si acaso, para no bloquear nada". Esto autoriza cualquier IP del mundo a enviar emails con tu dominio. Es una invitación abierta al spoofing.

Cómo detectarlo: mira el final de tu SPF.

Solución: cambiar a ~all (softfail, estándar seguro) o -all (hardfail, más estricto). El estándar de facto es ~all con DMARC alineado.

Error 5: SPF con IPs hardcoded que ya no existen

Ejemplo: pusiste ip4:52.30.55.60 porque ese era el IP de tu VPS en 2021. En 2024 tu proveedor te asignó otra IP y nunca actualizaste el SPF. Ahora el SPF autoriza una IP que ya no es tuya (posiblemente ni siquiera de tu proveedor).

Cómo detectarlo: cada ip4: o ip6: de tu SPF debería justificarse. Si no recuerdas por qué está ahí, sospecha.

Solución: limpiar ip4:/ip6: obsoletas o reemplazarlas por include: del proveedor si son estables.

El error que veo casi todos los días

Los include: funcionan pero ya no son necesarios. Un ejemplo real que revisé la semana pasada:

v=spf1 include:_spf.google.com include:mailgun.org include:_spf.mail.hostinger.com ~all

El cliente había dejado de usar Mailgun hace un año. Pero el include:mailgun.org seguía ahí, sumando 3 lookups (mailgun anida a su vez include: de otros dominios). Al añadir SendGrid al SPF, saltó por encima de 10 lookups y todo se rompió.

Regla: cada 3-6 meses, revisa tu SPF y elimina los senders que ya no uses.

Cómo verificar que tu SPF pasa

Hay dos formas:

  1. Automática: el escáner de ClearRows te dice en 30 segundos si tu SPF pasa, cuántos lookups gastas, si hay duplicados, si termina bien. Comprobar mi SPF.

  2. Manual: envía un email a auth@verifier.port25.com. En 1-2 minutos te contesta con un reporte completo de SPF/DKIM/DMARC. Es gratis y no requiere registro.

Preguntas frecuentes

¿Debe ser ~all o -all? ~all (softfail) es el estándar seguro. -all (hardfail) es más estricto pero rompe emails legítimos si te olvidas de un sender. La mayoría usa ~all + DMARC estricto, que es equivalente en efecto pero más seguro.

¿Puedo tener SPF sin all? Técnicamente sí (?all = neutral), pero pierdes toda la utilidad del SPF. No lo hagas.

¿Debo publicar SPF en subdominios? Sí, si envías desde subdominios. Cada subdominio necesita su propio SPF (o un include: del dominio raíz, pero eso gasta un lookup). En 2026 la mejor práctica es SPF distinto por subdominio de envío.

¿SPF y DMARC son lo mismo? No. SPF autoriza IPs. DMARC dice qué hacer si SPF (o DKIM) fallan. Necesitas los tres — SPF, DKIM y DMARC — para tener autenticación real en 2026.

Si tu SPF está fallando y no sabes por qué, ejecuta el diagnóstico gratis en 30 segundos. Te decimos exactamente qué está mal y cómo escribir la línea correcta para tu DNS.