Cómo fusionar registros SPF: guía completa paso a paso

Por qué las organizaciones terminan con varios registros SPF

La mayoría de las empresas no se proponen publicar varios registros SPF. Estos se acumulan con el tiempo a medida que el entorno de remitentes crece y cambia.’

Cada vez que se añade una nueva plataforma de correo electrónico – un CRM, una herramienta de marketing o un sistema de RR. HH. – es posible que se publique una nueva entrada SPF como un registro TXT independiente en lugar de añadirla al registro existente. La descentralización de TI hace que las unidades de negocio publiquen registros SPF de forma independiente, sin visibilidad de lo que ya existe. El resultado son varios registros TXT de SPF en el mismo dominio.

Las fusiones y adquisiciones agravan el problema. La infraestructura de correo electrónico de la entidad adquirida suele incluir sus propios registros SPF, que pueden entrar en conflicto con los ya publicados en el dominio de la organización adquirente.’’

Por qué varios registros SPF rompen la autenticación

’El RFC 7208 establece que un dominio no debe publicar más de un registro TXT de SPF. Cuando existen varios registros, el servidor receptor se confunde y devuelve un PermError – un error permanente que provoca el fallo de SPF.

’Un PermError significa que DMARC no puede usar SPF para superar la autenticación. DMARC exige que SPF o DKIM apruebe y haya alineación – así que, cuando SPF falla, DKIM debe asumir toda la carga. Si DKIM no está configurado correctamente, DMARC falla.’

Los registros duplicados son una causa común de fallos de DMARC difíciles de diagnosticar, ya que el error no siempre resulta evidente en los reportes agregados de DMARC.’

Cómo fusionar registros SPF correctamente

La forma correcta de fusionar registros SPF comienza con un enfoque estructurado. Apresurar la consolidación sin un inventario completo de remitentes conlleva el riesgo de excluir remitentes legítimos y provocar fallos de entrega.

1. Complete un inventario de remitentes exhaustivo. Documenta todas las plataformas autorizadas para enviar correo electrónico en nombre del dominio. Esta es la base que debe cubrir el registro fusionado. Incluye plataformas de marketing, CRM, sistemas de recursos humanos, herramientas de tickets y cualquier aplicación SaaS que envíe correo electrónico en nombre de su dominio.
2. Enumera todos los mecanismos de los registros SPF existentes. Extrae todos los mecanismos ip4:, ip6:, include:, a, mx, ptr, exists y redirect de todos los registros TXT publicados. Identifica los duplicados – cualquier mecanismo que aparezca en más de un registro existente solo necesita figurar una vez en el registro fusionado.
3. Elimina los mecanismos obsoletos y redundantes. Cualquier mecanismo que no corresponda a un remitente activo y autorizado debe eliminarse. Esto reduce el número de búsquedas DNS y reduce tu superficie de ataque. Valida las eliminaciones frente a tu inventario de remitentes antes de continuar.’
4. Consolida todo en un único registro TXT. Combina todos los mecanismos válidos en un solo registro TXT de SPF. El registro debe empezar con v=spf1 y terminar con un único calificador.
5. Verifica el número de búsquedas DNS. Antes de publicar, confirma que el registro fusionado se mantiene por debajo de las 10 búsquedas DNS. Cuenta cada mecanismo include:, a, mx, ptr, exists y redirect, incluidas las búsquedas anidadas.
6. Publica, elimina los duplicados y prueba. Publica el registro fusionado, elimina todos los demás registros TXT de SPF del dominio y valida el resultado con un verificador de SPF. Supervisa los reportes agregados de DMARC para comprobar la tasa de aprobación de SPF en los días posteriores al cambio.

Cómo gestionar los límites de búsquedas después de fusionar registros SPF

El límite de 10 búsquedas DNS se aplica a las búsquedas recursivas, no solo a los mecanismos visibles en el propio registro. Las cadenas anidadas de include: cuentan para el límite.

SPF Flattening resuelve los mecanismos include: convirtiéndolos en sus direcciones IP subyacentes, sustituyendo las búsquedas DNS por entradas estáticas. Esto reduce el número de búsquedas, pero requiere un mantenimiento activo.

’SPF Flattening de Sendmarc automatiza este proceso, manteniendo el registro dentro del límite de búsquedas sin necesidad de actualizaciones manuales.

’Cada nueva plataforma de envío añadida al entorno debe evaluarse frente al recuento actual de búsquedas antes de autorizarla en el registro SPF. Añadir un nuevo mecanismo include: a un registro que ya tiene nueve búsquedas provoca un PermError. Mantener un presupuesto de búsquedas – es decir, llevar un control del recuento – evita este fallo.

Mantén tu configuración válida después de fusionar registros SPF

Los fallos de SPF son difíciles de detectar a tiempo y más difíciles de rastrear sin una visión clara de cada dominio de envío.

’La Plataforma de Gestión de DMARC de Sendmarc los identifica en todos los dominios, marca las fuentes de envío no autorizadas y hace un seguimiento del estado de alineación de SPF. SPF Flattening mantiene los registros dentro del límite de búsquedas DNS de forma automática, reduciendo la carga operativa de los equipos de DNS y TI que gestionan entornos de remitentes complejos o distribuidos.

Después de fusionar registros SPF, un registro válido no se mantiene por sí solo. Sendmarc se encarga de que siga siéndolo a medida que crece tu entorno de remitentes.’