Un dominio de buena reputación o un servicio de envío compartido puede convertirse en parte de una ruta de mensaje abusiva. La pregunta útil no es si la infraestructura es generalmente confiable. Es si este mensaje en particular estaba autorizado a utilizar la identidad autenticada. La autenticación y la autorización comercial responden a diferentes preguntas.
Definir la autoridad que se reutiliza
Un buzón comprometido puede realizar envíos a través de su ruta autenticada ordinaria. Una autorización de red demasiado amplia puede admitir una fuente no deseada. Un retransmisor puede firmar un mensaje después de aceptarlo según una regla de admisión insuficientemente específica. Estos mecanismos tienen diferentes dueños y remedios. No los colapses en un reclamo inexplicable de secuestro de reputación.
La investigación original de BreakSPF examina la permisividad SPF configuraciones e infraestructura compartida. Su modelo de amenaza hace que el acceso a la red fuente sea una condición central. Ese es un límite de implementación, no evidencia de que un atacante pueda falsificar cualquier firma DKIM. Documento BreakSPF, Sección III. Trate las mediciones del artículo como una investigación histórica, no como un inventario actual de servicios vulnerables.
Construya un modelo de amenaza preciso
Escriba por separado el dominio protegido, el identificador autenticado, el conjunto de fuentes permitidas, la capacidad del atacante y la decisión del receptor. En el escenario acotado aquí, brand.test autoriza 192.0.2.0/24 para SPF . La aplicación aprobada utiliza 192.0.2.10 , mientras que un inquilino hipotético no deseado puede originarse en 192.0.2.99 . Ambas direcciones se encuentran dentro del rango publicado. Si dicho acceso de inquilino existe en un servicio real requiere evidencia separada.
SPF verifica la autorización de origen para determinar su identidad evaluada. No identifica al ser humano detrás de una IP compartida. Si la identidad SPF que pasa también se alinea con el dominio del autor, esa ruta puede satisfacer DMARC sin DKIM. RFC 7208 y RFC 9989. Por lo tanto, una evaluación exitosa puede revelar que se otorgó demasiada autoridad, en lugar de que un receptor ignore la regla de pase.
Compare tres casos de autorización escrita
Suponga que es visible desde alerts@brand.test , no vacío CORREO DE bounce@brand.test , sin firma DKIM y una evaluación DMARC que de otro modo sea elegible. Comparar hipotético Registros SPF v=spf1 ip4:192.0.2.0/24 -all and v=spf1 ip4:192.0.2.10/32 -all. No other mechanisms exist in these examples.
- Fuente aprobada 192.0.2.10 : incluida por ambos prefijos de red; SPF pasa y se alinea con brand.test, por lo que el mensaje ilustrativo pasa DMARC en cualquier caso.
- Fuente no deseada 192.0.2.99 : incluida en /24 pero no en /32; SPF pasa sólo bajo el registro amplio. Sin firma DKIM , el resultado DMARC estipulado se pasa bajo /24 y falla bajo /32.
- Fuente externa 198.51.100.10 : no incluida por ningún prefijo; -all los rendimientos SPF fallan en cualquier caso. Sin firma DKIM , el resultado DMARC estipulado es fallido en ambos.
Estos son prefijos escritos de membresía y alineación deducciones, no un analizador SPF en ejecución, observación DNS o reproducción de BreakSPF. El control de fuente se supone, no se demuestra. No se probó ningún mensaje externo ni servicio en vivo. La técnica de protocolo cruzado del artículo está fuera de este ejemplo de enseñanza.
Un mecanismo alineado de paso único puede satisfacer la condición de paso DMARC de un mensaje. Eso no hace que la implementación solo de SPF sea adecuada: la sección 7.4 de RFC9989 requiere DKIM válido para la publicación de dominios p=rejecty la sección 8 aborda la participación plena. Estas son tareas de implementación separadas, no una puerta de paso adicional por mensaje.
Fijar el límite de rendición de cuentas
Antes de limitar un registro SPF real, haga un inventario de todos los remitentes legítimos y siga la configuración respaldada por el proveedor. Una fuente dedicada sólo es útil si es realmente exclusiva y se mantiene. Confirmar que el servicio de envío vincula a los clientes con sus identidades permitidas; Verifique la configuración DKIM y elimine la autoridad obsoleta mediante el control de cambios.
Supervise los fallos específicos de la ruta después del cambio, conserve un plan de recuperación y documente los remitentes desconocidos. No reemplace un registro amplio con una lista de IP supuesta de este ejemplo. La lección es conciliar la autorización con la propiedad real del servicio, no copiar DNS de demostración en producción.