¿Qué es «SPF Include»? Cómo utilizarlo de forma segura en tu registro SPF
por
Última actualización: 12 minutos de lectura
Puntos clave
- El mecanismo SPF autoriza a los remitentes externos haciendo referencia al registro SPF de su dominio dentro del tuyo, lo que elimina la necesidad de enumerar manualmente todas las direcciones IP de envío.
- Cada instrucción «include» genera al menos una consulta DNS adicional. Si se supera el límite de 10 consultas, se produce un PermError que hace que el SPF falle para todos los remitentes, incluidos los legítimos.
- SPF solo admite DMARC cuando el dominio del sobre coincide con el dominio del campo «De». El hecho de que una comprobación SPF dé resultado positivo no garantiza automáticamente que se cumplan los requisitos de alineación de DMARC.
- Los equipos de TI y seguridad de las empresas que gestionan múltiples plataformas SaaS, regiones y dominios necesitan un flujo de trabajo de revisión estructurado para mantener los registros SPF dentro de los límites de consulta a medida que se incorporan nuevos remitentes.
- En el caso de los MSP y los MSSP, los problemas relacionados con SPF INCLUDE se extienden rápidamente por los entornos de los clientes, por lo que la supervisión centralizada es la que permite detectar los registros erróneos antes de que provoquen fallos en la entrega.
Respuesta rápida: El mecanismo «include» de SPF permite al propietario de un dominio autorizar a un remitente externo haciendo referencia al registro SPF de dicho remitente dentro de su propio registro TXT de DNS. Cuando un servidor receptor evalúa tu registro SPF y encuentra una instrucción «include», recupera y evalúa el registro SPF del dominio al que se hace referencia como parte de la comprobación. Dado que cada instrucción «include» desencadena al menos una consulta DNS adicional, debes mantener el número total de mecanismos de consulta DNS en 10 o menos para evitar un PermError.
Tu registro SPF indica a los servidores de correo receptores qué fuentes están autorizadas a enviar correos electrónicos en nombre de tu dominio. Cuando tu organización empieza a utilizar plataformas de terceros para el marketing, los mensajes transaccionales, las actualizaciones de CRM o los correos electrónicos de asistencia, la gestión del SPF se vuelve más difícil de mantener de forma manual. Ahí es donde resulta útil el mecanismo «SPF include».
Esta guía explica en detalle qué es una inclusión de SPF, cómo funciona y cómo gestionar varias inclusiones sin que se rompa tu registro. También aborda cómo mantener todo en consonancia con DMARC, para que tus correos electrónicos lleguen siempre a la bandeja de entrada.
¿Quién debe conocer el concepto de «SPF Include»?
El SPF es fundamental para los equipos de TI, los administradores de sistemas, los asesores de ciberseguridad y proveedores de servicios gestionados (MSP) que gestionan dominios que envían correo electrónico a través de múltiples servicios de terceros. Si su organización utiliza plataformas como un CRM, un servicio de asistencia técnica, una herramienta de automatización de marketing, un proveedor de correo electrónico transaccional o un servicio de correo en la nube, es probable que su registro SPF dependa de uno o varios mecanismos de inclusión.
- Equipos de TI y seguridad de empresas que gestionan múltiples plataformas SaaS, remitentes regionales o carteras de dominios
- Administradores de sistemas responsables de los registros DNS y de la entrega de correo electrónico
- Proveedores de servicios de seguridad gestionados (MSP) y proveedores de servicios de seguridad gestionados (MSSP) que gestionan SPF y DMARC en múltiples dominios de clientes
- Asesores en ciberseguridad en sectores regulados, como el financiero, el sanitario, el minorista y el sector público
¿Qué es un registro SPF?
Un registro SPF, o Sender Policy Framework , es un registro TXT del DNS que enumera todos los servidores y direcciones IP autorizados para enviar correo electrónico en nombre de un dominio concreto. Cuando llega un correo electrónico, el servidor de correo receptor comprueba los registros DNS del remitente para verificar que el correo procede de una fuente autorizada. Si la dirección IP del remitente coincide con una entrada del registro, el SPF se supera. Si no es así, el SPF falla.
Lo que los registros SPF no pueden hacer por sí solos
Los mecanismos del SPF son fundamentales, pero tienen algunas limitaciones que conviene conocer:
- Valida el remitente del sobre, no la dirección «De» que ven realmente los destinatarios
- Se interrumpe durante el reenvío de correos electrónicos, por lo que los correos reenviados suelen fallar la verificación SPF incluso cuando el remitente original es legítimo
- Por sí solo, no puede evitar la suplantación de dominio a nivel del encabezado «From», que es donde la mayoría de los ataques de phishing se dirigen a los destinatarios
Por eso, el SPF funciona mejor como parte de una configuración de autenticación más amplia que también incluya DKIM y DMARC. La configuración conjunta de estos tres protocolos ofrece el mayor nivel de protección del correo electrónico.
¿Qué incluye el SPF?
Si los registros SPF son el conjunto de normas que determinan quién puede enviar correo electrónico desde tu dominio, el mecanismo «SPF include» es la forma de incorporar las normas establecidas por terceros. Permite al propietario de un dominio delegar la autoridad de envío a otro dominio haciendo referencia al registro SPF de ese dominio dentro del suyo propio. En lugar de enumerar manualmente todas las direcciones IP utilizadas por un servicio de correo electrónico de terceros, se incluye su dominio, y el servidor receptor recupera y evalúa su registro SPF como parte del tuyo propio.
¿Por qué existe la instrucción «include» en SPF?
Hoy en día, el envío de correos electrónicos rara vez se realiza desde un único servidor. Para los equipos de TI y seguridad de las empresas, la complejidad del SPF suele aumentar a medida que, con el tiempo, se van incorporando nuevas herramientas SaaS, plataformas de marketing regionales, sistemas CRM, servicios de asistencia técnica y servicios de correo electrónico transaccional. Cada nuevo remitente debe autorizarse correctamente, supervisarse de forma continua y mantenerse dentro del límite de 10 consultas DNS del SPF para evitar fallos de autenticación y problemas de entrega.
El mecanismo «include» de SPF resuelve este problema al permitirte hacer referencia directamente al registro SPF del servicio de terceros. Cuando el servidor receptor evalúa tu registro SPF y encuentra una instrucción «include», recupera y resuelve el registro TXT SPF de ese dominio externo como parte del proceso de validación. Si la política SPF del dominio incluido da como resultado «aprobado» para la dirección IP remitente, el mecanismo «include» coincide y la evaluación SPF se considera superada para ese remitente. De lo contrario, el servidor receptor continúa evaluando el resto de tu registro SPF.
Cómo se aplica en la práctica el SPF
Una declaración «include» básica en SPF tiene este aspecto:
| v=spf1 include:thirdpartydomain.com ~all |
En este ejemplo, el servidor receptor consulta el registro SPF de thirdpartydomain.com y lo evalúa junto con el resto de tus registros. Si la IP remitente está autorizada en dicho registro, el correo electrónico supera la verificación SPF de tu dominio. El mecanismo «include» es indispensable para los dominios que externalizan el envío de correo electrónico o que recurren a varios proveedores, ya que la alternativa consistiría en enumerar manualmente todas las direcciones IP utilizadas por cada servicio, lo cual resulta poco práctico y propenso a errores.
¿Cómo funciona el mecanismo de inclusión del SPF?
Comprender el mecanismo «include» de SPF a nivel técnico te ayuda a evitar los errores de configuración que provocan que SPF falle de forma silenciosa. Esto es lo que ocurre cuando un servidor receptor evalúa un registro SPF que contiene declaraciones «include».
El proceso de validación del SPF
- Cuando un correo electrónico llega a un servidor de correo receptor, el servidor extrae el dominio de la dirección «MAIL FROM» y realiza una búsqueda en el DNS para recuperar el registro TXT SPF de ese dominio. A continuación, lee el registro de izquierda a derecha, evaluando cada mecanismo hasta que encuentra una coincidencia o llega al final. Cuando se encuentra con una instrucción «include»:
- El servidor receptor realiza una consulta DNS adicional para obtener el registro TXT de SPF del dominio incluido.
- Comprueba si el registro SPF del dominio incluido coincide con la dirección IP de envío.
- Si la política SPF del dominio incluido devuelve un resultado de «aprobado» para la IP remitente, el mecanismo de inclusión se cumple y la evaluación SPF puede dar resultado positivo para ese remitente.
- Si no se encuentra ninguna coincidencia, el servidor continúa evaluando los mecanismos restantes del registro original.
¿Cómo se contabilizan las consultas en el límite de búsquedas DNS?
Cada instrucción «include» de un registro SPF genera al menos una consulta DNS adicional. Esto es importante porque la validación SPF está limitada a un máximo de diez consultas DNS por comprobación. Cada instrucción «include», junto con mecanismos como «mx» y «a», cuenta para este límite. Si el propio registro SPF del dominio incluido contiene a su vez más instrucciones «include», estas también cuentan, creando una cadena de consultas que puede acumularse rápidamente.
Si se supera el límite de diez consultas, el SPF devuelve un «PermError», que los servidores receptores interpretan como un fallo de SPF. Esto puede dar lugar a que los correos electrónicos sean rechazados o acaben en las carpetas de spam, incluso cuando el remitente sea totalmente legítimo.
Sintaxis de los registros SPF: cómo escribir correctamente una inclusión SPF
Es imprescindible que la sintaxis sea correcta. Un solo error en tu sintaxis del registro SPF puede hacer que todo el registro falle, independientemente de lo bien que esté configurado el resto.
La estructura básica de un registro SPF
| v=spf1 [mecanismos] [calificador:todos] |
- v=spf1 declara la versión de SPF y debe aparecer al principio de cada registro TXT de SPF
- mecanismos definen las fuentes de envío autorizadas, que pueden incluir direcciones IP, dominios mediante «include», registros MX y otros elementos
- «all» es el mecanismo genérico que determina qué ocurre con los correos electrónicos que no coinciden con ninguna fuente de la lista
Resumen de los criterios de clasificación del SPF
| Calificador | Significado | Ejemplo |
|---|---|---|
| + (por defecto) | Aceptado, el remitente está autorizado | +todo o incluir: |
| - | Error, el remitente no está autorizado; rechazar | -todos |
| ~ | Softfail: se señala, pero normalmente se entrega | ~todos |
| ? | Neutro, sin política definida | ?todos |
Cómo escribir correctamente una instrucción «include» en un SPF
La sintaxis correcta para una instrucción «include» es «include:domain.com». Ten en cuenta que no debe haber ningún espacio entre «include» y los dos puntos. Un espacio provoca un error de sintaxis. A continuación se muestra un ejemplo completo de un registro SPF con varias inclusiones:
| v=spf1 include:sendgrid.net include:mailchimp.com ip4:192.168.1.1 ~all |
- sendgrid.net y mailchimp.com están autorizados como remitentes externos mediante la función «include»
- 192.168.1.1 es una dirección IP autorizada individualmente
- ~«all» es un «softfail», lo que significa que los correos electrónicos procedentes de fuentes no autorizadas se marcan, pero no se rechazan directamente
Lista de comprobación: cómo añadir de forma segura una nueva inclusión SPF
- Identifica el nuevo servicio de envío y confirma el dominio de inclusión facilitado por el proveedor.
- Consulta tu registro TXT de SPF actual utilizando una herramienta de búsqueda de SPF.
- Cuenta el número total de consultas DNS, incluidas las consultas anidadas dentro de los registros incluidos.
- Añade el nuevo mecanismo «include:» a tu único registro TXT de SPF.
- Valida la sintaxis con un generador de registros SPF o una herramienta de consulta.
- Publica el registro actualizado y comprueba los resultados de la autenticación a través de los encabezados de los correos electrónicos.
- Supervisa los informes DMARC para comprobar que el nuevo remitente cumple con la alineación SPF.
SPF «Include» frente a «Redirect»: ¿cuál es la diferencia?
Tanto el mecanismo «include» como el modificador «redirect» hacen referencia al registro SPF de otro dominio, pero su comportamiento es muy diferente. Utilizar uno cuando se necesita el otro es un error de configuración habitual que puede provocar fallos en la autenticación sin que el usuario se dé cuenta.
El mecanismo «include» autoriza a los remitentes que figuran en el registro SPF de otro dominio, al tiempo que permite que tu registro SPF contenga mecanismos adicionales. El modificador «redirect», por el contrario, indica al servidor receptor que utilice el registro SPF de otro dominio como política completa para tu dominio, sustituyendo todo lo demás en tu registro.
| Mecanismo / Modificador | Qué hace | Se recomienda su uso cuando | Ejemplo |
|---|---|---|---|
| incluye | Añade los remitentes autorizados de otro dominio a tu política, al tiempo que mantiene tus propios mecanismos | Quieres autorizar a un remitente externo sin desactivar tu propia política SPF | incluir:sendgrid.net |
| redirigir | Sustituye toda tu política SPF por el registro SPF del dominio al que se hace referencia | Quieres que el registro SPF de otro dominio sirva como única política para tu dominio | redirect=example.com |
| IPv4 / IPv6 | Autoriza directamente una dirección IP o un rango de direcciones IP concretos; sin consulta al DNS | El rango de direcciones IP de un remitente es estático y está bien documentado | IPv4: 203.0.113.0/24 |
| a | Autoriza las direcciones IP del registro A del dominio actual; una consulta DNS | Tu servidor web también envía correos electrónicos | a |
| mx | Autoriza las direcciones IP de los registros MX del dominio; una consulta DNS | Tu servidor de correo entrante también envía correos electrónicos salientes | mx |
Error habitual
Uso conjunto de «include» y «redirect» en el mismo registro. El modificador «redirect» se ignora siempre que aparece un mecanismo «all» en el registro, por lo que ambos no se combinan como cabría esperar. En la mayoría de las configuraciones con varios remitentes, «include» es la opción correcta y «redirect» se omite por completo.
Errores sintácticos habituales que hay que evitar
- Publicar más de un registro TXT de SPF para el mismo dominio, lo que provoca un PermError, ya que los servidores receptores no pueden determinar qué política deben aplicar
- Añadir un espacio después de los dos puntos en una instrucción «include»
- El uso de calificadores incorrectos o de mecanismos que entran en conflicto entre sí
- Olvidarse de finalizar la grabación con un comando «all»
Un generador de registros SPF crea un registro con el formato correcto desde cero; también puedes introducir tu registro actual en una herramienta de consulta de SPF para detectar posibles errores antes de que provoquen problemas de entrega.
Comparación de los mecanismos del SPF: «include» frente a «a», «mx», «ip4», «ip6» y «all»
Antes de editar un registro TXT de DNS, conviene saber qué mecanismo SPF utilizar y en qué casos. Cada mecanismo tiene una finalidad distinta y un impacto diferente en el número de consultas de DNS.
| Mecanismo | Qué autoriza | ¿Búsqueda de DNS? | Mejor caso de uso | Error habitual |
|---|---|---|---|---|
| incluye | Remitentes autorizados en el registro SPF de otro dominio | Sí, al menos uno por inclusión, además de las búsquedas anidadas. | Autorización de remitentes externos, como proveedores de servicios de correo electrónico (ESP) y sistemas de gestión de relaciones con los clientes (CRM) | Añadir demasiadas llamadas a «include» y superar el límite de 10 consultas |
| a | Direcciones IP resueltas a partir del registro A del dominio | Sí, 1 búsqueda | Cuando tu servidor web envía un correo electrónico | Se confunde con IPv4; requiere una consulta al DNS |
| mx | Direcciones IP de los registros MX del dominio | Sí, una consulta por cada registro MX | Cuando tu servidor de correo entrante también envía correos electrónicos salientes | Subestimar el número de consultas MX que se tienen en cuenta |
| IPv4 / IPv6 | Una dirección IPv4 o IPv6 concreta o un rango CIDR | No | Remitentes con rangos de IP fijos y bien documentados | Utilizarlo cuando el proveedor cambia las direcciones IP, lo que provoca que los registros queden obsoletos |
| todo | Categoría genérica para cualquier dirección IP que no se haya identificado anteriormente | No | Debe aparecer al final de cada registro SPF | Omitirlo o situarlo antes que otros mecanismos |
| redirigir | Delega toda la política de SPF a otro dominio | Sí, 1 búsqueda | Centralizar la gestión de políticas en un único dominio de referencia | Si se utiliza con todos los elementos en el mismo registro, se ignora la redirección. |
Reglas de inclusión múltiple de SPF y límites de consultas DNS
El uso de varias inclusiones SPF es habitual y, a menudo, necesario, pero introduce una complejidad que hay que gestionar con cuidado. A continuación te explicamos lo que debes saber sobre cómo gestionar un registro SPF con varias inclusiones.
¿Por qué son necesarias varias inclusiones?
La mayoría de las organizaciones envían correos electrónicos a través de más de una plataforma. Una configuración típica incluye un servidor de correo principal para el correo interno y saliente, un servicio de correo transaccional para confirmaciones de pedidos y notificaciones, una plataforma de marketing para boletines informativos y campañas, y una herramienta de CRM o de atención al cliente para las comunicaciones con los clientes. Cada una de ellas debe estar autorizada en tu registro SPF, y la forma más práctica de hacerlo es mediante sentencias «include» que hagan referencia al registro SPF de cada proveedor.
Por qué los MSP deben supervisar minuciosamente el SPF
Para los MSP y los MSSP, los problemas relacionados con el SPF se extienden rápidamente por los entornos de los clientes. Un cliente puede añadir una nueva herramienta de marketing por correo electrónico, otro puede cambiar de CRM y un tercero puede publicar, sin saberlo, varios registros SPF. Sin una visibilidad centralizada, estos cambios suelen convertirse en incidencias de soporte técnico solo cuando el envío de correos electrónicos empieza a fallar. Una plataforma centralizada de gestión de SPF y DMARC ayuda a los MSP a identificar registros erróneos, inclusiones en desuso, riesgos de superación del límite de consultas y fallos de autenticación en todos los dominios de los clientes desde un único panel de control, lo que reduce la necesidad de resolver problemas de forma reactiva.
Por qué la inclusión de varios archivos SPF puede superar el límite de 10 consultas
Cada instrucción «include» activa al menos una consulta DNS, y algunos registros SPF de terceros contienen a su vez más instrucciones «include», lo que añade aún más consultas. Para cuando hayas autorizado cuatro o cinco plataformas, es posible que ya te estés acercando al límite de diez consultas o que lo hayas superado. Cuando se supera el límite, el servidor receptor devuelve un PermError y trata el correo electrónico como un fallo de autenticación SPF.
Ejemplo: cómo las inclusiones visibles superan las 10 consultas totales
| Mecanismo en tu expediente | Búsquedas directas | Búsquedas anidadas típicas | Total acumulado |
|---|---|---|---|
| incluir:_spf.google.com | 1 | 2 | 3 |
| incluir:sendgrid.net | 1 | 2 | 6 |
| incluye: salesforce.com | 1 | 1 | 8 |
| mx | 1 | 1 | 10 |
| incluyen: mailchimp.com (añadido posteriormente) | 1 | 1 | 12, se ha activado PermError |
Tres inclusiones visibles pueden convertirse fácilmente en más de diez consultas en total si se cuentan las inclusiones anidadas dentro de los registros a los que se hace referencia.
¿Cuántos SPF puede incluir un registro SPF?
No existe un límite estricto en cuanto al número de instrucciones «include» que se pueden escribir en un registro SPF. Sin embargo, el conjunto de todos los mecanismos de consulta DNS —incluidos «include», «a», «mx», «exists» y «redirect»— no debe generar más de 10 consultas DNS en total durante la evaluación. Este límite incluye las consultas anidadas dentro de los registros incluidos.
En la práctica, la mayoría de los dominios pueden utilizar sin problemas entre tres y cinco instrucciones «include» antes de acercarse al límite, dependiendo del número de búsquedas anidadas que desencadene cada registro al que se hace referencia. Añadir una sexta o séptima instrucción «include» para un proveedor cuyo propio registro SPF contenga múltiples «includes» anidados puede hacer que el total supere los 10 y provoque un PermError, aunque el registro visible parezca corto. Una herramienta de aplanamiento de SPF cuenta el total de consultas y resuelve las cadenas de «include» antes de que publiques cualquier cambio en el registro.
Cómo no superar el límite de consultas DNS
- Revisa tu registro SPF actual y calcula el número total de consultas DNS que genera, incluidas las consultas anidadas dentro de los registros incluidos
- Elimina cualquier instrucción «include» correspondiente a servicios que ya no utilices
- Siempre que sea posible, sustituya los mecanismos de inclusión por entradas IPv4 o IPv6 directas para los servicios cuyos rangos de IP sean estáticos y estén bien documentados
- Uso el aplanamiento de SPF para resolver automáticamente las cadenas de inclusión y sustituirlas por direcciones IP directas, reduciendo así el número total de consultas
- Revisa tu historial cada vez que añadas o elimines una plataforma de envío
Un registro SPF por dominio, siempre
Una regla fundamental que se aplica independientemente del número de inclusiones que gestiones: nunca publiques más de un registro TXT de SPF para el mismo dominio o subdominio. La existencia de varios registros SPF provoca un error «SPF PermError», ya que los servidores receptores no pueden determinar qué política aplicar, por lo que todo debe consolidarse en un único registro. Si realizas envíos desde subdominios, cada subdominio debe tener su propio registro TXT de SPF independiente.
Ejemplos de SPF para configuraciones habituales de envío de correo electrónico
Los siguientes ejemplos ilustran la sintaxis correcta de la inclusión de SPF para configuraciones multiplataforma habituales. Comprueba siempre el dominio de inclusión exacto en la documentación de tu proveedor antes de publicarlo y valida cualquier nuevo registro con una herramienta de consulta de registros SPF antes de publicarlo en el DNS.
Solo un proveedor de correo electrónico
| v=spf1 include:_spf.google.com ~all |
Proveedor de correo electrónico y servicio de correo electrónico transaccional
| v=spf1 include:_spf.google.com include:sendgrid.net ~all |
Proveedor de correo electrónico, plataforma de marketing y CRM (fíjate en el número de búsquedas)
| v=spf1 include:_spf.google.com include:sendgrid.net include:mailchimp.com ip4:203.0.113.10 ~all |
Ejemplos no válidos
Dos registros que darán error, con el motivo:
| v=spf1 include: sendgrid.net ~all <- INCORRECT (space after colon) v=spf1 include:sendgrid.net <- INCORRECT (missing all mechanism) |
Errores habituales con el SPF y cómo evitarlos
Los registros SPF son potentes, pero implacables. Un solo error de configuración puede provocar fallos de autenticación en todo tu flujo de correo electrónico, y lo más frustrante es que muchos de estos errores no generan un mensaje de error evidente. Tanto si estás configurando el SPF por primera vez como si estás revisando un registro ya existente, estos son los errores a los que debes prestar atención.
| Error | ¿Qué pasa? | Cómo evitarlo |
|---|---|---|
| Publicación de varios registros TXT de SPF para un dominio | SPF falla inmediatamente con un PermError, independientemente del contenido. | Consolida todo en un único registro TXT de SPF por dominio o subdominio |
| Se ha superado el límite de diez consultas DNS | Los servidores receptores devuelven un PermError y consideran el correo electrónico como un error de SPF | Realiza auditorías periódicas, elimina los archivos «include» que no se utilicen y aplica el «SPF flattening» cuando sea necesario. |
| No se actualiza el SPF al añadir nuevos remitentes | Los correos electrónicos enviados a través de la nueva plataforma no superan la autenticación SPF | Actualiza tu registro SPF cada vez que incorpores un nuevo proveedor de servicios de correo electrónico |
| Ignorar los requisitos de los subdominios | Los correos electrónicos procedentes de subdominios no superan la verificación SPF porque el registro principal no los incluye | Publica un registro TXT de SPF independiente para cada subdominio de envío. |
| Sintaxis incorrecta, como espacios después de los dos puntos | Todo el registro deja de ser válido y el SPF falla para todos los remitentes | Comprueba que tus datos sean correctos con una herramienta de búsqueda cada vez que realices un cambio. |
| Incluir los servicios que ya no utilizas | Las consultas innecesarias agotan tu cupo de consultas DNS | Revisa periódicamente las plataformas incluidas y elimina aquellas a las que ya no envías contenido. |
| Suponiendo que el SPF cubra el DMARC automáticamente | Es posible que SPF se supere, pero DMARC seguirá fallando si el dominio del sobre no coincide | Configura la alineación DKIM como opción alternativa y revisa los ajustes de alineación de DMARC |
| Uso de «include» cuando se pretendía realizar una redirección | La política se comporta de forma diferente a lo esperado; tus propios mecanismos permanecen activos | Antes de editar, es importante comprender la diferencia entre «include» y «redirect». |
| Incluir declaraciones «include» duplicadas | Desperdicia consultas DNS y puede hacer que el registro supere el límite | Cada dominio incluido debe aparecer solo una vez en tu registro. |
Resultados de la evaluación del SPF: Aprobado, Suspendido, Fallo leve, Neutro, Error temporal y Error permanente
Entender qué significa cada resultado de SPF te ayuda a diagnosticar rápidamente los fallos de autenticación. La tabla siguiente recoge todos los resultados que un servidor receptor puede devolver tras evaluar un registro SPF.
| Resultado | Significado | Causa Común | Acción recomendada |
|---|---|---|---|
| Pasar | Se autoriza la dirección IP de origen | La dirección IP coincide con un mecanismo autorizado en el registro | No es necesario realizar ninguna acción; comprueba la alineación de DMARC |
| Falla | El envío desde esta dirección IP no está autorizado de forma explícita; el correo electrónico debe rechazarse. | La dirección IP no coincide y el registro termina con «-all» | Añade la dirección «include» o la IP del remitente al registro |
| Softfail | Es probable que la dirección IP de origen no esté autorizada; no obstante, es posible que el correo electrónico se entregue | La dirección IP no coincide y el registro termina con ~all | Revisa los remitentes que faltan; plantéate cambiarlos a -all cuando estés seguro |
| Neutral | No hay ninguna declaración de política sobre la dirección IP de origen | El registro termina con el mecanismo «todo o nada». | Establece una política clara; añade «~all» o «-all» |
| Ninguno | No se ha encontrado ningún registro SPF para el dominio | Falta el registro TXT de SPF en el DNS | Crear y publicar un registro TXT de SPF con un generador |
| Error de temperatura | Se ha producido un error temporal durante la evaluación; inténtalo más tarde. | Tiempo de espera de DNS agotado o fallo transitorio de DNS | Supervisa si se repiten los problemas; comprueba la fiabilidad del proveedor de DNS |
| PermError | Error permanente; no se puede completar la evaluación del SPF | Error de sintaxis, varios registros SPF o más de 10 consultas DNS | Corrige la sintaxis, consolida registros o reduce las consultas mediante la simplificación |
Inclusión de SPF y cumplimiento de DMARC
Los SPF no funcionan de forma aislada. La forma en que los configures tiene un impacto directo en tu cumplimiento de DMARC, y comprender la relación entre ambos es esencial para mantener una capacidad de entrega constante.
En sectores regulados como el financiero, el sanitario, el educativo, el minorista y el sector público, la inclusión de la «higiene» en el SPF no es solo una cuestión relacionada con la entregabilidad. Respalda requisitos más amplios de autenticación del correo electrónico vinculados a las normas de remitentes de Google y Yahoo, las expectativas de autenticación de Microsoft y la norma PCI DSS, los controles de seguridad alineados con el RGPD y los programas internos de gestión de riesgos.
Cómo se integra SPF en DMARC
DMARC se basa en SPF y DKIM para ofrecer a los propietarios de dominios control sobre cómo se gestionan sus correos electrónicos cuando falla la autenticación. Para que un correo electrónico supere la verificación DMARC, debe cumplirse al menos una de las siguientes condiciones:
- El SPF se valida y el dominio del remitente coincide con el dominio del campo «De»
- La verificación DKIM es correcta y el dominio de firma DKIM coincide con el dominio del remitente
Esto significa que ni siquiera un registro SPF configurado correctamente, con todas las inclusiones adecuadas, es suficiente por sí solo. La alineación SPF también debe ser correcta, lo que implica que el dominio de la ruta de retorno debe coincidir con el dominio «De» según tu configuración de alineación DMARC.
Cómo afecta la inclusión de SPF a la alineación
Cuando un remitente externo utiliza su propio dominio en la ruta de retorno, es posible que su «include» figure en tu registro SPF y que, técnicamente, el SPF se supere para su dominio, pero no coincidirá con tu dominio «From». En este caso, DMARC seguirá fallando en la comprobación de SPF. Configurar el servicio externo para que utilice una ruta de retorno personalizada bajo tu dominio, o asegurarte de que la alineación DKIM como medida de respaldo es esencial.
Por qué el SPF por sí solo no es suficiente
SPF, DKIM y DMARC están diseñados para funcionar conjuntamente como elementos fundamentales de seguridad del correo electrónico . SPF valida el origen del envío, pero deja de funcionar durante el reenvío. DKIM firma el propio mensaje y sigue funcionando tras el reenvío. DMARC combina ambos y te ofrece visibilidad y control sobre lo que ocurre cuando alguno de ellos falla. Configurar los tres es la única forma de crear un sistema de autenticación de correo electrónico resistente.
Configuración de DMARC junto con SPF
Si tienes tus entradas SPF configuradas correctamente pero aún no has implementado DMARC, configurar DMARC es el siguiente paso lógico. Empieza con una política de p=none para supervisar tus flujos de correo electrónico sin afectar a la capacidad de entrega; después, pasa a la cuarentena y al rechazo a medida que aumente tu confianza en tu configuración de autenticación.
Gestiona las inclusiones SPF y la alineación DMARC con PowerDMARC
La gestión de las inclusiones SPF se complica cuando tu organización utiliza múltiples remitentes externos en distintos departamentos, dominios y regiones. Una sola inclusión no utilizada, una cadena de búsqueda anidada o un dominio de ruta de retorno desalineado pueden provocar errores de autenticación difíciles de detectar manualmente.
PowerDMARC ofrece a los equipos de TI, a los responsables de seguridad y a los MSP una visión centralizada de los resultados de SPF, DKIM y DMARC en todas las fuentes de envío. Con la gestión automatizada de SPF, la generación de informes DMARC, análisis de SPF, servicios de autenticación alojados y asistencia especializada, los equipos pueden evitar fallos por exceso de consultas SPF, identificar remitentes no autorizados y mantener el cumplimiento normativo con una menor carga de trabajo en el DNS.
Las organizaciones utilizan PowerDMARC para centralizar la gestión del SPF, supervisar los errores de autenticación e identificar las fuentes de envío no autorizadas antes de que afecten a la capacidad de entrega.
Preguntas frecuentes
¿Cuántos SPF puedo tener?
No hay un límite fijo para las instrucciones «include», pero el total de consultas DNS no debe superar las 10, contando las consultas anidadas dentro de los registros a los que se hace referencia. La mayoría de los dominios pueden gestionar entre tres y cinco instrucciones «include» sin problemas antes de que sea necesario aplanar la estructura.
¿Cuál es la diferencia entre «include» y «redirect»?
«include» añade los remitentes de otro dominio, al tiempo que mantiene activos tus propios mecanismos. «redirect» sustituye toda tu política por el registro de otro dominio. «redirect» se ignora si existe un mecanismo «all», por lo que ambos no se combinan.
¿Por qué mi SPF pasa la comprobación pero DMARC sigue fallando?
El SPF puede hacer que parezca que el mensaje procede del propio dominio de un remitente externo, sin que coincida con tu dominio «De». DMARC requiere que haya coincidencia, así que configura una ruta de retorno personalizada bajo tu dominio o utiliza la coincidencia de DKIM como alternativa.
¿Qué provoca un error «PermError» de SPF?
Tres causas habituales: superar el límite de 10 consultas, publicar más de un registro SPF para un dominio o un error de sintaxis, como un espacio después de «include:». Las tres causas provocan que el SPF falle para todos los remitentes hasta que se solucionen.
¿Puedo tener un único registro SPF para varios subdominios?
No. Cada subdominio de envío necesita su propio registro TXT de SPF. El registro del dominio principal no cubre los subdominios, por lo que el correo procedente de un subdominio sin configurar no supera la verificación SPF.
¿Cómo puedo reducir el número de consultas al SPF?
Elimina las inclusiones de los servicios que no se utilicen, sustituye los remitentes con IP estática por entradas directas de IPv4 o IPv6, y utiliza el «SPF flattening» para resolver las cadenas de inclusión en direcciones IP directas. Realiza una auditoría cada vez que se añada o se elimine una plataforma de envío.
¿La incorporación de una llamada a un archivo de inclusión tiene un efecto inmediato en el correo electrónico?
Solo una vez que se haya completado la propagación del DNS, lo que puede tardar hasta 48 horas. Comprueba el registro con una herramienta de búsqueda antes de publicarlo y, a continuación, confirma que el nuevo remitente cumple con la alineación SPF en tus informes DMARC.
Yunes es jefe de equipo de operaciones en PowerDMARC con conocimientos especializados en autenticación y seguridad del correo electrónico. Yunes es Administrador Asociado de Azure certificado por Microsoft y cuenta con certificaciones de CompTIA A+ y muchas más.
Últimos mensajes de Yunes Tarada (ver todos)
- Guía de configuración de DKIM, DMARC y SPF de TinkMail - 19 de agosto de 2026
- Guía de configuración de DKIM, DMARC y SPF en PandaDoc - 19 de agosto de 2026
- Guía de configuración de DKIM, DMARC y SPF de Moloni - 18 de agosto de 2026
