Estructura SPF : las decisiones de arquitectura que importan

Por qué la estructura SPF es una decisión de arquitectura

La mayoría de SPF se limitan a la sintaxis y pasan por alto las decisiones estructurales que determinan si un registro se mantiene a gran escala. Basta con configurar bien los mecanismos, publicar el registro y seguir adelante. Ese enfoque funciona para un único dominio con dos o tres fuentes de envío, pero falla en cualquier otro caso.

En los entornos empresariales suele haber varios sistemas de envío: un servidor principal, un CRM, una plataforma de marketing, un servicio transaccional y un sistema financiero. Si a esto le sumamos la infraestructura regional, la decisión sobre la estructura SPF se convierte en un problema.

La estructura SPF determina:

1. Cuántas consultas DNS genera durante la evaluación y en qué medida se acerca el registro al límite de consultas DNS
2. Si los rangos de direcciones IP simplificados provocan desviaciones a medida que cambia la infraestructura de los proveedores
3. Ya sea que include las cadenas son auditables

Se trata de decisiones SPF . Considerarlas como sintaxis es donde comienza el riesgo operativo.

El límite de consultas DNS: la restricción que determina la estructura SPF

La RFC 7208 limita SPF a 10 consultas DNS. Ese límite incluye cada include, a, mxy exists mecanismo de la cadena.

Para una configuración sencilla en una única plataforma, el límite de consultas DNS es generoso. En el caso de una empresa con cinco o seis remitentes SaaS, cada uno de los cuales cuenta con su propio include cadena, es fácil pasarse.

Supongamos que configuras un SPF para una organización de tamaño medio:

Esto parece razonable. Seis include referencias, todos ellos remitentes legítimos. Pero cada uno include apunta a un registro que, a su vez, contiene una o más consultas. Para cuando el servidor que realiza la evaluación resuelva esta cadena, es probable que ya hayas superado el límite de consultas DNS, lo que significa que SPF un PermError.

La solución no consiste en eliminar remitentes. La solución consiste en reestructurar el SPF para controlar la profundidad de la búsqueda.

Opción 1: Simplificación de direcciones IP

Sustituir include referencias con los rangos de direcciones IP resueltos:

ip4 y ip6 Los mecanismos no cuentan para el límite de consultas DNS, por lo que Aplanamiento de SPF elimina por completo la profundidad de búsqueda.

Esta elección de estructura SPF conlleva una desventaja: cuando un proveedor renueva o amplía su rango de direcciones IP —como hacen Google, Salesforce y los principales proveedores de servicios de correo electrónico (ESP)—, tu registro simplificado deja de ser preciso. SPF puede fallar en el caso de correos electrónicos legítimos hasta que actualices el registro manualmente.

Opción 2: SPF

Los MSP y las empresas que gestionan varios dominios desde una infraestructura compartida pueden utilizar macros para crear SPF de forma dinámica. El %{d} La macro se resuelve en el dominio de origen.

En -all vs. ~all Decisión sobre SPF

El SPF que aparece al final de un SPF determina qué ocurre cuando una fuente no figura en la lista. -all devuelve un error; ~all devuelve un «softfail». Ninguno de los dos SPF es correcto en todos los casos.

Para las empresas que cuentan con un Política DMARC de p=reject o p=quarantine, el efecto de la ~all vs. -all SPF es mínimo. DMARC tiene prioridad.

Para entornos que aún están creando su inventario de remitentes, ~all es el SPF inicial adecuado. Evita bloquear los mensajes de remitentes aún no identificados, mientras quereporte DMARC reporte esas fuentes para que se tomen medidas correctivas. Una vez completado el inventario de remitentes y DMARC de aplicación, se puede endurecer la configuración a -all es la opción más acertada desde el punto de vista operativo.

Errores habituales en la estructura de SPF

• Mecanismos duplicados: Enumerar lo mismo include Hacer referencia a un dato más de una vez supone un desperdicio del presupuesto destinado a la búsqueda de información y pone de manifiesto una mala gestión de los registros durante las auditorías.
• Desaparecido all calificador: Un récord sin un «-» al final all El valor predeterminado SPF es «neutral», lo que equivale, a efectos prácticos, a no tener ninguna SPF .
• Ausencia de un proceso de gestión de cambios: las actualizacionesSPF son cambios en el DNS. En entornos con ventanas de cambio estrictas, una SPF no documentada (que a menudo lleva a cabo un equipo de marketing o de incorporación) puede provocar fallos en la autenticación de otros remitentes.

Cómo ayuda Sendmarc

La gestión de la estructura SPF en múltiples dominios y proveedores de envío es una tarea operativa continua. Los entornos distribuidos dificultan la visualización de todas las fuentes de envío en un único lugar, y los equipos de seguridad y de TI, que ya están desbordados, no tienen capacidad para rastrear las cadenas de consulta.

Sendmarc ofrece una visibilidad continua de tu SPF , detectando remitentes desconocidos o no autorizados que aparecen en los datos DMARC antes de que se conviertan en un problema de cumplimiento normativo o de entregabilidad.

DMARC de Sendmarc amplía esta visibilidad más allá de SPF DMARC DKIM DMARC , con una supervisión continua y reporte centralizados reporte todos los dominios que gestionas.