Registro SPF de DNS: cómo funciona y cómo configurarlo

Cada correo electrónico que envía tu organización afecta a la reputación de tu dominio. Si tu registro SPF está mal configurado o no existe, los servidores receptores no tienen ninguna forma fiable de verificar que el correo electrónico realmente proviene de ti. Los correos electrónicos legítimos acaban en la carpeta de spam. Las campañas de marketing se devuelven. Los atacantes envían mensajes que parecen proceder de tu dominio.

El SPF (Sender Policy Framework) es uno de los tres principales protocolos de autenticación , junto con DKIM y DMARC, que indica a los servidores de correo receptores qué direcciones IP están autorizadas a enviar correo electrónico en nombre de tu dominio. Se publica como un registro TXT del DNS. A simple vista, parece sencillo. En la práctica, el SPF es el origen de la mayoría de los problemas de autenticación del correo electrónico. 

Esta guía explica con detalle qué es exactamente un registro SPF, cómo funciona la verificación SPF paso a paso, cómo crear uno y cómo solucionar los errores más comunes de SPF, incluido el límite de 10 consultas DNS que impide silenciosamente la entrega de correos electrónicos en las organizaciones en expansión.

¿Qué es un registro SPF de DNS?

Un registro SPF (Sender Policy Framework) de DNS es un tipo de registro TXT de DNS que especifica qué servidores de correo están autorizados a enviar correos electrónicos en nombre de tu dominio. Ayuda a los servidores de correo receptores a verificar que los mensajes entrantes proceden de fuentes legítimas, lo que reduce el riesgo de suplantación de identidad y phishing. Cuando se recibe un correo electrónico, el servidor comprueba el registro SPF del dominio del remitente para confirmar que la IP de envío está autorizada. 

Si la dirección IP no aparece en la lista, es posible que el mensaje sea marcado, rechazado o enviado a la carpeta de correo no deseado. Configurar correctamente un registro SPF mejora la capacidad de entrega del correo electrónico y refuerza la autenticación del dominio.

Puedes comprobar el registro SPF de tu dominio al instante con una herramienta gratuita de búsqueda de SPF. Tarda cinco segundos y te muestra exactamente lo que está publicado en tu DNS.

¿Cómo funciona la autenticación SPF?

La autenticación SPF sigue un proceso estructurado de búsqueda y validación en el DNS cada vez que se recibe un correo electrónico:

• Tu dominio publica un registro SPF como una entrada TXT de DNS. Este registro define todas las fuentes de envío autorizadas mediante mecanismos como ip4, ip6, include, y una, junto con una política predeterminada (-all, ~all, o ?all).
• Cuando se envía un correo electrónico, el servidor de envío incluye una dirección «Return-Path» (remitente del sobre) que representa el dominio responsable de la entrega.
• El servidor de correo receptor extrae el dominio de la dirección «Return-Path».
• Realiza una consulta DNS para recuperar el registro SPF asociado a ese dominio.
• A continuación, la dirección IP del servidor remitente se compara con cada uno de los mecanismos del registro SPF, procesándose en orden hasta que se encuentra una coincidencia o se toma una decisión sobre la política.
• SPF impone un límite de 10 consultas DNS durante esta evaluación para evitar una recursión excesiva; si se supera este límite, se produce un PermError.
• En función del resultado, SPF devuelve un valor como «Pass», «Fail», «SoftFail», «Neutral», «None», «PermError» o «TempError».
• El servidor receptor utiliza este resultado, junto con la autenticación DKIM y la conformidad con la política DMARC, para determinar cómo debe gestionarse el mensaje (entregarlo, ponerlo en cuarentena o rechazarlo).

Un detalle fundamental: el SPF valida el dominio del «Return-Path» (remitente del sobre), no el encabezado «From» visible. Si estos dominios difieren, como suele ocurrir con las plataformas de envío de terceros, es posible que el SPF se supere, pero la alineación DMARC puede fallar, lo que afecta directamente a la entrega en la bandeja de entrada.

Cada código de resultado del SPF tiene un significado práctico concreto:

Informes agregados de DMARC te muestran exactamente qué correos superan y cuáles no superan la verificación SPF en todas tus fuentes de envío. Sin los informes DMARC, los fallos de SPF se producen de forma silenciosa y nunca te enteras hasta que alguien se queja.

Explicación de la sintaxis y el formato de los registros SPF

Para comprender la sintaxis de SPF, lo primero es leer un registro completo y saber cómo se evalúa cada parte. He aquí un ejemplo típico:

v=spf1 include:_spf.google.com include:spf.protection.outlook.com ip4:203.0.113.0/24 -all (donde /24 representa un rango de 256 direcciones IP utilizando la notación de enrutamiento entre dominios sin clases (CIDR))

Esta única línea indica a los servidores receptores exactamente qué fuentes están autorizadas a enviar correos electrónicos en nombre de tu dominio y qué deben hacer si un remitente no figura en la lista.

Etiqueta de versión SPF (v=spf1)

Cada registro SPF debe comenzar con v=spf1. Esto identifica el registro TXT como una política SPF. No hay otras versiones válidas. Si esta etiqueta falta o es incorrecta, el registro se ignora por completo.

Mecanismos SPF (remitentes autorizados) 

Los mecanismos definen quién puede enviar correos electrónicos. Se evalúan de izquierda a derecha, y la primera coincidencia determina el resultado.

Entre incluyen: El mecanismo «include» es el más utilizado y el que causa más problemas. Cada «include:» desencadena una consulta DNS recursiva. Si el registro SPF de Google incluye otros tres dominios, todos ellos cuentan para tu límite de 10 consultas.

Un punto que suele generar confusión: el un en SPF hace referencia al registro A del DNS del dominio. No crea un «registro A para SPF» independiente. Cuando añades un a tu registro SPF, estás autorizando cualquier dirección IP a la que resuelva el registro A de tu dominio.

Modificadores (redirect=)

Los modificadores controlan el comportamiento de la evaluación del SPF, en lugar de definir a los remitentes.

• redirect=
  Transfiere toda la evaluación SPF a otro dominio. A diferencia de include:, que añade otra política a tu registro, redirect= sustituye tu evaluación por completo.
  Utilícelo solo cuando un dominio deba heredar por completo la configuración SPF de otro dominio.

Límite de consultas DNS (restricción crítica)

SPF permite un máximo de 10 consultas DNS por evaluación. Mecanismos como incluyen:, un, mx, existe:, y redirect= cuenta para este límite.

Si se supera el límite, SPF devuelve un PermError y la autenticación falla, incluso si el remitente es legítimo. Por eso, los registros grandes y complejos suelen requerir una optimización (como reducir las inclusiones que no se utilizan o simplificarlos).

Clasificatorios del SPF (el mecanismo «all»)

El calificativo en el «all» al final de tu registro SPF define tu política SPF: qué ocurre con los correos electrónicos procedentes de servidores que no figuran explícitamente en la lista:

SPF funciona como un conjunto de reglas lógicas. El servidor receptor lee el registro de izquierda a derecha, comprueba cada mecanismo y se detiene en la primera coincidencia. Si no se encuentra ninguna coincidencia, el se aplica la .

Un registro SPF bien estructurado es:

• Completo (incluidos todos los remitentes legítimos)
• Eficaz (dentro de los límites de la consulta)
• Estrictos (utilizando -all una vez validado)

Esto garantiza una autenticación precisa y evita el uso no autorizado de tu dominio para el envío de correos electrónicos.

Cómo crear y publicar un registro SPF

Para configurar un registro SPF, es necesario identificar todas las fuentes de envío legítimas, definirlas claramente en el DNS y comprobar que la configuración funciona según lo previsto. Sigue estos 5 pasos en el orden indicado.

Paso 1: Identifica todas tus fuentes de envío

Enumera todos los servicios que envían correos electrónicos en nombre de tu dominio. Por lo general, esto incluye tu proveedor de correo electrónico principal (como Google Workspace o Microsoft 365), plataformas de marketing (como Mailchimp o HubSpot), sistemas de gestión de relaciones con los clientes (CRM) (Salesforce), herramientas de asistencia (Zendesk) y servicios de correo electrónico transaccional (SendGrid, Amazon SES). Cada uno de estos servicios envía desde una infraestructura diferente, por lo que todos deben estar autorizados explícitamente. La mayoría de los proveedores publican un valor SPF «include» en su documentación, que indica a los servidores receptores que confíen en sus direcciones IP de envío.

Paso 2: Crea tu registro SPF

Un registro SPF es una entrada TXT de una sola línea que comienza por «v=spf1». A continuación, se definen los remitentes autorizados mediante los siguientes mecanismos:

• incluir: para servicios de terceros (por ejemplo, include:_spf.google.com)
• ip4: o ip6: para direcciones IP específicas o rangos que usted controle
  Los mecanismos se evalúan de izquierda a derecha. Al final, se define una política:
• ~all (error leve) marca a los remitentes no autorizados como sospechosos
• -all (error grave) los rechaza explícitamente

Por ejemplo:

v=spf1 include:_spf.google.com include:servers.mcsv.net ip4:198.51.100.0/24 ~all

Este registro indica a los servidores receptores exactamente qué fuentes están permitidas y cómo deben tratar el resto.

Paso 3: Publicar el registro en el DNS

Inicia sesión en tu proveedor de DNS (como Cloudflare, Route 53 o GoDaddy). Crea un nuevo registro TXT para tu dominio raíz:

• Servidor/Nombre: @ (o déjelo en blanco, dependiendo del proveedor)
• Valor: tu registro SPF completo
  Una vez guardado, el registro pasa a ser accesible públicamente a través del DNS. Los cambios pueden tardar un tiempo en propagarse.

Paso 4: Validar el registro

Tras la publicación, comprueba que:

• El registro SPF tiene el formato correcto (sin errores de sintaxis)
• Todo se ha resuelto correctamente
• El número total de consultas DNS no supera el límite de 10 (si se supera, SPF devuelve un PermError)

La validación garantiza que los servidores receptores puedan procesar tu registro de forma fiable y sin errores.

Paso 5: Supervisar los resultados del SPF

El SPF no es una configuración que se realiza una sola vez. A medida que añadas o elimines fuentes de envío, deberás actualizar tu registro SPF. Para supervisar el rendimiento:

• Habilitar DMARC para recibir informes agregados que muestren las tasas de aprobación/rechazo de SPF
• Comprueba qué fuentes superan o no la autenticación
• Elimina los servicios que no se utilicen y corrige los remitentes desalineados o no autorizados

Importante: Solo se permite un registro SPF por dominio. Si hay varios registros TXT que comienzan por v=spf1 , la evaluación SPF falla por completo con un PermError. Combina siempre todas las fuentes de envío en un único registro completo.

El límite de consultas DNS de SPF 10 (y por qué afecta al funcionamiento de tu correo electrónico)

La evaluación del SPF no es ilimitada. Según el RFC 7208, un servidor receptor puede realizar un máximo de 10 consultas DNS mientras procesa tu registro SPF. Si se supera este límite, el SPF devuelve un PermError (error permanente) y la comprobación falla por completo.

No se trata de un fallo parcial. Un PermError significa que el SPF no se puede evaluar en absoluto. Como consecuencia, todos los correos electrónicos enviados desde tu dominio pierden la autenticación SPF, independientemente de si el remitente es legítimo.

¿Qué se tiene en cuenta para el límite de 10 búsquedas?

Los siguientes mecanismos activan las consultas DNS:

• entre ellos: (los más comunes y los de mayor repercusión)
• a
• mx
• ptr (obsoleto, pero sigue contando si se utiliza)
• existe:
• redirect=

Los mecanismos «ip4:» e «ip6:» no cuentan para el límite de búsquedas, ya que hacen referencia directa a las direcciones IP, sin necesidad de resolución DNS

Por qué es fácil sobrepasar este límite

El principal problema se debe a las búsquedas anidadas (recursivas).

Cuando añades un «include:», no solo estás añadiendo una entrada, sino que también estás heredando todo lo que contiene el registro SPF de ese proveedor.

Por ejemplo:

• Si incluyes Google, el SPF de Google puede incluir otros muchos dominios
• Si incluyes Microsoft 365 → se añaden varias consultas más
• Incluyes herramientas de marketing y transaccionales → cada una añade su propia cadena

Esto se acumula rápidamente. Aunque el registro parezca corto, el número real de consultas puede superar las 10 durante la evaluación.

El límite de 2 «búsquedas nulas» (que a menudo se pasa por alto)

SPF también impone un límite de 2 consultas nulas.

Una búsqueda sin resultados se produce cuando una consulta DNS no devuelve ningún resultado (dominio inexistente [NXDOMAIN] o una respuesta vacía).

Causas comunes:

• Entre los datos incorrectos u obsoletos se incluyen: los dominios
• Errores tipográficos en los mecanismos SPF
• Referencias a dominios que ya no existen

Si se producen más de dos consultas nulas, SPF vuelve a devolver un PermError.

A PermError no significa «fallo para algunos remitentes». Significa:

• El SPF no es válido
• Los servidores receptores no pueden confiar en tu política SPF
• El SPF, en la práctica, no ofrece protección ni autenticación

Dado que el SPF es una de las señales que utiliza DMARC, esto también puede dar lugar a:

• Errores de DMARC (si DKIM no coincide)
• Aumento de la presencia de spam
• Rechazo de mensajes por parte de destinatarios más exigentes

A medida que tu infraestructura de correo electrónico crece, tu registro SPF se vuelve, naturalmente, más complejo. Sin una gestión activa:

• El número de consultas aumenta sin que nos demos cuenta
• Los servicios no utilizados permanecen en el registro
• Los errores se acumulan con el tiempo

El SPF es delicado en este sentido. Solo funciona de forma fiable cuando los registros se mantienen dentro de los límites establecidos, son precisos y se actualizan continuamente.

A qué velocidad se alcanza el límite (ejemplo real)

Así es como se presenta una pila de SaaS típica del mercado medio en lo que respecta a las consultas de DNS:

Ni siquiera has añadido todavía Zendesk, SendGrid, tu servicio de asistencia técnica ni tu proveedor de nóminas. Si tu organización utiliza Google Workspace junto con cuatro o cinco herramientas SaaS que envían correos electrónicos, es probable que ya hayas alcanzado o superado el límite.

Cómo solucionar los problemas relacionados con el límite de consultas SPF

Si tu registro SPF supera el límite de 10 consultas DNS, debes reducir su complejidad sin afectar a las fuentes de envío legítimas. Estos son los tres enfoques prácticos, ordenados por orden de impacto:

Eliminar los mecanismos innecesarios

Empieza por realizar una auditoría completa de tu registro SPF.

• Identifica todos los incluir: y los mecanismos que figuran actualmente en la lista
• Comprueba si cada servicio sigue enviando correos electrónicos de forma activa para tu dominio
• Retira todo lo que ya no se utilice

Problemas comunes:

• Las antiguas herramientas de marketing que quedaron en el archivo
• Incluir duplicados en todos los subdominios
• Los servicios de prueba o temporales nunca se han eliminado

Cada uno de los que que elimines inmediatamente libera una o más consultas DNS. Esta es la forma más sencilla y de menor riesgo de volver a estar por debajo del límite.

Sustituir incluir: por ip4:/ip6: siempre que sea posible

Si un remitente utiliza un conjunto fijo y reducido de direcciones IP, puedes sustituir su incluir: por entradas de IP directas.

• Ejemplo: sustituir include:vendor.com por ip4:x.x.x.x
• Esto elimina por completo las consultas de DNS para ese remitente

Cuándo funciona bien:

• Infraestructura interna
• Direcciones IP dedicadas de un proveedor
• Proveedores con rangos de direcciones IP estables y debidamente documentados

Aspectos que hay que sopesar:

• Te haces cargo del mantenimiento
• Si el proveedor actualiza o cambia las direcciones IP, tu registro SPF quedará desactualizado
• Esto puede provocar errores silenciosos en el SPF hasta que se corrija

Utiliza esto solo cuando se pueda predecir la estabilidad de la dirección IP.

Uso SPF de aplanamiento o SPF Macros

Cuando se utilizan varios servicios de terceros, la limpieza manual por sí sola no suele ser suficiente. Se necesita una forma de reducir el número de consultas sin perder cobertura.

Aplanamiento del FPS

• Resuelve todos incluidos: mecanismos en sus direcciones IP subyacentes
• Los sustituye por una lista plana de ip4: / ip6: entradas
• Elimina la mayoría de las consultas DNS

Limitación:

• Los registros aplanados son estáticos
• Si un proveedor (como Google o Microsoft) actualiza sus direcciones IP de envío, tu registro no se actualiza automáticamente
• Esto da lugar a una laguna por la que los correos electrónicos legítimos pueden no superar la verificación SPF sin previo aviso

Macros SPF (alternativa dinámica)

• Mantener la evaluación del SPF dinámica sin dejar de controlar la profundidad de la búsqueda
• Reducir la dependencia de las cadenas de inclusión largas
• Más adecuado para entornos en los que la infraestructura de los remitentes cambia con frecuencia

¿No sabes cuántas consultas utiliza tu registro SPF? Comprueba el número de consultas con nuestro verificador SPF gratuito

Para aquellas organizaciones que necesitan mantenerse por debajo del límite de 10 consultas sin tener que gestionar manualmente el DNS, la función PowerSPF ofrece tanto aplanamiento y las modernas macros SPF, lo que te permite elegir la técnica que mejor se adapte a tu entorno. El registro se actualiza automáticamente cuando los proveedores externos cambian sus rangos de IP autorizados.

Por qué el factor de protección solar (FPS) por sí solo no es suficiente

El SPF es un método de autenticación básico, pero no fue diseñado para ofrecer una protección total contra las técnicas modernas de suplantación de identidad y el uso indebido. Presenta tres limitaciones fundamentales que lo hacen insuficiente por sí solo.

Limitación 1: SPF comprueba el remitente del sobre, no el encabezado «From»

SPF valida el campo «Return-Path» (remitente del sobre), es decir, el dominio utilizado durante la transmisión del correo electrónico. Sin embargo, los usuarios ven el encabezado «De», que puede ser diferente.

Esto crea una vulnerabilidad que los atacantes pueden aprovechar:

• Un atacante envía un correo electrónico desde su propio dominio (que supera la verificación SPF)
• Configuran la dirección del remitente visible para que aparezca como tu dominio o como una persona de confianza
• El SPF se valida porque el dominio de origen es legítimo
• El destinatario sigue viendo una identidad falsificada

SPF no dispone de ningún mecanismo integrado para verificar que el dominio de envío coincida con el remitente visible. DMARC resuelve este problema imponiendo la coincidencia entre SPF (o DKIM) y el dominio del encabezado «De».

Limitación 2: el SPF se rompe al reenviar correos electrónicos

El SPF se basa en la dirección IP del servidor remitente. Cuando se reenvía un correo electrónico:

• El servidor de reenvío se convierte en la nueva fuente de envío
• Su dirección IP se compara con el registro SPF del dominio original. Dado que el servidor de reenvío no figura como remitente autorizado, el SPF falla.
• Como no aparece en la lista, SPF falla

Esto ocurre incluso cuando el correo electrónico es totalmente legítimo. No se trata de un error de configuración, sino de una limitación del funcionamiento del SPF.

Repercusión:

• Los correos electrónicos reenviados legítimos suelen fallar en la verificación SPF
• Los sistemas receptores deben basarse en otras señales (como DKIM) para validar el mensaje

Limitación 3: El SPF no cuenta con un mecanismo de notificación propio

SPF no ofrece ninguna función de generación de informes integrada.

Sin una capa adicional:

• No sabes qué fuentes superan o no la verificación SPF
• No puedes detectar remitentes no autorizados que utilicen tu dominio
• No tienes visibilidad sobre los problemas de autenticación que afectan a la capacidad de entrega

DMARC incorpora funciones de generación de informes, lo que te proporciona datos agregados sobre los resultados de SPF y DKIM en todos los receptores.

La infraestructura moderna del correo electrónico, con reenvíos, listas de distribución, remitentes externos y técnicas sofisticadas de suplantación de identidad, ha superado las capacidades que ofrece el SPF por sí solo. DKIM añade una firma criptográfica que se mantiene tras el reenvío, resolviendo así la mayor debilidad de SPF. DMARC es la capa de políticas que conecta SPF y DKIM con el encabezado «De».

Para ver una comparación completa de cómo funcionan estos protocolos en conjunto, consulta nuestra guía sobre SPF, DKIM y DMARC.

Errores habituales en los registros SPF (y cómo solucionarlos)

La mayoría de los fallos del SPF se reducen a unos pocos problemas recurrentes. El problema radica principalmente en la falta de mantenimiento y validación. A continuación te explicamos cómo identificarlos y solucionarlos con medidas concretas.

Error 1: Varios registros SPF en el mismo dominio.

SPF requiere una única política oficial. Si varios registros TXT comienzan con v=spf1, los servidores receptores no pueden determinar cuál deben evaluar. El resultado es un PermError, lo que significa que SPF falla por completo para todos los mensajes.

Por qué ocurre:

• Los distintos equipos añaden registros de forma independiente (marketing, TI, herramientas de asistencia)
• Los nuevos proveedores proporcionan instrucciones para «añadir este registro» sin comprobar la configuración existente

Cómo solucionarlo:

• Comprueba todos los registros TXT de tu dominio
• Identificar todas las entradas relacionadas con el SPF
• Integrar todos los mecanismos en un único registro completo

A qué hay que prestar atención:

• Registros incompletos que quedaron tras las migraciones
• Subdominios utilizados incorrectamente en lugar del dominio raíz 

Error 2: Superar el límite de 10 consultas DNS

Cuando la evaluación del SPF supera las 10 consultas DNS, se detiene inmediatamente y devuelve un PermError. Esto invalida el SPF para todos los remitentes, incluso los legítimos.

Por qué ocurre:

• El uso excesivo de incluyen: para múltiples herramientas SaaS
• Inclusiones anidadas de proveedores (tú las incluyes y estas, a su vez, incluyen otras)
• No se puede consultar el recuento acumulado de búsquedas

Cómo solucionarlo:

• Identificar todos los mecanismos y su impacto en las consultas
• Elimina primero las llamadas a archivos de inclusión que no se utilicen o que sean redundantes
• Reevalúa si realmente es necesario que todas las herramientas envíen mensajes desde tu dominio

A qué hay que prestar atención:

• Búsquedas «ocultas» dentro de archivos de terceros
• Una acumulación gradual a lo largo del tiempo a medida que se van incorporando nuevas herramientas

Error 3: Usar +all (pasar todo)

Esto indica explícitamente a los servidores receptores que confíen en cualquier origen de envío, lo que, en la práctica, desactiva el SPF como medida de seguridad.

Por qué ocurre:

• Interpretación errónea de la sintaxis de SPF
• Las configuraciones de prueba temporales nunca se restablecieron

Cómo solucionarlo:

• Sustituir por ~todo mientras compruebas tu configuración
• Ir a -todos una vez que se hayan confirmado todos los remitentes legítimos

A qué hay que prestar atención:

• Documentos antiguos copiados de fuentes poco fiables
• Dominios que parecen «autenticados», pero que en realidad no cuentan con protección alguna

Error 4: Usar el indicador ptr obsoleto

Mecanismos como ptr introducen búsquedas lentas y poco fiables y pueden ser ignorados por los receptores modernos, lo que da lugar a resultados SPF inconsistentes.

Por qué ocurre:

• Configuraciones heredadas que se han ido manteniendo a lo largo del tiempo
• Documentación o plantillas obsoletas

Cómo solucionarlo:

• Eliminar mecanismos obsoletos como ptr
• Sustituir por include: o ip4: / ip6: entradas

A qué hay que prestar atención:

• Registros excesivamente complejos que intentan gestionar casos extremos
• Mecanismos que añaden complejidad sin aportar un beneficio claro

Error n.º 5: No indicar las fuentes legítimas de envío

Los correos electrónicos procedentes de plataformas válidas no superan la comprobación SPF, lo que puede provocar:

• Mensajes que van a parar a la carpeta de correo no deseado
• Retrasos en la entrega o devoluciones
• Errores de DMARC si no existe una alternativa compatible

Por qué ocurre:

• Se han añadido nuevas herramientas sin actualizar el SPF
• Falta de coordinación entre los equipos que gestionan los sistemas de correo electrónico

Cómo solucionarlo:

• Mantener una lista centralizada de todas las fuentes de envío autorizadas
• Incluir la verificación de SPF como parte del proceso de incorporación, y no cuando ya hayan surgido problemas
• Comprueba periódicamente que todos los remitentes activos estén incluidos

A qué hay que prestar atención:

• Los sistemas transaccionales (facturación, alertas) suelen pasarse por alto
• Herramientas regionales o específicas de cada equipo que se envían de forma independiente

Error 6: Registro SPF que supera los 255 caracteres en una sola cadena DNS

Los registros SPF que superen los límites del DNS o que tengan un formato incorrecto pueden quedar truncados o interpretarse erróneamente, lo que puede provocar fallos silenciosos.

Por qué ocurre:

• Demasiadas inclusiones y mecanismos en un solo registro
• Los proveedores de DNS gestionan los valores TXT largos de forma diferente

Cómo solucionarlo:

• Escribe el informe de la forma más concisa posible
• Si es necesario, utiliza varias cadenas entre comillas dentro de un mismo registro TXT
• Comprueba de nuevo el registro publicado después de guardarlo (no solo los datos introducidos)

A qué hay que prestar atención:

• Entradas que parecen correctas en tu panel de DNS, pero que se resuelven de forma incorrecta
• Problemas de formato surgidos durante las modificaciones manuales

Realiza una comprobación gratuita del estado de tu SPF para ver si tu registro presenta alguno de estos errores

Buenas prácticas de SPF para 2026

Un registro SPF correcto no es solo una cuestión de sintaxis. Se trata de mantener una política que se adapte a los cambios a medida que evoluciona tu infraestructura de correo electrónico. Estas prácticas recomendadas te ayudan a garantizar que tu configuración de SPF siga siendo fiable, eficaz y acorde con los requisitos actuales para los remitentes.

1. Mantener un único registro SPF por dominio

SPF solo permite un registro TXT que comience por v=spf1. La presencia de varios registros provoca un PermError, lo que impide por completo la autenticación. Incorpora siempre las nuevas entradas al registro existente.

2. Incluir todas las fuentes de envío legítimas

Tu registro SPF debe incluir todos los sistemas que envían correos electrónicos en tu nombre. Si falta algún remitente, se producirán errores en el SPF, lo que afecta directamente a la capacidad de entrega y al cumplimiento de DMARC.

3. No superar el límite de 10 consultas DNS

Cada incluyen:, un, mx, existe:, y redirect= cuenta para el límite. Superar los 10 da lugar a un PermError, lo que invalida el SPF para todos los correos electrónicos. Revisa y optimiza tu registro con regularidad.

4. Elimina las llamadas a archivos «include» que no se utilicen o que estén obsoletas

Las herramientas antiguas, los entornos de prueba y los servicios obsoletos suelen permanecer en los registros SPF mucho tiempo después de que hayan dejado de enviar mensajes. Esto añade una complejidad innecesaria y agota el presupuesto de consultas.

5. Prefiere IPv4: y ip6: para una infraestructura controlada

Si gestionas direcciones IP dedicadas o rangos de envío estables, utiliza mecanismos de IP directa en lugar de include:. Esto reduce las consultas de DNS y mejora el rendimiento.

6. Evita utilizar +all bajo ninguna circunstancia

El calificador permite que cualquier servidor envíe mensajes en nombre de su dominio, lo que, en la práctica, desactiva el SPF como medida de seguridad. Nunca debe utilizarse en entornos de producción.

7. Utiliza ~todos durante la configuración y, a continuación, pasa a -all

Empieza con ~all (softfail) mientras valida su configuración. Una vez que se hayan confirmado todos los remitentes legítimos y se hayan alineado con DMARC, cambie a -all (hardfail) para una aplicación estricta.

8. Evita mecanismos obsoletos o peligrosos como ptr

El ptr está en desuso y no es fiable. Introduce búsquedas de DNS innecesarias y puede ser ignorado por los receptores modernos. Utiliza mecanismos explícitos en su lugar.

9. Supervisar el rendimiento del SPF mediante los informes DMARC

El SPF por sí solo no ofrece visibilidad. Activa los informes DMARC para hacer un seguimiento de qué fuentes superan o no la verificación SPF en todos los receptores e identificar actividades no autorizadas.

10. Considerar el SPF como un sistema que requiere una gestión continua

El SPF no es una configuración que se haga una sola vez. Cada nueva herramienta, plataforma o proveedor que envíe correos electrónicos debe reflejarse en tu registro SPF. Revísalo y actualízalo con regularidad para evitar fallos silenciosos.

Cómo funciona SPF junto con DKIM y DMARC

SPF, DKIM y DMARC están diseñados para funcionar como un sistema coordinado. Cada uno de ellos aborda un aspecto diferente del problema de la confianza en el correo electrónico, como la legitimidad del remitente, la integridad del mensaje y la coincidencia de identidades, y solo en conjunto ofrecen una protección y un control fiables.

Cuando se recibe un correo electrónico, la autenticación se lleva a cabo en varias etapas:

• SPF comprueba si la dirección IP del servidor remitente está autorizada para el dominio indicado en el campo «Return-Path» (remitente del sobre).
• DKIM verifica la firma criptográfica adjunta al mensaje, confirmando que no ha sido alterado y que el dominio que lo ha firmado es válido
• DMARC evalúa los resultados de SPF y DKIM y comprueba si alguno de ellos coincide con la dirección «De» visible

SPF y DKIM generan resultados de autenticación sin procesar, pero DMARC determina si esos resultados son relevantes en el contexto de lo que el destinatario ve realmente.

Se necesitan tanto SPF como DKIM porque cada uno compensa las deficiencias del otro. SPF falla en el reenvío, mientras que DKIM no. Algunos intermediarios pueden eliminar DKIM, pero SPF no depende del contenido del mensaje. Juntos, proporcionan redundancia.

DMARC añade la capa de políticas: ¿qué deben hacer los destinatarios cuando ni SPF ni DKIM coinciden? Las tres opciones son ninguna (solo supervisar), cuarentena (enviar a spam) y rechazar (bloquear por completo). DMARC también añade la función de informes; sin ella, nunca se sabe cuándo falla la autenticación.

Conclusión

El SPF es la base de la autenticación del correo electrónico, pero su eficacia depende de su configuración y su utilidad, del marco DMARC al que se integra. Un registro SPF mal configurado impide la entrega del correo electrónico, expone tu dominio a la suplantación de identidad y hace que tu organización incumpla los requisitos vigentes para los remitentes.

El siguiente paso es el mismo tanto si estás configurando el SPF por primera vez como si estás solucionando un problema con un registro defectuoso: comprueba tu configuración actual.

Comprueba la configuración de autenticación del correo electrónico de tu dominio con nuestro Analizador de dominios gratuito . Evalúa SPF, DKIM, DMARC y mucho más en cuestión de segundos. ¿Necesitas supervisión continua, gestión automatizada de SPF e informes DMARC? 

Empieza una prueba gratuita de 15 días

Preguntas frecuentes

¿Puede un dominio tener más de un registro SPF?

No. El RFC 7208 exige exactamente un registro SPF por dominio. Si hay dos registros TXT que comienzan por v=spf1 , ambos devuelven PermError y el SPF falla por completo. Combina todas las fuentes autorizadas en un único registro.

¿Qué significa que mi dominio tenga demasiadas consultas DNS?

Tu registro SPF supera el límite de 10 consultas DNS establecido por el RFC 7208. Esto provoca un error «SPF PermError», lo que impide la autenticación SPF de todos los correos electrónicos, no solo de los que superan el límite. Reduce el número de inclusiones y sustitúyelo por ip4:/ip6:, o utiliza el aplanamiento de SPF o macros para mantenerte por debajo del límite.

¿Cuál es la diferencia entre el «softfail» (~all) y el «hardfail» (-all) de SPF?

Softfail (~all) indica a los destinatarios que acepten el correo electrónico, pero que lo marquen como sospechoso. Hardfail (-all) indica a los destinatarios que rechacen el correo electrónico directamente. Utilice softfail durante la configuración inicial y las pruebas; cambie a hardfail una vez que se hayan confirmado todos los remitentes legítimos y se haya implementado DMARC.

¿Evita el SPF la suplantación de identidad en el correo electrónico?

No por sí solo. El SPF comprueba el remitente del sobre (Return-Path), no el encabezado «De» que ven los destinatarios. Un atacante puede superar el SPF mientras suplantaba la dirección «De» visible. Se necesita DMARC —que comprueba la coherencia entre los resultados de SPF/DKIM y el encabezado «De»— para evitar la suplantación del nombre de visualización.

¿Qué ocurre cuando falla el SPF?

Depende del calificador SPF y de si DMARC está configurado. Con -all y una política de rechazo de DMARC, el correo electrónico se bloquea. Con ~all y sin DMARC, el correo electrónico puede llegar a entregarse, pero se marcará como sospechoso. Sin SPF, los destinatarios no tienen ninguna señal SPF que evaluar.

¿Cómo puedo comprobar mi registro SPF?

Utiliza una herramienta gratuita herramienta de búsqueda de SPF. Introduzca su dominio y la herramienta recuperará su registro SPF del DNS, validará la sintaxis, contará las consultas DNS y señalará cualquier error, incluidas las infracciones de PermError y de consultas nulas.

¿Necesito SPF si ya tengo DKIM y DMARC?

Sí. DMARC exige que al menos uno de los dos, SPF o DKIM, supere la comprobación y cumpla con los requisitos de alineación. Aunque DKIM por sí solo puede satisfacer los requisitos de DMARC, contar con ambos (SPF y DKIM) proporciona redundancia. Si uno falla (por ejemplo, si SPF deja de funcionar al reenviar el correo), el otro puede seguir cumpliendo con la alineación de DMARC.

¿Qué es la alineación del FPS?

La coincidencia de SPF significa que el dominio del campo «Return-Path» (remitente del sobre) coincide con el dominio del encabezado «From». DMARC comprueba esta coincidencia. Sin ella, SPF puede pasar la comprobación, pero DMARC seguirá fallando, que es lo que ocurre con muchos remitentes externos, a menos que estén configurados para utilizar tu dominio en el campo «Return-Path».

¿Con qué frecuencia debo actualizar mi registro SPF?

Revisa tu registro SPF cada vez que añadas o elimines un servicio de envío, y audítalo al menos una vez al trimestre. Los registros SPF pierden validez a medida que los proveedores cambian los rangos de IP y que la infraestructura de envío de tu organización evoluciona. Un registro SPF que era válido hace seis meses puede estar dañado o incompleto hoy en día.

¿Qué es el «SPF flattening»?

La conversión a SPF resuelve todos , incluyendo: en direcciones IP sin procesar, lo que reduce el número de consultas DNS. Esto te permite mantenerte por debajo del límite de 10 consultas, pero crea un registro estático que debe actualizarse cada vez que un proveedor cambie sus direcciones IP. Las alternativas modernas, como las macros SPF, mantienen el registro dinámico sin superar el límite.

• Acerca de
• Últimas publicaciones

Ahona Rudra

Experto en seguridad de dominios y correo electrónico de PowerDMARC

Ahona es la Directora de Marketing de PowerDMARC, con más de 5 años de experiencia escribiendo sobre temas de ciberseguridad, especializada en seguridad de dominios y correo electrónico. Ahona tiene un posgrado en Periodismo y Comunicaciones, consolidando su carrera en el sector de la seguridad desde 2019.

Últimas publicaciones de Ahona Rudra (ver todas)

• Política antiphishing de Office 365: cómo configurarla - 3 de junio de 2026
• Seguridad de los agentes de IA: riesgos, buenas prácticas y autenticación del correo electrónico - 2 de junio de 2026
• PowerDMARC ya se integra con HaloPSA - 1 de junio de 2026