Cómo investigar un informe XML agregado DMARC
Leer la fuente cuenta y resultados alineados, compararlos con un inventario del remitente, y evitar confundir el fallo DMARC con un ataque confirmado.
Definir la cuestión y la ventana de presentación de informes
Comience con una pregunta específica: ¿es un conocido boletín de noticias que falla alineación, o tiene una fuente desconocida apareció en los informes seleccionados? Escriba la organización de informes, el dominio de políticas y el rango de fechas antes de combinar archivos. Un informe global resume las observaciones de un receptor; no es un libro completo de cada mensaje que su organización envió. Faltan receptores y lagunas en la presentación de informes. Mantenga el informe original junto a sus notas para que un revisor posterior pueda inspeccionar la misma evidencia. Un alto recuento sin una ventana de reporte definida es difícil de comparar con un cambio en su actividad de envío.
Abra el XML que el lector realmente soporta
El lector de informes agregados DMARC acepta un documento XML completo o archivos XML UTF-8 seleccionados. Extraer archivos comprimidos primero: Los contenidos ZIP y GZIP no se analizan directamente. La interfaz actual soporta hasta veinte archivos, cinco megabytes totales y veinte mil registros. La entrada de archivo reemplaza XML pegado. Revise qué archivos se seleccionan antes de ejecutar el análisis. Procesar permanece en su navegador, pero eso no establece la autenticidad del informe. Utilice los informes recibidos a través de su flujo de trabajo normal de informes y mantenga su procedencia en lugar de tratar un archivo XML descargado arbitrariamente como autoritativo.
Destinguida alineación de un pase de autenticación cruda
DMARC relaciona la autenticación exitosa SPF o DKIM al visible Desde el dominio a través de la alineación. Un pase crudo para otro dominio puede coexistir con una falla de alineación. El lector cuenta con los resultados de policy_evaluated, en lugar de sustituir los valores brutos auth_results. Esa elección importa al investigar el reenvío o los servicios que firman con un dominio diferente. Compare los identificadores pertinentes antes de interpretar una aparente contradicción. RFC 9989 describe el modelo de autenticación y alineación; RFC 9990 define la información agregada. Ni un pase crudo ni una política publicada es suficiente, por sí misma, para explicar el resultado de cada mensaje.
Trabajo a través del informe de demostración ficticia
El ejemplo incorporado contiene tres registros: 120 mensajes con pases alineados SPF y DKIM, 30 con DKIM de paso alineado y falla SPF alineado, y 10 con ambos fallos. Añadiendo los recuentos suministrados da 160 mensajes. Los dos primeros grupos contribuyen 150 pases DMARC porque ya sea el mecanismo alineado es suficiente; diez fallas. La cuota de fracaso para esta fijación es 10 dividida por 160, o 6.25%. Estos son cálculos de XML deliberadamente ficticios, no observaciones sobre un dominio real o proveedor. Utilice el ejemplo para saber qué campos conducen los totales antes de importar sus propios informes.
| Alineado DKIM | SPF de los Países Bajos | Mensajes | Resumen DMARC |
|---|---|---|---|
| Paso | Paso | 120 | Paso |
| Paso | Fail | 30 | Paso |
| Fail | Fail | 10 | Fail |
| Total | Cualquier mecanismo alineado pasa | 160 | Paso 150; 93.75% |
Informe de ficción. La disposición del receptor y el resultado de la alineación son campos separados.
Use este ejemplo Abre el lector de informes DMARC con estas entradas.
Mantener la disposición separada de la autenticación
Un informe también proporciona la disposición del receptor. El lector acepta pasar de RFC 9990, ninguno heredado, cuarentena y rechazar; es un lector estructural en lugar de validación de esquemas XML completos. No asuma que el recuento de cuarentena debe igualar todas las fallas DMARC. Las opciones de política y el manejo de receptores pueden hacer que esos totales sean diferentes. En el ejemplo ficticio, los diez mensajes fallidos tienen una disposición cuarentena; esa relación pertenece a la fijación suministrada y no es una regla universal. Lea la información récord antes de escalar una diferencia inexplicable. Los campos de alineación conducen totales de autenticación, independientemente de la acción que el receptor reporta.
Compare una fuente con su inventario de envío
Para una fuente desconocida, compare la dirección fuente, dominio visible y período de observación con sus servicios conocidos y cambios recientes. Una nueva plataforma de facturas o una integración migrada del boletín puede explicar el tráfico que estaba ausente del viejo inventario. El uso anticipado o no autorizado son otras posibilidades. El lector no atribuye una dirección IP a un proveedor o clasifica una fuente como maliciosa. Mantenga esos juicios separados hasta que tenga evidencia. Grabar un siguiente paso práctico, como comprobar el dominio de firma configurado del proveedor, en lugar de eliminar o bloquear automáticamente cada fila que falla la alineación.
Evite contar las mismas observaciones dos veces
Mantener las identidades del informe y los períodos de presentación de informes en su historial de trabajo. El lector rechaza identidades duplicadas dentro de una presentación, pero diferentes IDs de informe con períodos superpuestos todavía pueden describir el tráfico superpuesto. Combinar esos archivos puede inflar una tendencia aparente. Compare la cobertura y los intervalos de receptor similares al medir la mejora después de un cambio de configuración. También recuerde que la tabla mostrada puede ser limitada mientras la descarga conserva más filas. Investigar la exportación completa cuando sea necesario. Un porcentaje cambiante puede reflejar una nueva selección de informes, así como un cambio de configuración de envío.
Verificar un mensaje real antes de cambiar la política
Utilice el control de registro DMARC para inspeccionar la política actualmente publicada, a continuación, obtener un mensaje representativo del servicio legítimo afectado. Lee los encabezados de confianza con el analizador de cabecera y compara las identidades con el informe. El DNS actual puede diferir de la política observada durante un informe anterior. Mantenga la diferencia de tiempo explícita. Una vez entendido la causa, revise la configuración de servicio pertinente y su proceso de cambio de políticas. Un informe es una pista de diagnóstico, no una promesa de entrega o un comando para pasar inmediatamente a una política más estricta. Retener las pruebas y verificar las observaciones posteriores.