la frase DMARC bypass puede describir eventos muy diferentes. Un pase válido de una fuente sobreautorizada, la entrega a pesar de un resultado fallido y un error de implementación no son el mismo fracaso. Comience con una afirmación falsable: ¿qué identidad se afirmó, en qué evidencia se confió y qué decisión difirió de la regla esperada?
Reconstruir la decisión observada.
Conserve el dominio del autor, el dominio del sobre, los dominios de firma, los resultados de autenticación confiables y la disposición del receptor. Registre la política y el tiempo de observación. La entrega de un mensaje no prueba por sí solo un pase DMARC . El manejo del receptor incluye la política local y el tratamiento solicitado por el propietario de un dominio no es una garantía de entrega universal. RFC 9989.
Asimismo, una copia Authentication-Results La cadena no es prueba de la decisión del sistema receptor. Establezca el servicio de autenticación confiable y el salto relevante. RFC 8601. Si la única evidencia es una captura de pantalla que dice "aprobado", conserve el reclamo como no resuelto hasta que las identidades subyacentes y el contexto de confianza estén disponibles.
Separar la sobreautorización de la evasión de reglas
BreakSPF estudia cuán permisivo SPF La autorización y el acceso a la infraestructura compartida pueden permitir suplantación de identidad. Su modelo de amenaza le da al atacante una ruta de origen elegible; el receptor puede entonces evaluar la autorización publicada tal como está escrita. BreakSPF, Sección III.A y Figura 3.
Si la fuente controlada por el atacante está dentro de un rango autorizado y utiliza una identidad de sobre alineada, la regla de paso ordinaria puede tener éxito. La debilidad está en la autoridad otorgada o el límite del servicio, más que en una nueva definición de DMARC . Por el contrario, si solo se autentica una identidad no relacionada y el dominio del autor no está alineado, un pase reclamado necesita una explicación diferente.
Clasifica tres hallazgos hipotéticos
Suponga que hay un único aviso visible de alerts@brand.test y una evaluación DMARC que de otro modo sería elegible. Estas son hipótesis escritas, no incidentes observados.
- Caso de autorización: la fuente 192.0.2.99 está dentro de un rango SPF ip4:192.0.2.0/24 estipulado; CORREO DE bounce@brand.test pasa SPF ; No firma DKIM. La ruta SPF alineada produce un paso DMARC a nivel de mensaje. Pregunte si esa fuente realmente es controlable por un remitente no deseado y qué propietario le otorgó autoridad.
- Caso de manejo: CORREO bounce@other.test pasa SPF y DKIM d=other.test passes, but assume neither aligns with brand.test. DMARC fails. If the trusted receiver record separately says delivered, investigate its handling policy; delivery alone has not changed the failed alineación resultado.
- Caso de evidencia: un encabezado copiado dice aprobado, pero se desconoce el origen del receptor confiable, las identidades evaluadas y la política aplicada. No se establece ni una violación del protocolo ni un pase confiable. Solicite el registro original y del lado del receptor.
Un remitente positivo autorizado 192.0.2.10 y una fuente externa 198.51.100.10 pueden proporcionar controles propuestos al investigar el primer caso. Un hipotético registro ip4:192.0.2.10/32 -all admite sólo el primero; De esta aritmética de prefijos no se deriva ningún cambio real en la producción. Aquí no hay ningún analizador ejecutado, verificación de firmas o exploit.
RFC9989 sección 7.4 requiere DKIM válido para la publicación de dominios p=reject. Un mecanismo de SPF alineado es suficiente para la condición de aprobación de un mensaje en particular, pero no es una recomendación para la aplicación de SPF únicamente.
Hacer que el hallazgo sea procesable
Nombra la condición reproducida y la evidencia que aún falta. Un hallazgo útil dice que una fuente específica es admitida mediante una autorización específica e identifica al propietario responsable. No dice que se anule toda la protección DMARC . Compruebe si el servicio real restringe las identidades de los inquilinos, si la fuente es realmente controlable y si el receptor aplicó el resultado reclamado.
Preservar un control positivo autorizado inofensivo al probar una mitigación propuesta. Reducir un rango o cambiar un conector puede dañar a los remitentes legítimos. Exija la aprobación de cambios específicos de la ruta y la verificación posterior al cambio, y mantenga explícitamente sin resolver el comportamiento del proveedor no probado en el laboratorio. Esto respalda una solución precisa sin exagerar un modelo educativo hasta convertirlo en una vulnerabilidad de producción.