Se ha alcanzado SPF : corrige los registros DNS antes de que afecten al correo electrónico legítimo

Para la mayoría de las organizaciones, este problema se va acumulando poco a poco. Se ha incorporado una nueva plataforma de marketing. El departamento de RR. HH. adopta una herramienta de selección de personal. El departamento financiero añade un sistema de facturación. El servicio de asistencia comienza a gestionar las consultas desde una plataforma de help desk. Cada cambio parece insignificante. Con el tiempo, el SPF se vuelve más complicado de gestionar, más difícil de auditar y cada vez más propenso a fallar durante la evaluación.

Por eso el SPF es importante desde el punto de vista operativo. Puede impedir la autenticación de correos electrónicos legítimos, generar riesgos en la entrega y obligar a los equipos a realizar tareas de resolución de problemas de forma reactiva. El impacto no siempre se traduce en un rechazo directo. Depende de si otro método de autenticación cumple con la DMARC del dominio y de cómo gestiona el mensaje el sistema receptor.

Qué es el SPF

SPF al propietario de un dominio especificar qué fuentes están autorizadas a enviar mensajes en su nombre. Los destinatarios utilizan la SPF publicada para comprobar si el remitente está autorizado.

SPF es el número máximo de consultas DNS que un servidor receptor puede realizar durante una evaluación. Cuando un servidor de correo electrónico receptor comprueba tu SPF , no puede realizar más de 10 consultas DNS. Si el recuento supera las 10, el receptor debe devolver un error permanente (PermError).

No todos SPF o modificadores SPF cuentan para ese total. Los principales que sí cuentan son:

• include
• a
• mx
• ptr
• exists
• redirect

Los términos all, ip4y ip6 no cuentan para el límite de 10 consultas, ya que no activan consultas DNS durante una SPF . También existen otros sublímites relacionados con mx y ptr, lo cual es una de las razones por las que los registros complejos se vuelven frágiles más rápido de lo que los equipos esperan.

En la práctica, el SPF es una medida de seguridad del protocolo. Su finalidad es evitar una carga de consultas excesiva. Cuando tu política supera lo que permite el protocolo, el resultado no es una validación con calidad reducida, sino un error.

¿Qué ocurre cuando SPF demasiadas consultas DNS?

Cuando SPF demasiadas consultas DNS, el servidor receptor devuelve un PermError. Esto significa que el receptor no ha podido interpretar correctamente la SPF publicada del dominio debido a las reglas del protocolo. Un PermError es un error que requiere actualizaciones del DNS.

El efecto en las etapas posteriores es más complejo. DMARC exige DKIM tanto SPF DKIM superen DKIM . Se puede obtener una DMARC incluso si DKIM supera la comprobación. Por lo tanto, un SPF no conduce automáticamente a un DMARC si DKIM superando la comprobación.

Por eso, a menudo este problema se manifiesta como un problema de entrega antes de que se identifique como un problema SPF .

Lo primero que pueden notar los equipos es que:

• Los correos electrónicos para restablecer la contraseña han dejado de llegar
• No se envían las facturas ni los avisos de pago
• Los correos electrónicos de asistencia no llegan a determinados destinatarios
• El rendimiento de la campaña disminuye

¿Qué provoca el errorSPF consultas DNS»?

Demasiados includes

Esta es la causa más común. Cada include apunta a otro registro. Esto resulta práctico cuando los proveedores tienen sus propios registros, pero el número aumenta rápidamente. Una unidad de negocio añade una plataforma. Otra añade dos más. Al final, el número de registros supera el límite permitido por el protocolo.

Uso excesivo de los mecanismos de consulta de DNS

Los récords también se vuelven peligrosos cuando los equipos dependen en gran medida de a, mx, existso redirect. Estos términos son válidos, pero todos ellos contribuyen al límite de consultas DNS. Un registro puede parecer breve en el DNS, pero al comprobarlo puede generar demasiadas consultas.

Registros de proveedores anidados

Lo que se ve no siempre es el verdadero problema. Uno include puede hacer referencia a otro registro con varios más includes. Sobre el papel, tu SPF puede parecer manejable. En realidad, el número total de consultas puede superar con creces el límite.

Remitentes antiguos que nunca se eliminaron

Los antiguos sistemas de gestión de entradas, las herramientas de campaña ya en desuso y los proyectos puntuales suelen permanecer en SPF mucho tiempo después de que el servicio haya dejado de utilizarse. El riesgo aumenta con el tiempo, ya que las entradas en desuso siguen contándose cuando SPF comprueba SPF .

Sin propiedad centralizada

SPF quedar a cargo de varios equipos. El departamento de marketing gestiona un remitente. El departamento de TI gestiona otro. El servicio de asistencia gestiona un tercero. El departamento de seguridad revisa la política solo surge algún problema. Al no haber una responsabilidad centralizada, el SPF crece como consecuencia de las adquisiciones y las operaciones.

Cómo reducir SPF

1. Hacer un inventario de todos los servicios que envían correos electrónicos

Empieza por analizar el panorama real de los remitentes. Documenta todas las plataformas, herramientas, proveedores y servicios de terceros que envían correos electrónicos utilizando el dominio. Incluye los sistemas transaccionales, las herramientas de CRM, las plataformas de RR. HH. y los servicios financieros.

No optimices SPF saber qué sistemas deben seguir funcionando.

2. Comprueba el SPF y todos los términos de consulta DNS

Debes contar cada término de consulta DNS que el servidor receptor evalúa durante la SPF . Esto también incluye los anidados includes.

Presta atención a estos mecanismos y modificadores:

• include
• a
• mx
• ptr
• exists
• redirect

Si el recuento ampliado es igual o superior a 10, tienes un problema con SPF .

3. Eliminar remitentes que no se utilizan o que están duplicados

Esta suele ser la forma más rápida de reducir el tamaño de tu registro. Los sistemas retirados, las entradas duplicadas de proveedores y los proyectos temporales suelen permanecer en SPF .

Comprueba si cada remitente sigue siendo necesario. Si una plataforma ya no envía correos electrónicos, elimínala. Si hay varios servicios que se repiten, consolídalos siempre que sea posible.

4. Simplificar siempre que lo permita el control administrativo

Cuando controles la infraestructura de envío, utiliza SPF estables y directas en lugar de largas cadenas de includes. Estático ip4 y ip6 Las entradas no consumen el presupuesto SPF . A menudo son más fáciles de usar que los registros de terceros.

Esto puede reducir rápidamente el número de búsquedas y facilitar la revisión del registro.

5. Trasladar los flujos de correo electrónico a subdominios correspondientes

A veces, la solución adecuada es la separación, no la agrupación. Si los correos electrónicos de marketing, asistencia y transacciones se envían todos desde el mismo dominio raíz, separar determinados flujos en subdominios específicos puede reducir SPF y mejorar la claridad en cuanto a la propiedad.

6. Utiliza una herramienta SPF

SPF puede reducir el número de consultas al sustituir las búsquedas de DNS por direcciones IP ya resueltas. Si se utiliza con cuidado, es una de las formas más prácticas de mantenerse dentro del SPF sin dejar de permitir el envío por parte de terceros.

Los registros simplificados deben mantenerse actualizados a medida que cambia la infraestructura del proveedor. Una solución de simplificación estática que no se actualice periódicamente puede quedar obsoleta y provocar errores de autorización de forma inadvertida más adelante.

7. Volver a realizar la prueba SPF confirmar que el registro se mantiene dentro de los límites

Una vez realizados los cambios, vuelve a comprobar el registro y verifica de nuevo el recuento total de consultas. Confirma que la política se mantiene dentro de los límites del protocolo y que sigue autorizando a todos los remitentes necesarios.

Este es también el momento en el que los equipos deben comprobar que los flujos de correo electrónico importantes siguen pasando DMARC los SPF .

8. Supervisar el registro para detectar desviaciones por parte del proveedor

Un SPF puede pasar de estar en buen estado a ser de riesgo sin que se produzca ningún cambio directo en tu propio DNS. Los proveedores pueden actualizar sus propios SPF o añadir nuevos includes. Dado que SPF las consultas en todos los registros vinculados, los cambios realizados por parte de los proveedores pueden hacer que, con el tiempo, te acerques al límite.

Por eso es importante realizar revisiones periódicas. La tareanotermina solo el registro sea válido hoy. Se da por concluida cuando el dominio puede adaptarse a los cambios futuros sin sobrepasar el SPF .

Comprueba tu SPF antes de que la incorporación de un nuevo remitente convierta un registro que se gestiona sin problemas en un problema de entrega.