Lista de comprobación SPF : qué hay que comprobar antes de publicar un registro

Por qué la auditoría es lo primero

Realizar una SPF antes de la publicación permite detectar lo que un simple comprobador sintáctico no puede. La mayoría de SPF en un entorno con múltiples proveedores no se deben a registros mal formados, sino a que se publica un registro basándose en lo que sabe el equipo, y no en lo que realmente está enviando los mensajes.

Estas deficiencias provocan errores de autenticación que hacen que los correos electrónicos legítimos acaben en la carpeta de spam.

El envío de correos sin un inventario completo de remitentes no solo un problema de entregabilidad. Si tu organización opera bajo marcos de auditoría que exigen medidas de seguridad técnicas adecuadas para el correo electrónico, un registro incompleto que permita el envío de mensajes no autenticados constituye una deficiencia que los comités de auditoría y de riesgos detectarán. Crear un registro no es lo mismo que controlar tu entorno de correo electrónico.

Lista de comprobación SPF : Pasos previos a la creación

1. Crear un inventario completo de remitentes

Este es el paso que más tiempo lleva de la lista de comprobación SPF , y el que más probabilidades tiene de que se omita. No lo omitas.

Enumera todos los dominios y subdominios que utiliza tu empresa para enviar correos electrónicos, todas las plataformas o proveedores que envían mensajes desde esos dominios, y cualquier socio o agencia que envíe mensajes en tu nombre.

En un entorno con múltiples proveedores, registra para cada remitente los rangos de IP, el dominio de envío y el mecanismo requerido (include, ip4, ip6), y el equipo responsable del mismo.

2. Revisar los registros DNS existentes

Antes de crear un nuevo registro, comprueba lo que ya está publicado. En un entorno con varios proveedores, es habitual encontrar un SPF que nunca se ha actualizado, registros TXT conflictivos o duplicados, registros de subdominios con una configuración demasiado permisiva +all los clasificados, o los récords que ya han superado el Límite de 10 búsquedas DNS.

Un registro que supere el límite de consultas genera un resultado «PermError» en el momento de la evaluación. Los servidores receptores lo interpretan como un error. Si vas a heredar un registro ya existente en lugar de crear uno nuevo, cuenta el número de consultas antes de añadir nada.

3. Evaluar la preparación para el seguimiento

La preparación para la supervisión es el punto de la lista de comprobación SPF que la mayoría de los equipos dan por sentado que ya está cubierto. La creación SPF sin supervisión es una acción puntual, no una implementación controlada.

Antes de publicar, compruebareporte implementado o se tenga previsto implementarreporte DMARC . Los informes DMARC muestran qué fuentes cumplen o incumplen SPF ; sin ellos, el equipo trabaja a ciegas.

Comprueba también que exista un proceso para revisar los errores de autenticación: quién recibe los informes y quién se encarga de clasificarlos. La supervisión de la preparación no es opcional; marca la diferencia entre una implementación controlada y un juego de adivinanzas.

4. Coordinar a las partes interesadas antes de realizar cambios en el DNS

En un entorno con múltiples proveedores, SPF todos los equipos que envían correos electrónicos. Si se implementa sin una coordinación previa, la semana siguiente a la puesta en marcha se convertirá en una sucesión de quejas y problemas técnicos por parte de los equipos que no sabían que se iba a producir el cambio.

Como mínimo, informa a los responsables de marketing y CRM (que son los que más probablemente tengan remitentes no documentados), a los de finanzas y compras (las notificaciones del ERP suelen pasarse por alto), a operaciones de TI y al servicio de asistencia técnica (primera línea de atención de reclamaciones), y a los departamentos jurídico y de cumplimiento normativo (requisitos de documentación). Este paso de la lista de comprobación SPF tiene tanto que ver con la comunicación como con el DNS.

Creación SPF : sintaxis y patrones habituales

Una vez que se han comprobado todos los puntos de la lista de verificación SPF y se ha alcanzado un consenso entre las partes interesadas, la creación SPF en sí es relativamente sencilla. Un registro típico de una empresa tiene el siguiente aspecto:

Uso -all (fallo grave) en lugar de ~all (softfail); ~all Es aceptable durante una implementación supervisada, pero no debería ser permanente. Es preferible include mecanismos sobre ip4 intervalos cuando un proveedor publica un registro actualizado, ya que esto reduce el trabajo de mantenimiento cuando cambia la infraestructura del proveedor.

Evita +all y ?all en producción, y no superar el límite de 10 consultas DNS.

Cada subdominio que envíe correos electrónicos necesita su propio registro. Los subdominios no heredan la SPF del dominio principal.

Una vez que el registro entre en vigor

SPF no finaliza una vez que se ha completado la creación SPF y este se ha publicado. En un entorno con múltiples proveedores, debes revisar los informesDMARC en las primeras 48 a 72 horas y buscar fuentes que aparezcan en los informes y que no figuraran en el inventario original, ya que esa es la señal más clara de que la auditoría previa a la publicación pasó algo por alto.

Cómo ayuda Sendmarc

SPF un entorno con múltiples proveedores no permanece estático. Los proveedores cambian la infraestructura, los equipos incorporan nuevas herramientas sin avisar al departamento de TI, y las fusiones y adquisiciones introducen remitentes que no existían en el inventario original. El seguimiento manual no ampliarse, y los equipos de seguridad y de TI, ya de por sí sobrecargados, necesitan una lista de comprobación paraSPF y una supervisión continua. 

Sendmarc ofrece a los equipos una visión global de DMARC SPF, DKIM y DMARC en todos los dominios, de modo que el inventario de remitentes en el que se basa la lista de comprobación SPF se mantenga actualizado y no quede obsoleto en tan solo un trimestre. Cuando aparece una nueva fuente en los datos DMARC , esta se muestra en la plataforma, de modo que el equipo pueda evaluarla y autorizarla antes de que se convierta en un error de autenticación o en una brecha de cumplimiento.

En el caso de los comités de auditoría y de riesgos, DMARC mantiene el historial documental del que reporte fiables: qué remitentes están autorizados, cuándo se añadieron y quién es su responsable.

Para los equipos de seguridad que gestionan múltiples dominios y departamentos, esto reduce la carga operativa que supone la propia auditoría y estandariza la política en todos los departamentos y regiones, sin convertir SPF un control que se configura una vez y se olvida, y que acaba quedando desactualizado.

Si la creación SPF forma parte de una iniciativa más amplia encaminada a DMARC , Sendmarc ofrece soporte para todo el proceso, desde la supervisión hasta la cuarentena y el rechazo, con la visibilidad del remitente que un entorno con múltiples proveedores necesita para llevar a cabo cada paso.