Cómo crear un SPF que sea fiable en un entorno empresarial

Por qué SPF sintácticamente válidos siguen fallando

La mayoría de SPF sobre cómo crear un SPF se limitan a explicar la estructura del registro. Explican include mecanismos, la diferencia entre ~all y -all , y cómo añadir una dirección IP de envío. En un entorno empresarial complejo, esos conocimientos son necesarios, pero no suficientes.

Entornos empresariales Normalmente, el correo electrónico se gestiona a través de una combinación de plataformas: un servidor central, una herramienta de automatización de marketing, un servicio de notificaciones transaccionales, una plataforma de recursos humanos, un sistema de nóminas y, en ocasiones, un socio externo que envía mensajes en nombre de la empresa. Cada una de ellas puede requerir su propio include referencia en el SPF .

Un registro configurado para dos remitentes queda rápidamente obsoleto a medida que aumenta el número de remitentes.

El riesgo inmediato es la capacidad de entrega: los correos electrónicos no autenticados que no superan SPF en las carpetas de spam o son rechazados directamente. El riesgo a largo plazo es aún mayor. SPF merman directamente tu capacidad para pasar a DMARC .

Realiza un inventario de remitentes antes de crear un SPF

Al crear un SPF , primero debes completar un inventario de remitentes. El orden es importante. Si empiezas por el registro, basarás la creación en lo que ya sabes y te dejarás algo en el tintero.

Un inventario de remitentes debe recoger cuatro datos para cada dominio de tu cartera: los servicios que envían correo electrónico, los rangos de IP necesarios o include las referencias, los equipos responsables de cada relación con el remitente y la fecha de la última revisión para su uso activo.

La ausencia de un inventario de remitentes implica que no existe una base fiable sobre la que crear un SPF .

En los entornos empresariales se acumulan los remitentes. Es posible que una plataforma CRM de un proveedor anterior siga teniendo un include esa referencia seguirá figurando en tu registro mucho tiempo después de que el contrato haya finalizado. Esa entrada ocupa una de tus 10 ranuras de búsqueda de DNS y no aporta ningún valor en materia de autenticación. Un inventario exhaustivo elimina ese desperdicio antes de que publiques nada.

El límite de 10 consultas: la restricción que hace que SPF falle

Es fundamental comprender los límites de consulta antes de crear un SPF .

SPF un límite estricto de 10 consultas de DNS durante la evaluación de los registros. Cada include, a, mxy exists Este mecanismo cuenta a efectos de dicho límite. Cuando un registro supera las 10 consultas, la evaluación devuelve un resultado «PermError», que los servidores receptores interpretan como un SPF .

El problema se agrava a gran escala. Las grandes organizaciones suelen heredar include mecanismos de remitentes externos. Un único include Una referencia a un importante proveedor de servicios de correo electrónico puede provocar dos o tres consultas DNS adicionales. Para cuando todos los mecanismos se hayan resuelto, un registro que a simple vista parezca pequeño puede llegar a consumir ocho o nueve consultas.

SPF es la medida de mitigación estándar. El «flattening» resuelve las direcciones IP que se encuentran detrás de tu include las referencias y las sustituye por estáticas ip4 y ip6 entradas. La contrapartida es el mantenimiento: Cuando tus servicios de envío rotan los rangos de IP, tu registro simplificado queda desactualizado.

La solución operativa a ese dilema es la automatización. La simplificación manual crea un registro puntual que se va desfasando. La simplificación automatizada supervisa los cambios en los rangos de IP de origen y actualiza el registro en consecuencia. Para las empresas que gestionan múltiples dominios, el mantenimiento manual de los registros simplificados en toda la cartera no es un proceso viable a largo plazo.

Estrategia de dominios y subdominios múltiples

Las empresas rara vez envían correos desde un único dominio. Una estructura típica incluye un dominio corporativo principal, dominios regionales o específicos de cada país, dominios de líneas de productos y subdominios utilizados para funciones específicas —notificaciones, facturación, marketing—. Cada uno de ellos requiere su propio SPF si se utiliza para enviar correo electrónico.

Los subdominios que no envían correo requieren registros explícitos. Un subdominio sin SPF no es neutral, sino que es vulnerable a ataques. Los atacantes pueden utilizar subdominios desprotegidos para enviar phishing que superen las comprobaciones básicas del dominio. La configuración correcta para los subdominios que no envían mensajes es una configuración explícita v=spf1-all registro.

En el caso de los subdominios que sí envían mensajes, el SPF debe incluir solo remitentes relevantes para la función de dicho subdominio. Los subdominios suelen tener un ámbito de envío más limitado, y un registro más específico reduce la superficie de ataque y el número de consultas.

Configurar un SPF y DMARC avanzado 

La forma en que se configura un SPF determina hasta qué punto se puede mejorar la DMARC .

Para DMARC supere, SPF DKIM coincidir con el dominio «From». SPF requiere que el dominio del remitente del sobre —el Return-Path— coincida con el dominio «From». Esto significa que un servicio de envío que utilice su propio dominio Return-Path (algo habitual) no garantizará SPF .

DMARC solo DMARC solo a esos mensajes si existe DKIM . Al crear tu SPF , identifica qué remitentes proporcionan SPF y cuáles se basan en DKIM. Esa identificación te indicará directamente el camino a seguir para la aplicación de las normas.

Gobernanza: ¿Quién es el titular del SPF ?

La gobernanza define quién tiene autoridad para crear un SPF , modificarlo y aprobar los cambios.

Para muchas empresas, la titularidad SPF es ambigua. El departamento de TI creó el registro original. El departamento de marketing añadió remitentes sin documentarlo. Un proveedor externo solicitó un include referencia a través de un ticket de asistencia que nadie cotejó con la estructura de registros existente. El resultado es un registro que refleja años de incorporaciones no documentadas y una falta de responsabilidad clara.

Los equipos de auditoría y cumplimiento normativo muestran un interés cada vez mayor por la autenticación del correo electrónico como medida de control. Las preguntas sobre quién puede modificar los registros DNS, cómo es el proceso de revisión y aprobación, y cómo se prueban los cambios antes de su implementación son cuestiones legítimas en materia de gobernanza, y la mayoría de las empresas no saben responderlas.

Una responsabilidad clara implica designar a un equipo como responsable de SPF en todos los dominios de la cartera. Los cambios deben seguir un proceso definido: solicitud, revisión en función del recuento actual de consultas y del inventario de remitentes, pruebas en un entorno de prueba siempre que sea posible, e implementación con un plan de reversión documentado.

En el caso de las empresas que cuenten con comités consultivos de cambios, las modificaciones SPF deben tratarse como un cambio en el DNS, lo que requiere el proceso de aprobación habitual.

La documentación constituye el registro de auditoría. Cada include La referencia que figura en el expediente debe corresponder a un servicio concreto, a un responsable y a la fecha de la última revisión.

Cómo te ayuda Sendmarc a crear un SPF

La gestión SPF una cartera empresarial con múltiples dominios supone una carga operativa constante: hay que realizar un seguimiento de las incorporaciones de remitentes, supervisar el número de consultas, mantener los registros simplificados a medida que los servicios de envío actualizan su infraestructura y conservar un registro de auditoría en el que puedan confiar los equipos de cumplimiento normativo.

Sendmarc automatiza SPF para que los cambios de IP en los servicios de envío de nivel superior no provoquen errores de autenticación. La plataforma ofrece visibilidad sobre toda tu cartera de dominios, de modo que las deficiencias y los remitentes no autorizados salen a la luz antes de que se conviertan en incidentes de entrega o de seguridad. El seguimiento de cambios dentro de la plataforma respalda la documentación de gobernanza que necesitan los equipos de auditoría y de gestión de riesgos.

Sendmarc te ofrece las herramientas y la visibilidad necesarias para crear un SPF que se adapte a medida que evoluciona tu entorno.