6 fallos de SPF más comunes y cómo arreglarlos

Tus correos están autenticados, tu DNS se ve limpio y tu entregabilidad es sólida. Pero un día, una nueva plataforma de marketing se activa, alguien ajusta un registro DNS, y de repente la mitad de tus correos termina en la carpeta de spam. ¿Te suena familiar?

Los fallos de SPF (Sender Policy Framework) son uno de los problemas más habituales de autenticación que vemos entre las más de 1.200 organizaciones que usan Red Sift OnDMARC. Y en 2026, con Google, Yahoo y Microsoft exigiendo autenticación a los remitentes masivos, un SPF roto no solo baja la entregabilidad: corta completamente la comunicación con tus clientes.

SPF es uno de los tres principales protocolos de autenticación de correo, junto con DKIM (DomainKeys Identified Mail) y DMARC (Domain-based Message Authentication, Reporting y Conformance). Su funcionamiento consiste en publicar un registro TXT en DNS que enumera qué IPs y servidores están autorizados a enviar correo usando tu dominio. Cuando un servidor receptor recibe un mensaje, comprueba la IP de envío contra tu registro SPF. Si no coincide, el correo falla la autenticación.

¿Por qué es crucial? En febrero de 2024, Google y Yahoo comenzaron a exigir que todos los remitentes masivos (más de 5000 mensajes diarios) autenticaran sus mensajes con SPF y DKIM y tuvieran un registro DMARC publicado [1]. Microsoft hizo lo mismo en mayo de 2025, aplicando los mismos requisitos para direcciones de Outlook.com, Hotmail.com y Live.com [2]. Entre los tres gestionan en torno al 90% de las listas B2C habituales. Un solo registro SPF roto puede dejar fuera a prácticamente toda tu audiencia de la noche a la mañana.

Y está en juego mucho más que la entregabilidad. El FBI registró en 2024 193.407 denuncias de phishing y spoofing, el tipo de ciberdelito más reportado, con pérdidas por crímenes en internet de 16.600 millones de dólares, un aumento del 33% sobre 2023 [3]. Solo el business email compromise supuso 2.770 millones de dólares en pérdidas por 21.442 incidentes [4]. Configurar bien la autenticación de correo, empezando por SPF, es tu primera línea de defensa ante la suplantación de dominio.

Y no solo lo exigen los proveedores de correo: PCI DSS v4.0.1 (en vigor desde marzo de 2025) obliga a tener DMARC en cuarentena o rechazo para quienes procesan pagos con tarjetas [5]. La CISA BOD 18-01 exige p=reject para dominios federales de EEUU. NCSC del Reino Unido, ASD de Australia y CCCS de Canadá también exigen DMARC para dominios gubernamentales. Cada vez más aseguradoras cibernéticas lo piden para pólizas. Consulta nuestro resumen global de mandatos DMARC.

En resumen: los fallos de SPF en 2026 ya no son una molestia menor. Son un problema de entregabilidad, cumplimiento y seguridad en uno solo.

Veamos los seis fallos de SPF más comunes y cómo solucionarlos.

Cómo se ve: Los correos de un servicio legítimo (tu CRM, herramienta de soporte o sistema ERP/HRP) fallan la autenticación SPF porque sus IPs no están en tu registro SPF.

Por qué ocurre: Este es el fallo más frecuente de SPF y suele reducirse a esto: alguien configura un nuevo servicio de envío y no actualiza el DNS. Tu equipo de soporte empieza a usar Zendesk para clientes. El equipo técnico integra un ERP para notificaciones. Cada servicio usa tu dominio, y cada uno debe estar explícitamente autorizado en tu SPF.

El problema se agrava con el tiempo: tu empresa adquiere otras con sistemas distintos de envío; proveedores cambian IPs sin avisar; una cuenta de pruebas se pasa a producción y nadie avisa a los de DNS. Empresas que usan Salesforce, SAP o Zendesk junto a su correo principal tienen aún más riesgo de lagunas.

Cómo solucionarlo:

Empieza auditando cada servicio que envía mail usando tu dominio. Consulta tus informes DMARC agregados: muestran exactamente qué IPs envían en tu nombre y si pasan/fallan SPF. Si usas Red Sift OnDMARC, la plataforma detecta remitentes no autorizados y los señala para acción.

Cuando tengas detectadas todas las fuentes legítimas de envío, añade sus mecanismos SPF a tu registro. Cada servicio publica su include, como include:spf.protection.outlook.com para Microsoft 365 o include:_spf.google.com para Google Workspace.

Ejemplo práctico: si usas Google Workspace y Zendesk, tu registro SPF debería ser algo así:

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

Consejo: Programa una auditoría SPF trimestral. Cada vez que añadas o retires un proveedor, actualiza el DNS. Los informes DMARC te lo muestran fácil, señalando exactamente quién envía y quién falla. Elimina también registros SPF que no deban estar debido a la alineación SPF (más adelante veremos esto).

Cómo se ve: Tu registro SPF da PermError (error permanente) y todos los correos de tu dominio fallan la autenticación SPF. Todos. No solo algunos.

Por qué ocurre: RFC 7208 (la especificación de SPF) limita a 10 las búsquedas de mecanismos DNS por verificación [6]. Los mecanismos include, a, mx y exists, junto con el modificador redirect, cuentan para ese límite. Los mecanismos ip4 y ip6 no cuentan, ya que son valores literales y no suponen búsquedas DNS extra.

La cuenta se llena rápido: Microsoft 365 suma 2 búsquedas, Google Workspace 4. Si añades SendGrid (1), Salesforce (2) y alguno más, ya superas el tope casi sin querer. Cada include puede tener a su vez includes anidados, y también cuentan. Son 10 consultas DNS en total, incluyendo todas las búsquedas en cadenas anidadas.

Si se superan antes de encontrar la IP autorizada, el servidor receptor devuelve PermError y detiene el análisis. DMARC lo interpreta como falla de SPF [7]. Tus correos se rechazan o acaban en spam y dependes solo de DKIM, que no ayuda si ese servicio no firma con DKIM.

Received-SPF: permerror (yourdomain.com: too many DNS lookups)
  client-ip=203.0.113.45;
  envelope-from=noreply@yourdomain.com;
  helo=mail.yourdomain.com;

Lee así: permerror confirma que el servidor alcanzó el tope de 10 búsquedas antes de encontrar un remitente autorizado, no que el remitente sea realmente no autorizado. La razón lo indica claramente. cruza client-ip y envelope-from con tu SPF para detectar qué include te pasa de límite.

Hay otro límite menos conocido: la regla de 2 "void lookups". Si dos consultas DNS durante la evaluación SPF devuelven NXDOMAIN (no existe el dominio) o vacío, una tercera provoca PermError [8]. Suele pasar si un include apunta a un dominio de proveedor que ya no tiene SPF, como uno descatalogado.

Cómo solucionarlo:

Primero, cuenta tus búsquedas actuales. Usa Red Sift Investigate para ver exactamente cuántas realiza tu SPF.

Luego reduce el número:

• Quita servicios retirados. Si cancelaste Mailchimp hace seis meses pero queda el include, quítalo. CRM antiguos, pruebas, o datos añadidos por exempleados suelen ser el problema.
• Elimina mecanismos ptr.ptr. Ya están obsoletos según la especificación SPF, desperdician búsquedas y no se recomiendan.
• Delegar servicios de envío en subdominios. Cada subdominio tiene su propio registro SPF y 10 búsquedas propias. Envía marketing por info.tudominio.com con su propio SPF, manteniendo el del dominio raíz sencillo.

Si tu organización no logra bajar de 10 manualmente, Dynamic SPF de Red Sift OnDMARC lo soluciona automático. Dynamic SPF sustituye tu registro complejo por un solo include inteligente que apunta solo a las IPs activas. Gestionas servicios de envío desde OnDMARC, sin editar el DNS manual, y mantienes el límite siempre.

Cómo se ve: SPF falla en todos tus correos o el registro ni siquiera se reconoce como tal. Puedes ver PermError o None en informes DMARC.

Por qué ocurre: Los registros SPF siguen reglas de formato estrictas según RFC 7208. Pequeños errores lo rompen completo. Errores comunes:

• Etiqueta de versión ausente o incorrecta. El SPF debe empezar con v=spf1. Errores como v=spf2, v=spf11 o espacios de más lo invalidan.
• Faltan espacios entre mecanismos. Debe haber un solo espacio entre cada mecanismo. Algo como include:_spf.google.cominclude:mail.zendesk.com (sin espacio) inutiliza el registro.
• Mecanismos mal formateados. Los de ip4 y ip6 llevan dos puntos antes del valor (ip4:192.168.1.1), nunca igual ni barra.
• Errores ortográficos en mecanismos. Escribir incldue por include o ipv4 en vez de ip4 invalida el registro.
• Uso del mecanismo obsoleto ptr.ptr. Aunque aún se interprete, ptr está en desuso, lo desaconseja RFC 7208 y añade carga DNS innecesaria.

Estos errores afectan al 100% del correo. El servidor ve el error de sintaxis, no lo puede analizar y da PermError (si lo evalúa parcialmente) o None (si ni detecta SPF).

Cómo solucionarlo:

Pasa tu registro por un validador antes de publicarlo. Red Sift Investigate localiza errores, cuenta búsquedas y encuentra toda clase de fallos al instante.

Un SPF limpio, para referencia:

v=spf1 ip4:203.0.113.0/24 include:_spf.google.com ~all

Fíjate: v=spf1 al principio, espacio entre cada mecanismo, dos puntos tras ip4 y un solo ~all al final. Siempre valida tras cada cambio, espera hasta 24h por la propagación DNS y revisa tus informes DMARC por fallos inesperados.

Cómo se ve: SPF devuelve PermError y toda la autenticación SPF falla (no solo algunos mensajes).

Por qué ocurre: La especificación SPF exige exactamente un registro SPF TXT por dominio [6]. Si tienes dos o más, los servidores no saben cuál usar y devuelven PermError.

Esto pasa cuando distintos equipos gestionan sectores del email: IT publica uno para Microsoft 365, marketing añade otro para su herramienta y un consultor suma uno más. Nadie comprueba si ya existe y de pronto hay tres registros SPF en el mismo dominio, ninguno operativo.

$ dig yourdomain.com TXT +short

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

Lee esto así: dos cadenas distintas empezando por v=spf1; el servidor no elige entre ellas y da PermError, igual que por exceso de búsquedas, pero por causa opuesta: demasiados registros en vez de demasiadas búsquedas. La solución es fusionarlos en uno, como se muestra después, y validar con el mismo comando que sólo queda una entrada v=spf1.

Pasa también en migraciones: al cambiar de Google Workspace a Microsoft 365, si no borras el SPF de Google al añadir el de Microsoft, se duplica y se rompe la configuración.

Cómo solucionarlo:

Consulta los registros TXT de tu dominio y busca entradas que empiecen por v=spf1. Debe haber solo una. Si hay varias, fusiona todos los remitentes autorizados en un solo registro.

Por ejemplo, si tienes:

Registro 1: v=spf1 include:spf.protection.outlook.com ~all Registro 2: v=spf1 include:_spf.google.com ~all

Fusiónalo en uno solo:

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

Borra el extra. Tras fusionar, valida que la suma no pasa de 10 búsquedas. Centralizar la gestión DNS y exigir aprobación ayuda a evitar más errores. Si varios equipos modifican el envío, usa una plataforma tipo Red Sift OnDMARC donde todo se gestiona desde un único lugar.

Cómo se ve: Los correos pasan SPF si se entregan directos pero fallan al reenviarse o circular por listas de correo. Tus informes DMARC muestran fallos SPF desde IPs de reenviadores conocidos (universidades, ISPs, servidores corporativos).

Por qué ocurre: Es una limitación fundamental de SPF y el único fallo de la lista que no es por una mala configuración.

SPF comprueba si la IP del servidor de envío está autorizada para el dominio. Si un mail se reenvía, el reenvíador (Servidor B) lo remite al destinatario final (Servidor C) usando su propia IP. El Servidor C la comprueba contra el SPF original, ve que no coincide (pues el reenvíador nunca está autorizado) y SPF falla.

Las listas de correo lo empeoran: suelen modificar el mensaje (añadiendo un pie, cabeceras, enlaces de baja…), lo que también puede romper DKIM. Si fallan SPF y DKIM, DMARC falla igualmente.

Esto es así por diseño: SPF fue creado para rutas directas, sin mecanismos para intermediarios.

Cómo afrontarlo:

No puedes "arreglar" el SPF para reenvíos, pero sí construir un sistema de autenticación resiliente:

• Haz de DKIM tu respaldo principal. DKIM depende del contenido, no del trayecto. Mientras el cuerpo no se modifique durante el reenvío, la firma DKIM sigue válida y DMARC pasa. Haz que todos los servicios firmen por DKIM usando tu dominio. Consulta nuestra guía de configuración para SPF, DKIM y DMARC. Nuestra guía de protocolos de correo detalla gestión de claves DKIM, selectors y resolución de fallos.
• Usa ~all (soft fail), no -all (hard fail). Algunos servidores evalúan SPF antes que DMARC. Con -all pueden rechazar a nivel SMTP antes de evaluar DKIM/DMARC. El soft fail deja avanzar el mensaje, así que DMARC lo verifica y una firma DKIM válida puede salvarlo. La recomendación actual (2026) es ~all en dominios emisores [9]. Combinado con DMARC p=reject tienes la misma protección sin rechazado prematuro.
• Comprende ARC (Authenticated Received Chain). Es un protocolo para que servidores intermedios conserven los resultados originales de autenticación. Cuando un reenviador de confianza (como Gmail o Microsoft 365) "sella" los resultados de SPF y DKIM, el servidor destino puede referenciar esos datos aunque SPF falle en el último salto. ARC es automático en los principales proveedores; no necesitas configurarlo en el envío [10].

Nota: El IETF acaba de aprobar que ARC se depreque oficialmente. DKIM2 será su reemplazo.DKIM2 será su reemplazo.

• Monitorea los reenvíos en tus informes DMARC. Separa fallos debidos a reenvíos de intentos de spoofing real. El reenvío proviene de IPs de servidores reconocidos y suele mostrar SPF fail y DKIM pass; los ataques usan IPs desconocidas y fallan ambos.

Cómo se ve: SPF pasa (la IP es autorizada) pero DMARC falla. Esto confunde a muchos, porque creen que SPF pass equivale a DMARC pass. No es así. Para entender cómo trabajan juntos SPF, DKIM y DMARC, la diferencia es clave.

Por qué ocurre: DMARC exige alineación entre el dominio autenticado y el del remitente visible (From). Para SPF, significa que el dominio de Return-Path (rebote/envelope from/MAIL FROM) debe coincidir, o ser subdominio, del dominio en el From.

Muchos servicios de envío usan por defecto su propio dominio como Return-Path. Por ejemplo, Salesforce lo usa para gestionar rebotes salvo que lo configures tú. SPF comprueba el dominio de Return-Path, ve la IP de Salesforce en su registro y SPF pasa. Pero DMARC pregunta: "¿Coincide el Return-Path con el From?" Si el From es @yourdomain.com y el Return-Path es @bounce.salesforce.com, la alineación falla. SPF autoriza, pero falla la alineación. Si no puedes alinear SPF, DKIM es imprescindible.

Es donde más organizaciones se atascan implementando DMARC. Configuran SPF correctamente y no entienden por qué sigue fallando DMARC o SPF.

Cómo solucionarlo:

En cada servicio de envío, configura el Return-Path (dirección de rebote) para que use tu dominio o uno de tus subdominios. Según la plataforma:

• Salesforce: Desactiva la gestión de rebotes para que use tu dominio como Return-Path.
• Microsoft 365: La alineación se gestiona automáticamente al usar tu dominio personalizado.
• Plataformas de marketing (HubSpot, Marketo, Mailchimp): Suelen ofrecer configuración de Return-Path/envelope-from. Consulta la documentación de cada plataforma.

DMARC soporta dos modos de alineación:

• Alineación estricta (aspf=s):aspf=s): Return-Path debe coincidir exactamente con el From.
• Alineación relajada (aspf=r):aspf=r): Return-Path puede ser subdominio del From. Es el valor por defecto y recomendable para la mayoría.

Con alineación relajada, si el From es @yourdomain.com y el Return-Path @mail.yourdomain.com, la alineación pasa. Así puedes usar subdominios y cumplir DMARC.

Tu informe DMARC agregado es la clave. Muestra estatus de pase/fallo SPF y de alineación, permitiéndote distinguir entre autorización (SPF) o alineación (coincidencia de dominio Return-Path y From).

Red Sift OnDMARC lo muestra visualmente, señalando los remitentes que pasan SPF pero fallan alineación y el dominio culpable. Empieza tu implementación DMARC paso a paso y revísalos uno a uno.

Los informes DMARC agregados contienen todo lo necesario para identificar y corregir fallos de SPF. Debes buscar:

Si estás analizando informes DMARC manualmente (analizando XML), estás dedicando horas a un trabajo que una plataforma puede hacer en segundos. Red Sift OnDMARC transforma los datos sin procesar de los informes agregados en paneles claros y accionables que muestran exactamente qué remitentes están fallando, por qué fallan y cómo solucionarlo. Para un recorrido por las mejores herramientas para cada etapa, consulta nuestra guía de las principales herramientas de autenticación de correo electrónico.

Los fallos de SPF se pueden corregir. Cada uno de los seis fallos tratados en esta guía tiene una ruta de diagnóstico clara y una solución concreta. El verdadero desafío no es la complejidad. Es la visibilidad.

Sin informes DMARC, vas a ciegas. No sabes qué servicios están enviando en nombre de tu dominio, cuáles fallan la autenticación o por qué. Con ellos, cada fallo se convierte en un elemento que puedes investigar y resolver.

Si estás lidiando con fallos SPF ahora mismo, comienza con un escaneo gratuito usando Red Sift Investigate para ver el estado actual de tu registro. Para monitorización continua, gestión automatizada de remitentes y un camino claro hacia la aplicación de DMARC, inicia una prueba gratuita de Red Sift OnDMARC.

[1] An update on bulk sender requirements - Google

[2] Strengthening Email Ecosystem - Microsoft Community Hub

[3] FBI Releases Annual Internet Crime Report

[4] 2024 IC3 Annual Report

[5] PCI DSS v4.0.1 Summary of Changes

[6] RFC 7208 - Sender Policy Framework (SPF)

[7] The SPF lookup limit explained - Mailhardener

[8] RFC 7208 Section 4.6.4 - DNS Lookup Limits

[9] SPF failures: Hard fail vs Soft fail - Red Sift

[10] ARC: Solving the DMARC Problem with Email Forwarding - Mailflow Authority