SPF a Dato: Podría autorizar más de lo que crees

¿Por qué SPF? a Los registros son importantes

SPF Funciona mediante la publicación de un registro TXT en el DNS que enumera las fuentes de envío autorizadas. La mayoría de los equipos se centran en el include y ip4 mecanismos.

Pocos prestan mucha atención al a mecanismo que indica a los servidores receptores que comprueben un SPF a registrar y autorizar cualquier dirección IP que devuelva.

En a Este mecanismo es legítimo y útil. Permite a las organizaciones asociar un nombre de host a un ip4 dirección. El problema no es el mecanismo en sí mismo, sino lo que ocurre cuando el SPF a El registro al que hace referencia ya no apunta a una infraestructura que estés a cargo de gestionar.

Supongamos que SPF de un dominio incluye a:mail.partner-domain.example.com. Cuando se creó ese registro, su empresa controlaba ese subdominio. Desde entonces, se ha transferido a un tercero.

El registro sigue autorizando la dirección IP del SPF a registro se resuelve en. Si el SPF a El registro apunta ahora a una dirección IP propiedad de un tercero; has autorizado que una infraestructura no verificada envíe mensajes en nombre de tu dominio.

El SPF a Registrar la diferencia de Softfail

Muchos SPF de empresas siguen utilizando ~all (softfail) en lugar de -all (error grave). El «soft fail» indica a los servidores receptores que los mensajes procedentes de fuentes no autorizadas deben marcarse, pero no necesariamente rechazarse. Si a esto se le suma un SPF obsoleto o mal configurado a registro, esto da lugar a una situación en la que:

• Un correo electrónico de un Las direcciones IP no verificadas superan la comprobación SPF porque el a el registro lo autoriza.
• Un correo electrónico de un El remitente legítimo no supera la verificación SPF porque el a El registro se ha desplazado.

Ninguno de los dos resultados es visible sin una supervisión activa. El primero supone un riesgo directo de suplantación de identidad y de estafa BEC que socava los esfuerzos por prevenir la suplantación de identidad en el correo electrónico.

El segundo provoca un problema de entrega que se manifiesta en forma de fallos intermitentes en la llegada a la bandeja de entrada. Este es precisamente el tipo de fallo que resulta difícil atribuir a una configuración errónea del DNS.

DMARC agrava aún más esta situación. Si SPF a un remitente incorrecto, DMARC siga dando el visto bueno a la alineación, lo que significa que tu política de aplicación no detecta el problema.

SPF a Pasos para la auditoría de registros: identificación de registros desalineados

Los siguientes pasos conforman un SPF estructurado a Auditoría de registros. Aplícalos a todos los dominios que envíen correo electrónico.

Paso 1: Extraer todo a Mecanismos de tus SPF

Para cada dominio, recupera el registro SPF completo SPF .

Documenta cada a mecanismo, incluidos los que se encuentran anidados en su interior include referencias. Anidadas include Las cadenas son donde se acumula lo obsoleto a los mecanismos suelen pasar desapercibidos.

Si tu SPF incluye remitentes externos, como plataformas de marketing, sistemas de recursos humanos o herramientas transaccionales, es posible que SPF de dichos proveedores contengan a su vez a mecanismos que se integran en una infraestructura de la que no tienes visibilidad.

Paso 2: Resolver cada SPF al que se hace referencia a Registrar y verificar la titularidad

Por cada a mecanismo, resolver el actual a registro.

A continuación, comprueba lo siguiente:

• Si la dirección IP devuelta pertenece a la infraestructura que controla su organización.
• Si la dirección IP está asignada a un proveedor de servicios en la nube y, en tal caso, si puede ser compartida con otros usuarios.
• Si la dirección IP se ha reasignado, se ha transferido o sigue apuntando a un recurso temporal.

En multicuenta , este paso suele revelar direcciones IP que pertenecen a antiguos proveedores. Estos son los casos en los que un único SPF mal configurado a El registro puede suponer un riesgo de autorización en varios ámbitos.

Paso 3: Cuenta tus consultas DNS

SPF un límite de 10 consultas de DNS durante la evaluación. Cada include, a, mxy exists Cualquier mecanismo que requiera una consulta DNS cuenta para este límite.

Si tu registro supera las 10 consultas, los servidores receptores devuelven un PermError, y SPF falla. Esto significa que tus mensajes podrían ser rechazados directamente. 

Cuenta el número de consultas en toda tu SPF , incluidas las anidadas include referencias. Cada a Un mecanismo que apunte a una dirección IP externa aumenta el número de consultas sin que ello suponga necesariamente una mejora de la seguridad.

Validación segura antes de la aplicación

Pasarse a SPF -all (error grave) o DMARC p=reject sin validar tu SPF a Los primeros registros pueden interrumpir los flujos de correo electrónico esenciales.

La secuencia de validación que reduce SPF a riesgo de registro:

1. Asigna todas las fuentes de envío antes de actualizar cualquier registro DNS. Utiliza los informes DMARC para identificar todas las direcciones IP que actualmente envían mensajes en nombre de tu dominio. Compara esas direcciones IP con las que tu SPF autoriza realmente. Las discrepancias indican que hay remitentes no autorizados o una configuración errónea a mecanismo.
2. Prueba a Anota los cambios en la clasificación siempre que sea posible. Si vas a actualizar un SPF a registro como parte de una migración o una retirada del servicio, comprueba qué SPF hacen referencia a ese registro antes de realizar el cambio. Los procesos de gestión del DNS empresarial deben tener en cuenta que los cambios en a Los registros pueden afectar a la seguridad y a la capacidad de entrega del correo electrónico.
3. Ir a -all solo se hayan asignado y autorizado tus fuentes de envío. El «soft fail» no debería ser una configuración permanente. Una vez que hayas comprobado que todos los remitentes autorizados superan SPF , el riesgo de pasar al «hard fail» es bajo.
4. Realizar una nueva auditoría tras cualquier cambio en la infraestructura. SPF a Las modificaciones de los registros, la incorporación de remitentes externos, las migraciones a la nube y las operaciones de fusiones y adquisiciones crean unas condiciones en las que SPF que ya habían sido auditados dejan de estar alineados. Crear a Incorpora la verificación de registros en tu proceso de gestión de cambios.

Cómo ayuda Sendmarc

Auditoría del SPF a El registro manual de los riesgos es viable para un único dominio. Sin embargo, no resulta viable a gran escala cuando se trata de docenas de dominios, múltiples departamentos y un ecosistema de proveedores que cambia cada trimestre.

Sendmarc ofrece una visibilidad constante sobre quiénes envían realmente mensajes desde tus dominios, incluidas las fuentes que tu SPF podría estar autorizando debido a que están desactualizadas o mal configuradas a registros.

Para los equipos que se preparan para pasar de p=none a p=reject, DMARC de Sendmarc ofrece una vía de aplicación estructurada: identifica a los remitentes no autorizados, valida a los autorizados y pasa a la aplicación de las medidas sin lugar a dudas.