Comprobación de SPF en Exchange: cómo verificar, publicar y corregir registros SPF en Exchange

En mayo de 2025, Microsoft comenzó a rechazar los correos electrónicos de remitentes de gran volumen que carecían de SPF, DKIM y DMARC válidos. Si tu dominio envía más de 5.000 mensajes al día a Outlook.com o Hotmail.com sin la autenticación adecuada, esos mensajes nunca llegan a la bandeja de entrada.

Google y Yahoo introdujeron requisitos similares en febrero de 2024. Esa primera ronda de medidas redujo los mensajes no autenticados recibidos por los usuarios de Gmail en aproximadamente un 75 %, según el equipo de seguridad del correo electrónico de Google.

El suplantación de identidad en el correo electrónico empresarial, que aprovecha directamente las deficiencias en la autenticación del correo electrónico, provocó pérdidas declaradas por valor de 2.900 millones de dólares en 2023, según Informe sobre delitos en Internet del FBI IC3, 2023. 

El problema en los entornos de Exchange es que los fallos de SPF pasan desapercibidos. Exchange Online no te avisa cuando tu registro deja de funcionar correctamente. No hay ningún panel de control integrado que muestre las tasas de superación. La mayoría de los equipos se enteran semanas después, cuando los usuarios se quejan de que los correos electrónicos rebotan, o cuando el departamento de marketing les informa de que las tasas de apertura se han desplomado.

Esta guía explica cómo comprobar el registro SPF de Exchange mediante cuatro métodos diferentes, cómo publicar el registro correcto para Exchange Online, entornos locales y configuraciones híbridas, y cómo solucionar los errores más comunes errores de SPF (incluido el límite de 10 consultas que hace que el SPF falle en la mayoría de las organizaciones del mercado medio), cómo evalúa realmente Exchange Online el SPF en segundo plano y cómo supervisar el SPF de forma continua en lugar de comprobarlo una vez y olvidarse de él.

Cómo comprobar el registro SPF de Exchange (paso a paso)

Hay cuatro formas fiables de comprobar tu registro SPF, de la más rápida a la más exhaustiva. Utilice el Método 1 para una verificación rápida y el Método 4 para obtener visibilidad operativa continua.

Método 1: Utilizar una herramienta de búsqueda de SPF (la más rápida)

1. Abre cualquier verificador de SPF (el verificador de SPF de PowerDMARC es gratuito y no requiere registro)
2. Introduce tu dominio (por ejemplo, tudominio.com, sin el prefijo http://) y 
3. Revisa el resultado

La consulta devuelve varios resultados de validación SPF. A continuación se explica el significado de cada campo de salida y a qué debes prestar atención al revisarlos: 

Un registro puede analizarse correctamente y el recuento de consultas puede ser de seis, pero aún así puede faltar una fuente de envío válida. El verificador SPF comprueba la información del DNS, pero no sabe qué direcciones IP deberían estar autorizadas.

Método 2: Comprobarlo a través del Centro de administración de Microsoft 365

Inicia sesión en el Centro de administración de Microsoft 365. Ve a Configuración → Dominios → selecciona tu dominio → Registros DNS. En la sección de Microsoft Exchange, comprueba que el estado del registro TXT sea «OK».

Si el estado indica «Entrada no válida», es posible que falte el registro SPF o que no incluya la declaración obligatoria «include:spf.protection.outlook.com». Esta es la forma más rápida de verificar el SPF sin salir del portal de administración.

Método 3: Comprobación mediante la línea de comandos (nslookup / dig)

Para la resolución de problemas del lado del servidor o en situaciones en las que no se dispone de acceso al navegador, puedes consultar el registro TXT de SPF de tu dominio directamente desde la línea de comandos.

Ejecuta uno de los siguientes comandos: 

# Windows

nslookup -type=txt tudominio.com

# Linux 

/ macOSdig txt tu-dominio.com +short

El resultado muestra el registro TXT sin procesar. Busca la línea que empieza por «v=spf1». Si ves dos líneas de este tipo, significa que hay varios registros SPF, lo que provoca un error de permiso inmediato. Corrígelo antes de hacer nada más.

Método 4: Comprobación mediante los informes agregados de DMARC (el método de referencia)

Los informes agregados de los servidores de recepción, como Gmail, Yahoo, Microsoft, Mail.ru y los proveedores de servicios de Internet regionales, muestran las tasas de superación o fracaso de SPF en todos los correos electrónicos enviados por tu dominio, no solo en un mensaje de prueba. Esta es la única forma de obtener una visión completa y actualizada del estado de SPF.

Si estás publicando DMARC con una etiqueta «rua=», ya estás recopilando estos informes. La mayoría de las organizaciones los tienen, pero solo unas pocas los leen, ya que el XML sin procesar es ilegible sin una plataforma que lo analice.

PowerDMARC recopila estos informes a diario y presenta análisis específicos de SPF en un panel de control específico, con índices de aprobación/rechazo por fuente de envío, seguimiento de consultas DNS y alertas cuando aparece un nuevo remitente no autorizado.

Método 5: Verificar mediante los encabezados de los mensajes de Exchange (validación en condiciones reales)

Para comprobar cómo evalúa el SPF un destinatario real:

• Envía un mensaje de prueba desde tu dominio a una dirección externa (una cuenta personal de Gmail sirve).
• Abre el mensaje y extrae los encabezados completos. En Outlook: Archivo → Propiedades → Encabezados de Internet. En OWA o Gmail: Ver código fuente / Mostrar original.
• Busca el encabezado «Authentication-Results» y localiza el campo «spf=».

Así es como se ve el encabezado en cuestión, con las anotaciones:

Resultados de la autenticación: 

spf=válido (la IP del remitente es 40.107.22.83)  

smtp.mailfrom=tudominio.com;  

dkim=pass (se ha verificado la firma)  

header.d=tudominio.com;  

dmarc=pass action=none  

header.from=tudominio.com;  

compauth=pass motivo=100

«spf=pass» confirma que la IP remitente ha sido autorizada por tu registro SPF. Si ves «spf=fail», «spf=softfail» o «spf=permerror», el resultado concreto te indica cuál es el problema:

• spf=fail: La dirección IP del remitente no aparece en tu registro SPF.
• spf=softfail: La dirección IP no está autorizada, pero tu registro utiliza «~all» en lugar de «-all».
• spf=permerror: Tu registro SPF presenta un problema estructural (más de 10 consultas, registros múltiples, error de sintaxis).

Cómo es un registro SPF válido de Exchange

Cómo publicar un registro SPF para Exchange Online (M365)

Publicar un registro SPF para Exchange Online es sencillo. Sin embargo, la mayoría de los equipos cometen errores a la hora de introducir los datos correctamente.

Paso 1: Identifica todas tus fuentes de envío autorizadas

Antes de modificar la configuración del DNS, revisa todos los sistemas que envían correos electrónicos en nombre de tu dominio. La mayoría de las organizaciones subestiman esta lista en un 30-50 %.

• Microsoft 365 / Exchange Online → incluir:spf.protection.outlook.com
• Automatización del marketing (HubSpot, Mailchimp, Marketo, Pardot) → cada una tiene su propia integración
• CRM (Salesforce, Microsoft Dynamics) → consultar la documentación sobre SPF del proveedor
• Correo electrónico transaccional (SendGrid, Amazon SES, Postmark, Mailgun) → plantillas específicas de cada proveedor
• Servicio de asistencia / gestión de incidencias (Zendesk, Freshdesk, ServiceNow) → incluye soluciones específicas de cada proveedor
• Recursos Humanos / Nóminas (BambooHR, Gusto, Workday) → comprueba si envían notificaciones desde tu dominio
• Servidores locales heredados → IPv4: con direcciones IP públicas

La forma más fiable de descubrir remitentes que no conocías es los informes agregados de DMARC. Todas las fuentes legítimas (e ilegítimas) que envían mensajes desde tu dominio aparecen allí.

Paso 2: Crear el registro SPF

Empieza por la etiqueta de versión, añade las fuentes autorizadas y termina con el calificador.

Ejemplo básico de M365:

v=spf1 

incluir:spf.protection.outlook.com -all

Una empresa típica del segmento medio que utiliza HubSpot y SendGrid:

v=spf1 

incluir:spf.protection.outlook.com 

incluyen:_spf.hubspot.com 

incluir:sendgrid.net -all

Cuenta las consultas DNS a medida que construyes. Cada mecanismo «include:», «a:», «mx:», «ptr:» y «exists:» genera una consulta. Los mecanismos «ip4:» e «ip6:» no cuentan. Las inclusiones anidadas también cuentan, ya que la propia «include:spf.protection.outlook.com» consume entre 2 y 4 consultas adicionales internamente al encadenarse a través de la infraestructura de Microsoft.

Paso 3: Publicar el registro en el DNS

El proceso de publicación varía ligeramente según el proveedor de DNS, pero sigue el mismo patrón:

Configuraciones que se deben utilizar siempre:

• Tipo de registro: TXT
• Servidor / Nombre: @ (o en blanco, según el proveedor)
• TTL: 3600 (1 hora) durante las pruebas; posteriormente, 86400 (24 horas) una vez que se haya estabilizado

Importante: Solo un registro SPF por dominio. Un segundo registro TXT v=spf1 es un PermError a la espera de ser detectado. Si el proceso de aprovisionamiento de tu proveedor de DNS crea automáticamente un registro al añadir un servicio, comprueba inmediatamente si hay duplicados.

Paso 4: Verificar el registro publicado

• Espera entre 5 y 60 minutos a que se complete la propagación del DNS (dependiendo del TTL y del proveedor).
• Vuelve a realizar la consulta SPF del Método 1 para confirmar que el registro se resuelve correctamente.
• Comprueba el Centro de administración de M365 (Método 2). El estado del registro TXT debería aparecer ahora como «OK».
• Envía un mensaje de prueba a una dirección externa y comprueba que en los encabezados aparezca «spf=pass».
• Comprueba que el número de consultas DNS sea inferior a 10.

Si prefieres no crear el registro manualmente, el Generador SPF de PowerDMARC genera un registro con el formato adecuado una vez que indiques tus fuentes de envío.

SPF para entornos híbridos de Exchange: local + nube

Los entornos híbridos de Exchange aumentan considerablemente la complejidad del SPF, ya que el correo electrónico puede proceder tanto de Microsoft 365 como de la infraestructura local al mismo tiempo. Especialmente durante las migraciones, las rutas de flujo de correo suelen solaparse de tal manera que provocan fallos silenciosos del SPF, a menos que se tenga en cuenta correctamente cada ruta de salida.

El reto híbrido: dos rutas de correo, un registro SPF

En un entorno híbrido, el correo saliente puede enviarse a través de tres rutas diferentes:

• Directamente desde Exchange Online: para buzones alojados en M365
• Servidores Exchange locales o servidores de transporte Edge: para los buzones de correo que aún se encuentran en las instalaciones
• Servidores inteligentes o servidores de retransmisión de terceros: cuando el correo se redirige externamente antes de llegar a la red pública de Internet

Cada ruta presenta al servidor destinatario una dirección IP de origen diferente. Al SPF no le importa cuál era la ruta prevista, ya que solo comprueba si la dirección IP que realmente ha detectado está autorizada. Ambas rutas deben estar cubiertas en un único registro SPF, ya que solo se permite un registro SPF por dominio.

Cómo configurar el SPF para Exchange híbrido

Incluye ambas rutas de autorización:

v=spf1 include:spf.protection.outlook.com ip4:203.0.113.10 ip4:203.0.113.11 -all

Las direcciones IP locales son las direcciones públicas que utiliza tu servidor de correo cuando envía mensajes a Internet, no las direcciones internas del RFC 1918. Comprueba los conectores de envío de tu servidor de transporte perimetral y cualquier regla de NAT o del cortafuegos que determine la dirección IP pública. Si dispones de redundancia geográfica o de múltiples rutas de salida, todas las direcciones IP públicas desde las que pueda originarse el correo deben figurar en el registro.

SPF durante la migración (estado de transición)

La migración por etapas o con conmutación introduce un periodo en el que los buzones de correo coexisten en ambas ubicaciones y el correo puede enviarse desde cualquiera de las dos rutas. El SPF debe cubrir ambas rutas durante todo ese tiempo.

• Antes de iniciar la migración: Asegúrate de que tu registro SPF cubra tanto las entradas ip4: locales como include:spf.protection.outlook.com.
• Durante la migración: Mantenga ambas autorizaciones activas. Supervise los índices de éxito de SPF a través de los informes agregados de DMARC. Si los cambios en el enrutamiento desvían el correo por rutas inesperadas, los informes lo mostrarán antes de que lo hagan los usuarios.
• Una vez completada la migración: Elimina las entradas ip4: locales. Dejar direcciones IP obsoletas en el SPF supone un riesgo de seguridad. Si tu proveedor de servicios de Internet o tu proveedor de servicios en la nube reasigna esas direcciones IP antiguas, el nuevo usuario podrá enviar correo autenticado en nombre de tu dominio.

Un error habitual es eliminar las direcciones IP locales durante la migración porque la transición está «casi terminada». Basta con que un solo buzón siga enrutándose a través de la ruta antigua para que falle la autenticación del correo de ese usuario.

Subdominios en Exchange: el SPF no se hereda

Un aspecto crucial que suele pasar desapercibido en muchas organizaciones híbridas: los subdominios no heredan el registro SPF del dominio principal. Si marketing.tudominio.com envía correos electrónicos a través de un proveedor de servicios de correo electrónico (ESP) independiente, necesita su propio registro TXT de SPF. El protocolo no admite registros SPF con comodines. Cada subdominio que envíe correo debe tener su propio registro v=spf1 publicado en la raíz de su DNS.

Esto también significa que el uso de subdominios es una estrategia eficaz para distribuir la carga de SPF. Dirija el correo de marketing a través de marketing.sudominio.com y el correo transaccional a través de mail.sudominio.com, de modo que cada subdominio disponga de su propio presupuesto de 10 consultas. Esta práctica cumple con los requisitos del RFC, cuenta con un amplio soporte por parte de los proveedores de servicios de correo electrónico (ESP) y se utiliza ampliamente en entornos empresariales.

¿Comprueba Exchange Online el SPF en el correo entre inquilinos?

No. Exchange Online trata los mensajes entre usuarios de un mismo inquilino como correo interno y no realiza la evaluación de SPF. Los mensajes entre diferentes inquilinos, incluso entre organizaciones asociadas de confianza, están sujetos a comprobaciones de SPF, ya que ese correo recorre la ruta pública de enrutamiento del correo.

En el caso de las organizaciones que cuentan con varios dominios en un mismo inquilino de M365, cada dominio necesita su propio registro SPF. Compartir un registro entre dominios mediante un CNAME no es una práctica habitual y no funciona de forma fiable.

Errores comunes de SPF en Exchange y cómo solucionarlos

Todos los casos de resolución de problemas que se describen a continuación siguen el mismo esquema de diagnóstico: síntoma → causa → solución.

PermError: Demasiadas consultas DNS

• • Síntoma: SPF devuelve PermError. Es posible que los destinatarios marquen tu correo electrónico como spam o lo rechacen. La alineación DMARC falla.
  • Causa: Más de 10 consultas DNS en su registro SPF, incluidas las inclusiones anidadas. Este es el error de SPF más común en las organizaciones que utilizan múltiples servicios SaaS.

• Solución (proceso de 5 pasos):

• • Paso 1: Comprueba tu recuento actual de búsquedas utilizando un verificador de SPF que cuente de forma recursiva las inclusiones anidadas.
  • Paso 2: Elimina las inclusiones obsoletas de los servicios que ya no utilizas.
  • Paso 3: Sustituir «include:» por «ip4:» en los casos en que las direcciones IP del proveedor sean estables y estén documentadas.
  • Paso 4: Traslade a los remitentes no corporativos de gran volumen (marketing, transaccionales) a subdominios con sus propios registros SPF.
  • Paso 5: Si sigues teniendo más de 10, implementa el aplanamiento de SPF o macros utilizando una herramienta como PowerSPF para resolver automáticamente las inclusiones en entradas IPv4 y mantener el registro actualizado cuando los proveedores cambien de IP.

Ejemplo de antes y después:

Antes (14 consultas: PermError):

v=spf1 include:spf.protection.outlook.com include:_spf.hubspot.com include:sendgrid.net include:servers.mcsv.net include:_spf.salesforce.com include:zendesk.com include:spf.freshdesk.com a mx -all

Después de (7 consultas: por debajo del límite):

v=spf1 include:spf.protection.outlook.com include:_spf.hubspot.com include:sendgrid.net ip4:198.2.128.0/24 ip4:192.254.113.0/24 -all# Salesforce y Zendesk se han trasladado a mail.tudominio.com# Freshdesk sustituido por entradas ip4 simplificadas# mecanismos a y mx eliminados (redundantes con las inclusiones explícitas)

Se han encontrado varios registros SPF

• Síntoma: El verificador de SPF devuelve un error de «múltiples registros SPF». Todas las evaluaciones de SPF fallan.
• Causa: Existen dos o más registros TXT que comienzan por v=spf1 para el mismo dominio. Esto suele ocurrir cuando el proceso de aprovisionamiento de un proveedor de SaaS crea un segundo registro sin que el administrador se dé cuenta.
• Solución: Fusiona en un solo registro. Puedes tener muchos mecanismos «include:» e «ip4:» dentro de un mismo registro, pero solo un registro TXT «v=spf1» por dominio. Elimina la entrada redundante.

SPF deja de funcionar tras añadir una nueva herramienta SaaS

• Síntoma: Los correos electrónicos de la herramienta recién añadida no superan la verificación SPF. Es posible que otros remitentes tampoco la superen si la nueva inclusión eleva el número total de consultas por encima de 10.
• Causa: El nuevo servicio no se ha añadido a SPF, o al añadirlo se ha superado el límite de consultas.
• Solución: Añade la inclusión y, a continuación, vuelve a auditar el total de búsquedas. Si ahora superas las 10, el problema es el recuento de búsquedas, no la inclusión en sí. Aplica el flujo de trabajo de 5 pasos descrito anteriormente.

Error de SPF en Exchange híbrido (falta la dirección IP local)

• Síntoma: Los correos electrónicos enviados desde Exchange local no superan la verificación SPF, mientras que los correos procedentes de M365 sí la superan.
• Causa: La dirección IP pública del servidor local no figura en el registro SPF. Esto es especialmente habitual tras una migración parcial en la que el administrador actualizó el SPF para Exchange Online, pero olvidó que la ruta local sigue enrutando el correo.
• Solución: Añade ip4:x.x.x.x para cada IP de salida local. Si el correo se enruta a través de un servidor de transporte perimetral, un host inteligente o un relé de terceros, también debe incluirse la IP pública de ese relé.

SPF deja de funcionar tras la migración a Exchange Online

• Síntoma: Los correos electrónicos posteriores a la migración no superan la verificación SPF en todos los casos.
• Causa: El DNS sigue apuntando a direcciones IP locales antiguas; entre otras cosas, no se ha añadido include:spf.protection.outlook.com, o el correo se está enrutando por rutas inesperadas durante la transición.
• Solución: Comprueba que el registro SPF incluya tanto las rutas de autorización antiguas (locales) como las nuevas (Exchange Online) durante el periodo de migración. Elimina las entradas antiguas solo cuando se haya confirmado que el 100 % de los buzones se han migrado. Supervisa el proceso con informes agregados de DMARC en todo momento. Estos te muestran exactamente qué rutas sigue tu correo desde la perspectiva de los destinatarios.

El SPF se aprueba, pero el correo electrónico va a parar a la carpeta de spam

• Síntoma: Los encabezados muestran spf=pass, pero el mensaje acaba en la carpeta de correo no deseado del destinatario.
• Causa: El SPF es solo una señal entre muchas. La reputación del remitente, el contenido, el DKIM o el DMARC pueden fallar. Cualquiera de estos factores puede anular un resultado positivo en el SPF.
• Solución: Comprueba la alineación DKIM, la política DMARC, la reputación del remitente (estado en listas negras, antigüedad del dominio, cambios recientes en el volumen) y la reputación del contenido y los enlaces. El Analizador de Dominios de PowerDMARC devuelve una calificación de todos estos aspectos en un solo análisis.

SPF falla en los correos electrónicos reenviados

• Síntoma: Los mensajes reenviados automáticamente, los correos electrónicos de listas de distribución o los mensajes enrutados por reglas de transporte no superan la verificación SPF.
• Causa: La IP del servidor de reenvío no figura en el registro SPF del remitente original. Se trata de una limitación arquitectónica del SPF, más que de un error de configuración.
• Solución: Considera el fallo de SPF en el correo reenviado como un comportamiento esperado. Asegúrate de que DKIM esté correctamente configurado para tu dominio. Las firmas DKIM se conservan tras el reenvío, lo que permite que DMARC pase la comprobación de alineación DKIM incluso cuando SPF falla. ARC (Authenticated Received Chain) en Exchange Online conserva además los resultados de autenticación a lo largo de las cadenas de reenvío de confianza.

Cómo procesa realmente Exchange Online los resultados de SPF (una explicación de la «caja negra»)

La mayoría de los administradores de Exchange se enfrentan a la misma duda: ¿cómo gestiona realmente Exchange Online Protection (EOP) los errores de SPF? Algunas fuentes afirman que un error grave implica un rechazo automático. Otras sugieren que el SPF es solo un indicador secundario de spam. A continuación te explicamos cómo funciona realmente.

El canal de señales múltiples (SPF es solo una de las entradas)

Exchange Online Protection no toma decisiones sobre la entrega basándose únicamente en el SPF. El SPF es uno de los factores que se tienen en cuenta en una evaluación de autenticación combinada que incluye:

• Resultado de SPF: aprobado, fallido, fallo leve, neutro, PermError o TempError
• Resultado de DKIM: aprobado, suspendido o ninguno
• Resultado de DMARC: derivado de la comparación de SPF o DKIM con el dominio del encabezado «From»
• Reputación del remitente: reputación de la IP, reputación del dominio, patrones históricos de envío
• Puntuación del nivel de confianza de spam (SCL): puntuación interna de Microsoft que va de -1 (remitente seguro) a 9 (spam de alta confianza)
• Filtrado de contenidos: palabras clave, reputación de URL, análisis de archivos adjuntos

EOP utiliza el resultado de la autenticación combinada, y no un protocolo concreto, para determinar el destino final del mensaje.

Cómo gestiona EOP cada resultado del SPF

PermError es un error grave que EOP trata de forma casi idéntica a un fallo total de SPF, y que se propaga a DMARC, lo que impide por completo la autenticación. Por eso el límite de 10 consultas constituye un punto de fallo estructural.

Dónde consultar los resultados de SPF en Exchange

Tres sitios, ordenados de menor a mayor según su exhaustividad:

• Encabezados de los mensajes (Authentication-Results): Cada mensaje procesado por EOP se marca con spf=pass/fail/softfail/permerror/temperror, junto con el dominio y la IP de envío evaluados.
• Seguimiento de mensajes de Exchange: Muestra el estado de entrega, la IP de origen, el destinatario y el destino final, pero no muestra de forma destacada la evaluación del SPF. Si te basas únicamente en el seguimiento de mensajes para conocer el estado del SPF, estás actuando a ciegas.
• Informes agregados de DMARC (RUA): La única fuente de datos que muestra cómo evalúan los receptores de todo el mundo tu SPF. Los informes RUA muestran las tasas de aprobación y rechazo del SPF por IP y por origen en todos los servidores receptores que procesan tu correo.

Configuración de la aplicación de fallos graves de SPF en EOP

De forma predeterminada, Exchange Online tiene en cuenta los resultados de SPF en su puntuación global, pero no rechaza los mensajes basándose únicamente en SPF. Para configurar EOP de forma explícita para que marque los mensajes con error grave de SPF como spam:

En el Centro de administración de Exchange Online: ve a Protección → Filtro de correo no deseado → Opciones avanzadas y activa la opción «Registro SPF: error grave». También puedes ejecutar el siguiente cmdlet de PowerShell:

Get-HostedContentFilterPolicy | Where-Object {$_.IsDefault -eq $true} | Set-HostedContentFilterPolicy -MarkAsSpamSpfRecordHardFail On

Buenas prácticas de SPF para entornos Exchange en 2026

• Utiliza -all (rechazo absoluto) como criterio predeterminado. En combinación con DMARC, -all es el estándar. La única excepción es el periodo inicial de implementación, antes de que DMARC esté operativo.
• Nunca utilices +all. Esto permite que cualquier usuario de Internet envíe mensajes en nombre de tu dominio. Si encuentras +all en tu registro, considéralo un incidente de seguridad activo.
• Incluye siempre spf.protection.outlook.com para M365, incluso si el correo saliente se envía a través de una pasarela de terceros. Exchange Online genera invitaciones de calendario, respuestas automáticas, notificaciones de entrega fallida (NDR) y confirmaciones de lectura que se envían directamente desde la infraestructura de Microsoft.
• Revisa tu registro SPF al menos una vez al trimestre. Los proveedores de SaaS cambian los rangos de IP. Los equipos de marketing adoptan nuevas herramientas sin avisar al departamento de TI. Las revisiones trimestrales detectan las desviaciones antes de que provoquen un PermError. La supervisión continua a través de los informes DMARC detecta las desviaciones en tiempo real.
• Implementa SPF junto con DKIM y DMARC. El SPF por sí solo no evita la suplantación del campo «From» del encabezado. El DKIM por sí solo no valida el remitente del sobre. Solo la aplicación de DMARC, que comprueba la coherencia de SPF o DKIM con el dominio del campo «From» del encabezado, ofrece una protección completa.
• Cumpla con los requisitos para remitentes establecidos por los principales proveedores de correo electrónico. En 2026, Google, Yahoo, Microsoft y Apple exigirán el uso de SPF, DKIM y DMARC a los remitentes masivos. La norma PCI DSS v4.0, de obligado cumplimiento desde marzo de 2025, exige explícitamente estas tres medidas como controles contra el phishing.

Cómo supervisar el SPF de forma continua 

La principal diferencia entre las organizaciones que tienen «SPF configurado» y aquellas que están realmente protegidas por SPF es la supervisión. La configuración inicial es la parte fácil, pero detectar fallos silenciosos a lo largo de los meses siguientes es lo que distingue la autenticación de correo electrónico que funciona de la autenticación teórica.

Por qué las comprobaciones puntuales del SPF generan una falsa sensación de seguridad

Los registros SPF varían constantemente porque los proveedores modifican sus rangos de IP autorizados, tus cadenas «include:» se resuelven en direcciones IP diferentes y cualquiera de ellas puede hacer que se supere el límite de consultas. Los equipos añaden nuevas herramientas SaaS sin actualizar el SPF. Las migraciones modifican el enrutamiento del correo saliente de formas que tu DNS no refleja. Quedan entradas antiguas de servicios que la organización dejó de utilizar hace años.

Cómo funciona la monitorización continua del SPF

Cuatro componentes, cada uno de los cuales aborda un modo de fallo específico:

• Informes agregados de DMARC que se recopilan a diario de receptores de todo el mundo. Estos muestran los resultados de SPF por IP y por origen en todos los servidores receptores que han procesado tu correo. PowerDMARC recopila estos datos automáticamente y los presenta en un panel de análisis de SPF específico, con índices de aprobación/rechazo por origen, seguimiento del recuento de consultas DNS y líneas de tendencia históricas.
• Alertas automáticas en el momento en que los fallos de SPF superan un umbral, cuando aparece una nueva fuente de envío no autorizada o cuando un cambio en el DNS afecta a tu registro. Las PowerAlerts de PowerDMARC las envía por correo electrónico, Slack o Discord para que el equipo adecuado se entere del problema durante el horario laboral.
• Aplanamiento automático de SPF que se actualiza cuando los proveedores externos cambian las direcciones IP. Las resoluciones de resuelve las cadenas de «include:» en entradas «ip4:» y mantiene tu registro permanentemente por debajo de 10 consultas sin necesidad de ediciones manuales del DNS.
• Supervisión de listas negras y reputación. Si tus direcciones IP de envío acaban en una lista de bloqueo, es posible que el SPF se supere, pero la capacidad de entrega seguirá viéndose afectada. La supervisión integrada de la reputación detecta los fallos que el SPF por sí solo no detecta.

Especialmente para los MSP: cuando el proveedor de un cliente cambia su rango de direcciones IP, os enteráis antes de que el correo electrónico del cliente deje de funcionar. 

El panel de control para MSP de PowerDMARC permite supervisar de forma centralizada el SPF en todos los dominios de los clientes desde una única pantalla, con la posibilidad de profundizar en los datos por cliente. Esto transforma la gestión del SPF, pasando de ser una tarea reactiva de resolución de problemas a convertirse en una línea de servicios estructurada.

Empieza una prueba gratuita de 15 días para que lo compruebes por ti mismo. 

Preguntas frecuentes

¿Cómo puedo comprobar los registros SPF en Exchange Online?

Utiliza una herramienta de consulta de SPF, como el verificador SPF de PowerDMARC, introduce tu dominio y revisa el registro, la sintaxis y el número de consultas. También puedes verificarlo en el Centro de administración de Microsoft 365, en Configuración → Dominios → Registros DNS. Para la verificación por parte del destinatario, comprueba el encabezado «Authentication-Results» en un mensaje de prueba enviado desde el exterior.

¿Qué registro SPF necesito para Microsoft 365?

Como mínimo: v=spf1 include:spf.protection.outlook.com -all. Si utilizas servicios de envío adicionales (HubSpot, SendGrid, Salesforce, Zendesk), añade sus entradas «include» antes de «-all». Asegúrate de que el número total de consultas DNS no supere las 10, incluidas las consultas anidadas dentro de cada entrada «include:».

¿Por qué falla SPF aunque mi registro parece correcto?

Causas habituales: superar el límite de 10 consultas DNS (PermError), tener varios registros SPF en el mismo dominio, correos electrónicos reenviados (el SPF deja de funcionar al reenviarlos por diseño) o que un proveedor cambie sus rangos de IP autorizados sin avisarte. Comprueba el encabezado «Authentication-Results» para ver el resultado específico de «spf=».

¿Cuál es la diferencia entre «-all» y «~all»?

-all (rechazo definitivo) indica a los receptores que rechacen o denieguen los mensajes procedentes de direcciones IP no autorizadas. ~all (rechazo no definitivo) es más permisivo. En 2026, una vez implementado DMARC, la política DMARC controlará la aplicación independientemente del calificador. Si aún no dispone de DMARC, -all ofrece una protección considerablemente mayor.

¿Cuántas consultas DNS realiza include:spf.protection.outlook.com?

La llamada a Microsoft cuenta como una consulta, pero da lugar a llamadas anidadas que consumen aproximadamente entre 2 y 4 consultas adicionales. El número exacto varía a medida que Microsoft actualiza su infraestructura. Compruébalo siempre con una herramienta de análisis que cuente de forma recursiva las consultas anidadas.

¿Es suficiente el SPF para impedir la suplantación de identidad en el correo electrónico?

No. El SPF por sí solo no impide la suplantación de la dirección «De:» visible (el campo «From» del encabezado). Solo valida el remitente del sobre (Return-Path). Para lograr una protección completa, se requiere DKIM para la firma a nivel de mensaje, además de DMARC para garantizar el cumplimiento. El uso conjunto de estos tres protocolos, junto con una supervisión continua, será la norma en 2026.