Un informe comienza con una observación
Un correo con un asunto como «Report domain» no es automáticamente una alerta. Un proveedor receptor resume los mensajes que observó usando su dominio remitente durante un periodo concreto. Todos ellos pueden funcionar correctamente. El informe no confirma un acceso indebido a una cuenta ni es una notificación de entrega fallida de un correo determinado.
Los informes agregados se solicitan mediante el destino rua del registro DMARC. Los datos están en un archivo XML adjunto, a menudo comprimido. Por eso, un cuerpo de mensaje vacío no hace inútil el informe. Tampoco basta el nombre visible del remitente para acreditar su autenticidad: procese estos archivos mediante un procedimiento de análisis controlado. [1] [3]
Comprobar el periodo antes de sumar
Empiece por report_metadata: ¿quién genera el informe, cuál es su report_id y qué intervalo UTC cubre date_range? Después compruebe el dominio en policy_published. La fecha de recepción del correo no sustituye al periodo observado. count representa mensajes agrupados por la combinación de resultados correspondiente, no clientes, personas ni incidentes de seguridad.
Defina una regla de recuento reproducible. Compare emisor del informe, dominio, identificador, periodo y contenido. Una retransmisión idéntica no debe aumentar el total. Si los periodos se solapan parcialmente, quizá no haya detalle suficiente para descontar la parte común con exactitud. Documente esa limitación en lugar de ofrecer un total con una precisión injustificada. [1]
Superar SPF no siempre significa superar DMARC
auth_results contiene los resultados individuales de SPF y DKIM. policy_evaluated refleja su evaluación para DMARC, incluida la alineación de dominios. Compárelos con header_from, el dominio del remitente visible. Un resultado técnico positivo para el dominio del proveedor de envío no basta si falta la relación exigida con su dominio visible.
DMARC se supera cuando al menos SPF o DKIM tiene éxito y está alineado con el dominio From visible. Por tanto, SPF puede fallar mientras DMARC se supera mediante una firma DKIM válida y alineada. Un mensaje puede llevar varias firmas DKIM con resultados distintos. Busque la comprobación correcta y alineada; un «fail» aislado no determina el resultado general. [1] [2]
Delimitar el informe
Identificar emisor del informe, dominio, periodo e identificador; excluir copias duplicadas.
Identificar el envío
Comparar origen, SPF/DKIM y alineación con el inventario de servicios autorizados.
Aclarar la diferencia
Corregir un fallo legítimo, investigar un origen desconocido o documentar la observación.
Una decisión con evidencias
Registrar responsable, vía comprobada y próxima revisión. Verificar la entrega por separado.
Proceso explicativo sin datos reales de mensajes ni clientes. Un resultado DMARC y una prueba de entrega son evidencias distintas.
Interpretar las combinaciones habituales
La tabla se refiere a SPF y DKIM dentro de policy_evaluated, no a los resultados brutos de auth_results. Sirve para interpretarlos. No acredita la autorización de un servicio concreto ni la fiabilidad del contenido del mensaje. [1] [2]
Deslice la tabla horizontalmente para leerla.
| Resultado registrado | Interpretación | Siguiente paso |
|---|---|---|
| SPF pass, DKIM pass | Ambas vías superan la evaluación DMARC. | Relacionar el origen con un servicio de envío autorizado. |
| SPF fail, DKIM pass | DMARC se supera mediante DKIM. | Investigar por separado la diferencia SPF y posibles reenvíos. |
| SPF pass, DKIM fail | DMARC se supera mediante SPF. | Revisar DKIM; SPF por sí solo es menos resistente a los reenvíos. |
| SPF fail, DKIM fail | No hay una vía de autenticación correcta y alineada. | Distinguir mala configuración legítima, reenvío y uso no autorizado. |
| Resultado ausente o ilegible | El registro no permite una evaluación fiable. | Revisar formato y procesamiento; no contarlo como cero fallos. |
Una IP desconocida necesita atribución
El nombre de un proveedor o la ubicación de un centro de datos no demuestra quién inició un envío concreto. Una infraestructura compartida puede transportar correo de muchos clientes. Compare el origen con los servicios realmente autorizados: buzones, formularios web, facturación, soporte y boletines necesitan entradas separadas en el inventario.
Los dominios, selectores DKIM, registros de envío y un mensaje recibido de forma controlada ayudan a identificar la vía. No añada una IP desconocida a SPF para hacer desaparecer una advertencia. Confirme primero que está autorizada. Si falla un servicio legítimo, asigne la corrección a una persona y determine qué evidencia deberá aportar la nueva prueba. Un envío correcto desde el webmail no valida el formulario del sitio. [2] [4]
«none» no demuestra recepción en la bandeja de entrada
disposition describe el tratamiento registrado en la evaluación DMARC. none no es una prueba de entrega; quarantine no identifica de forma fiable la carpeta final de un mensaje concreto. Los receptores pueden aplicar otras reglas. Incluso superar DMARC no garantiza la bandeja de entrada ni un contenido fiable. Para investigar un correo perdido, examine registros de envío, notificaciones de devolución y, si existe, el original recibido.
Los informes solo muestran la perspectiva de los sistemas que informan durante el intervalo indicado. La falta de informes o los huecos de datos no equivalen a cero envíos ni a cero abusos. Documente la carencia. Para analizar tendencias, compare periodos de igual duración con los mismos emisores de informes y compruebe si cambió la cobertura. [1] [4]
Convertir el hallazgo en una tarea concreta
Actúe si una vía autorizada importante para el negocio no supera DMARC o cambia sus resultados sin explicación. Los orígenes desconocidos recurrentes necesitan atribución. La medida depende de las evidencias; no consiste automáticamente en endurecer o suavizar una política DNS. Antes de cambiarla, inventaríe y compruebe los servicios legítimos y corrija los fallos de autenticación conocidos. [2]
- Comprobar emisor del informe, dominio, periodo UTC y duplicados.
- Separar resultados brutos SPF/DKIM de la alineación DMARC.
- Relacionar el origen inesperado con un servicio y una persona responsable.
- Revisar un mensaje de prueba autorizado, cabeceras y registros pertinentes.
- Definir corrección, ventana de cambio y procedimiento de reversión.
- Comprobar por separado autenticación y entrega después del cambio.