¿Puedo tener varios registros SPF en un mismo dominio?

¿Se pueden tener varios registros SPF en un mismo dominio?

En el caso del mismo nombre de host, no. Un dominio solo debe publicar un registro SPF por nombre de host. El RFC 7208 establece que un nombre de dominio no debe tener varios registros que puedan dar lugar a que una comprobación de autorización seleccione más de un registro . En la práctica, la presencia de varios registros SPF genera un error de «múltiples registros SPF», en lugar de un resultado válido de «SPF pasado» .

En este caso, la distinción entre subdominios es importante. «example.com» y «mail.example.com» pueden tener cada uno su propio registro TXT de SPF si envían correos electrónicos de forma independiente, ya que se trata de nombres DNS distintos. Sin embargo, example.com no debería publicar dos entradas TXT independientes del tipo « v=spf1» para el mismo host. Esa es la diferencia entre un dominio que utiliza un único registro y varios subdominios de que utilizan sus propios registros.

Sugerencia visual: Añada un diagrama sencillo de DNS en el que se muestre example.com con un registro SPF y mail.example.com con su propio registro SPF independiente, .

Problemas habituales derivados de la existencia de varios registros SPF

Los destinatarios no interpretan las políticas SPF duplicadas como una autorización adicional. Por lo general, los interpretan como un error . La RFC 7208 considera que los registros SPF múltiples no son válidos a efectos de evaluación y, en las comprobaciones reales, esto suele aparecer como «SPF PermError». Esto significa que el servidor receptor no puede considerar el SPF como un resultado de validación normal.

Ese error técnico tiene repercusiones en el negocio. Los correos electrónicos legítimos pueden marcarse como spam, filtrarse de forma más estricta o rechazarse. Con el tiempo, los registros duplicados pueden generar una carga administrativa adicional, reducir la capacidad de entrega del correo electrónico y perjudicar la reputación del remitente , ya que los problemas de autenticación recurrentes merman la confianza en el dominio.

¿Cómo se producen los registros SPF múltiples?

La causa más habitual es el cambio sin consolidación. Cuando un equipo incorpora Microsoft Exchange Online Protection, Google Workspace, Amazon SES, un CRM, una plataforma de asistencia técnica o un servicio de marketing, la guía de configuración del proveedor proporciona un nuevo ejemplo de registro SPF de . En lugar de integrar el nuevo mecanismo en el registro SPF existente « », alguien publica un registro SPF independiente.

Esto es especialmente habitual en las organizaciones más grandes, en las que la configuración del DNS la modifican distintos equipos y nadie se hace cargo de la autenticación del correo electrónic o de principio a fin. También se produce durante las fusiones, las migraciones y los cambios de proveedor, cuando los servicios antiguos y los nuevos de envían mensajes desde el mismo dominio al mismo tiempo. En esos casos, la existencia de varios registros suele reflejar una titularidad fragmentada más que una mala intención.

¿Cómo se manifiesta un error de registros SPF múltiples?

La señal más clara es un resultado «SPF PermError» en una comprobación de SPF, un verificador de SPF, el encabezado de un mensaje o una herramienta de análisis de autenticación . Otra señal evidente es una consulta DNS que muestre más de un registro TXT que comience por «v=spf1» para el mismo nombre de host . 

Desde el punto de vista operativo, el problema suele manifestarse como un fallo repentino del SPF tras la incorporación de un nuevo remitente. También es posible que observe problemas inexplicables en la clasificación de los mensajes en la bandeja de entrada , incluso cuando los remitentes en cuestión sean legítimos. Si no se produce ningún otro cambio, pero la capacidad de entrega de disminuye justo después de la puesta en marcha de una nueva plataforma, conviene comprobar en primer lugar si hay registros SPF duplicados. 

Sugerencia visual: Añada una captura de pantalla de una herramienta de verificación de SPF en la que se muestren dos entradas «v=spf1» y un resultado «SPF PermError».

¿Cómo se comprueba si un dominio tiene varios registros SPF?

Empiece por la capa DNS. Revise los registros TXT del dominio y compruebe si hay más de una entrada «v=spf1» en el nombre de host exacto utilizado para el envío. No dé por sentado que el dominio raíz es el único lugar que debe comprobar. Si el correo se envía desde un subdominio, realice también allí la consulta SPF de .

Esta comprobación es especialmente importante después de:

• Incorporación de Google Workspace, Microsoft 365, Amazon SES u otra plataforma de correo electrónico externa
• Migraciones de DNS o cambios de registrador
• Implementaciones de plataformas de seguridad u otras actualizaciones de la infraestructura de correo electrónico

Estos son los momentos en los que suelen producirse con mayor frecuencia los registros SPF duplicados.

¿Cómo se corrigen varios registros SPF?

La solución no consiste en seguir buscando el origen del problema en las entradas duplicadas. Se trata de reunir todo en una única política SPF válida para ese nombre de host y, a continuación, comprobar que funciona según lo previsto.

1. Recopile todos los registros SPF existentes. Recopile todos los registros TXT de SPF asociados al dominio y a cualquier subdominio relevante. Revise detenidamente su zona DNS y elabore una lista con todos los nombres de host en los que se ha publicado el SPF, de modo que pueda trabajar a partir de un inventario completo .
2. Revise todos los mecanismos y las inclusiones. Revise cada registro SPF e identifique las fuentes de envío que siguen siendo legítimas y que aún son necesarias. Compruebe cada entrada de tipo ip4, ip6, include, a y mx con sus sistemas de correo actuales y para confirmar si dicha fuente sigue enviando correo para el dominio.
3. Elimine las entradas obsoletas. Una vez que sepa qué fuentes son válidas, elimine todo aquello que ya no requier autorización. Elimine las plataformas en desuso, los mecanismos duplicados, los sistemas de prueba y los antiguos servicios de terceros que ya no forman parte de su flujo de correo.
4. Cree un registro SPF consolidado. Combine todas las fuentes de envío necesarias en una única política v=spf1 para ese nombre de host. Añada únicamente los mecanismos que aún necesite, colóquelos en un orden lógico y claro, y termine el registro con un calificador de « », como ~all o -all.
5. Valide el nuevo registro SPF. Antes de publicarlo en producción, ejecute una comprobación del registro SPF en para confirmar que la sintaxis es correcta, que el número de consultas se mantiene dentro de los límites y que el registro sigue cubriendo a todos los remitentes legítimos. Corrija cualquier error de sintaxis o de consulta antes de sustituir el registro activo.
6. Publique el registro SPF unificado y elimine los registros adicionales. Actualice el DNS para que solo quede la nueva política SPF consolidada para ese nombre de host. Elimine al mismo tiempo los registros TXT de SPF sobrantes, en lugar de dejarlos junto con el nuevo.
7. Compruebe que solo exista un registro SPF. Tras la publicación, revise de nuevo el conjunto de registros TXT de DNS y compruebe que solo se haya publicado un registro SPF para ese nombre de host. Si su proveedor de DNS muestra varias entradas TXT, compruebe con atención para asegurarse de que los registros SPF anteriores se hayan eliminado por completo.
8. Supervise la capacidad de entrega. Una vez que el registro unificado esté activo, supervise atentamente el flujo de correo para detectar errores de SPF, mensajes bloqueados, u otros problemas de autenticación. Revise los mensajes de devolución, los registros de correo o los resultados de autenticación para detectar remitentes que falten y corrija el registro si es necesario. 

El objetivo no es simplemente eliminar el error. El objetivo es disponer de un único registro SPF que sea válido, fácil de mantener y que esté alineado con todos los servicios de envío legítimos.

¿Cómo se fusionan correctamente varios registros SPF?

La fusión de registros SPF no consiste simplemente en combinar el texto en una sola línea. El objetivo es elaborar una política SPF clara y válida que abarque a todos los remitentes legítimos sin añadir una complejidad innecesaria.

Elabore una política clara sobre el SPF

Un registro SPF fusionado y ordenado combina mecanismos como ip4, ip6, a, mx e include en una única secuencia lógica; a continuación, termina con una política clara, como ~all o -all. Así es como debería quedar la fusión de los registros SPF. El objetivo es disponer de un único registro SPF que dé cuenta de todos los remitentes legítimos.

Evite la complejidad durante la fusión

Los mayores errores que se cometen durante la fusión son la duplicación y el exceso de complejidad. Evite los mecanismos duplicados o contradictorios, , y preste especial atención a las inclusiones múltiples, ya que cada consulta de DNS cuenta para el límite de consultas de DNS de SPF. En ocasiones se utiliza la técnica de «SPF flattening» ( ) para reducir ese número, pero incluso un registro SPF fusionado técnicamente válido puede resultar difícil de mantener si la titularidad de está fragmentada.

¿Cómo afectan los registros SPF múltiples a DMARC y a la capacidad de entrega?

El SPF no es un factor aislado. Cuando SPF devuelve un PermError, es posible que no pueda aportar un resultado SPF alineado y válido para un DMARC de tipo « ». Esto se agrava cuando falta, está dañado o no está correctamente configurado el DKIM, ya que, en ese caso, el destinatario dispone de menos señales de autenticación válidas en las que basar su confianza. 

En la práctica, los registros SPF duplicados pueden provocar el filtrado como spam, el riesgo de rechazo y una peor entrega en la bandeja de entrada. Los errores de autenticación repetidos también merman la confianza en el dominio remitente con el paso del tiempo, por lo que es importante contar con un sistema de informes DMARC más sólido: . Por eso se trata tanto de un problema de seguridad del correo electrónico como de un problema de entrega. Una herramienta de comprobación de registros DMARC de puede ayudar a diagnosticar la situación en su conjunto, pero sigue dependiendo de que los datos de autenticación SPF sean correctos. 

¿Qué ocurre cuando hay muchos remitentes pero solo un registro SPF?

El hecho de tener muchos remitentes no implica que necesite varios registros SPF. Un único registro SPF puede autorizar numerosas fuentes de envío mediante mecanismos como ip4, ip6, mx e include. Esa es la forma correcta de gestionar un dominio utilizando varios servicios de correo electrónico legítimos de al mismo tiempo.

La diferencia fundamental radica en si hay varios remitentes o varias políticas SPF. Una política SPF debe abarcar todos los servicios aprobados por , en lugar de publicar registros separados para el mismo nombre de host. Incluso tras la consolidación, la complejidad sigue generando riesgos. Un número excesivo de declaraciones «include» puede hacer que el registro se acerque al límite de 10 consultas DNS, y un registro que, desde el punto de vista técnico, sea válido puede llegar a ser difícil de mantener si la responsabilidad sobre él está repartida entre distintos equipos.

Prácticas recomendadas para una mejor gestión de los registros SPF

Los problemas relacionados con el SPF suelen tener menos que ver con la sintaxis y más con la responsabilidad y el control de los cambios. Una gestión diaria más eficaz ayuda a evitar la duplicación de registros, a reducir los errores de autenticación y a facilitar el mantenimiento de las políticas a lo largo del tiempo.

• Asigne claramente la responsabilidad sobre el SPF y la autorización de remitentes salientes entre los distintos equipos.
• Revise la política de SPF vigente antes de incorporar cualquier nueva plataforma de correo electrónico o proveedor.
• Documente cada remitente autorizado, el motivo por el que se incluye y quién es su responsable.
• Revise periódicamente la configuración del DNS y de la autenticación tras cualquier cambio en la infraestructura o en los proveedores.

• Mantenga un único registro por nombre de host y utilice entradas de registro SPF independientes únicamente en los subdominios que realmente envíen correo de forma independiente.

Estas buenas prácticas mejoran la visibilidad a largo plazo, el control de los cambios y las prácticas recomendadas en materia de autenticación del correo electrónico. Además, facilitan el mantenimiento de un SPF « » a medida que los inventarios de los remitentes crecen y cambian.

Facilite la gestión de varios registros SPF 

La conclusión principal es sencilla: cada dominio o nombre de host debe tener un único registro SPF, y no varias entradas SPF que entren en conflicto entre sí. La presencia de varios registros SPF no mejora la autenticación. Generan errores, normalmente del tipo «SPF PermError», y dichos errores pueden afectar a la capacidad de entrega del correo electrónico, a la confianza en el remitente y a la eficiencia operativa.