SPF escala empresarial: sintaxis, gobernanza y límites

Capa 1: SPF y el límite de consultas DNS

SPF mediante la publicación de un registro TXT en la zona DNS de tu dominio. Ese registro recoge las direcciones IP y los dominios autorizados para enviar correo electrónico en tu nombre.

SPF mínimo tiene este aspecto:

En -all Al final, indica a los servidores receptores que rechacen los correos electrónicos de cualquier remitente que no figure en la lista. Sin ello —o cuando se utiliza ~all (softfail): el registro indica que los mensajes no autenticados deben tolerarse en lugar de rechazarse.

El límite de consultas DNS como restricción estructural

En Límite de consultas DNS es el punto de fallo más habitual en SPF escala empresarial. El RFC limita a 10 el número de consultas DNS que puede generar una SPF . Cada include, a, mxy redirect ese mecanismo cuenta para ese límite. Anidados includes agravar el problema: Un include que hace referencia a un registro de terceros que, a su vez, hace referencia a otros tres o cuatro includes puede agotar el presupuesto rápidamente.

Cuando se supera el límite de consultas, el SPF es «PermError», un error permanente que los servidores receptores interpretan como un fallo. En la práctica, un «PermError» puede provocar que se rechacen mensajes legítimos.

Gestión del recuento de consultas

Para gestionar el recuento de consultas, es necesario simplificar el SPF , es decir, sustituir include referencias con los rangos de IP resueltos, o bien utilizando una técnica como las macros o SPF dinámico SPF no sobrepasar el presupuesto.

Nivel 2: La proliferación de remitentes y el inventario de remitentes autorizados

SPF escala empresarial no es una configuración que se realiza una sola vez, sino una disciplina operativa continua.

Las empresas rara vez envían correos electrónicos desde una única fuente. Una empresa de tamaño medio puede utilizar un servidor principal, una plataforma de automatización de marketing, un proveedor de correo electrónico transaccional, una plataforma de recursos humanos, un sistema CRM y una herramienta de atención al cliente.

Cada uno de ellos debe ser un remitente autorizado. Cada uno debe aparecer en el SPF , ya sea directamente o a través de un include cadena.

Cómo se produce la acumulación

El problema es la acumulación sin control. Las fuentes de envío se van sumando con el tiempo —una nueva herramienta de marketing, la integración de un proveedor, una unidad de negocio adquirida con su propia infraestructura— y rara vez se eliminan cuando dejan de utilizarse. El SPF crece. El número de consultas aumenta. Y, al final, el registro acaba reflejando el historial de envíos de la empresa en lugar de su lista actual de remitentes autorizados.

La comparación de los remitentes autorizados con la información que figura en DMARC agregados permite detectar desviaciones antes de que se conviertan en un problema. DMARC agregados muestran todas las fuentes que envían correo electrónico desde tu dominio, con DKIM SPF DKIM correspondientes a cada una de ellas.

SPF escala empresarial significa que el registro refleja la autorización actual, no la acumulación histórica.

El inventario de remitentes como referencia para la gobernanza

Para las organizaciones que gestionan SPF escala empresarial, disponer de un inventario formal de remitentes —un registro de todos los sistemas autorizados para enviar mensajes en nombre de cada dominio, con su titular, la fecha de incorporación y la fecha de revisión— es un requisito básico de gobernanza, no una opción. Sin él, SPF se desvían, y esta desviación pasa desapercibida hasta que se produce un fallo o una auditoría pone de manifiesto la deficiencia.

El inventario de remitentes es la base del SPF escala empresarial.

Nivel 3: Gobernanza: control de cambios, responsabilidad y periodicidad de las auditorías

El control de cambios es lo que distingue SPF escala empresarial del SPF configuración puntual.

SPF se almacenan en el DNS. Los cambios en el DNS se realizan con gran facilidad desde el punto de vista operativo; por lo general, solo llevan unos minutos. Esa simplicidad plantea un riesgo de gobernanza: SPF suelen modificarse al margen del control formal de cambios, ya que parecen ser simples actualizaciones del DNS en lugar de cambios en las políticas de seguridad.

Por qué SPF justifican un control formal de cambios

En el caso de las empresas, los cambios SPF deben seguir el mismo proceso de control de cambios que los cambios en las reglas del cortafuegos o las actualizaciones de las políticas de acceso. Un cambio en un SPF puede:

• Autorizar a un nuevo remitente
• Eliminar un remitente obligatorio
• Interrumpir los flujos de correo electrónico
• El recuento de búsquedas de Push supera el límite
• Crear una desalineación

Titularidad

Para implementar SPF escala empresarial, la responsabilidad debe quedar claramente definida. Normalmente, el equipo de DNS o el departamento de infraestructura informática se encarga de gestionar la zona, pero el equipo de seguridad del correo electrónico y, en los sectores regulados, el departamento de riesgos y cumplimiento normativo deben dar su visto bueno a los cambios que afecten a la autenticación.

Frecuencia de las auditorías

Se debe definir la periodicidad de las auditorías. Una revisión trimestral del SPF en comparación con el inventario de remitentes autorizados es lo mínimo en la mayoría de los entornos empresariales. Las empresas con una actividad frecuente de fusiones y adquisiciones, migraciones activas a la nube o una elevada rotación de proveedores pueden necesitar revisiones mensuales.

Cada revisión debe confirmar que:

• Cada include Aún hace falta una referencia
• El número total de consultas DNS es inferior a 10
• En all el modificador está configurado en -all (fallo grave) en lugar de ~all
• El registro se ajusta a la DMARC

Capa 4: La brecha de alineación: lo que SPF no puede bloquear

La falta de alineación es la limitación más importante del SPF escala empresarial.

SPF al remitente de la envoltura, es decir, la dirección MAIL FROM. No autentifica el encabezado «De» que ven los destinatarios en su cliente de correo electrónico.

Un atacante que controle un dominio puede configurar un SPF válido para dicho dominio, superar la SPF y hacer que aparezca el dominio de tu empresa en el encabezado «De» visible.

Esto no es un fallo de SPF. Se trata de una limitación de la función para la que SPF diseñó SPF . SPF la ruta del sobre. Nunca se diseñó para proteger la dirección del remitente.

Cómo DMARC las deficiencias

DMARC cubre esta laguna. DMARC que el dominio que aparece en el encabezado visible «De» coincida con un dominio que supere DKIM SPF DKIM . La coincidencia significa que los dominios coinciden, ya sea de forma exacta (rigurosa) o a nivel de dominio raíz (flexible). 

DMARC solo sobre los mensajes no autenticados cuando su política está configurada en p=quarantine o p=reject. Una DMARC de p=nonesolo supervisa. Es el punto de partida adecuado durante la implementación, no el estado final. Una organización que implemente SPF y publique un DMARC en p=noney no avanza hacia la aplicación de la política tiene visibilidad del problema, pero carece de protección frente a él.

Lograr SPF escala empresarial

SPF escala empresarial requiere una visibilidad continua sobre quién realiza los envíos, qué está autorizado y si el registro se ajusta a una política DMARC activa. Sendmarc ofrece esa visibilidad en todos los dominios, subdominios y fuentes de envío.

En el caso de las empresas con múltiples dominios, propiedad distribuida y una elevada rotación de remitentes, la supervisión continua sustituye al ciclo de auditoría manual que la mayoría de los equipos no pueden mantener de forma constante.

Si tu DMARC sigue estando en p=none, tienes visibilidad del problema, pero no protección contra él. El camino desde la visibilidad hasta la aplicación de las normas está estructurado, y Sendmarc está diseñado para facilitar esa progresión sin interrumpir los flujos de correo electrónico por el camino.

¿Estás listo para pasar de la visibilidad a la aplicación? Descubre cómo Sendmarc te ayuda a avanzar hacia DMARC .