Antes de endurecer tu política de DMARC, identifica los sistemas que envían correo legítimo usando tu dominio. Los informes pueden revelar un remitente que necesita cambios de autenticación antes de que la aplicación de la política bloquee su correo.
¿Qué tipo de informe debes usar?
Usa informes agregados para comparar fuentes de envío y resultados de autenticación durante un período de reporte. La dirección rua en tu registro DMARC solicita estos resúmenes XML a los receptores participantes.
La dirección ruf solicita informes individuales de fallos, a veces llamados informes forenses. Usan un formato de reporte de fallos de autenticación y pueden contener encabezados o contenido del mensaje. Los receptores pueden redactarlos u omitirlos porque ese contenido puede exponer información personal. Las reglas de reporte de RFC 7489 describen los dos tipos de informe.
Los informes agregados cubren el tráfico que cada receptor observó. Un informe ausente no prueba que ningún mensaje haya usado tu dominio. La explicación del registro DMARC cubre dónde configurar las direcciones de reporte.
¿Qué contiene un informe agregado?
Un informe agregado identifica la organización que reporta, el período de reporte y la política publicada, seguidos de registros que agrupan mensajes con características compartidas. Una IP de origen puede aparecer en varios registros cuando sus resultados de autenticación u otros campos de agrupación difieren.
Este extracto ilustrativo conserva los campos necesarios para comparar una fuente con sus resultados de autenticación:
<report_metadata>
<org_name>google.com</org_name>
<date_range><begin>1718323200</begin><end>1718409600</end></date_range>
</report_metadata>
<policy_published>
<domain>example.com</domain>
<p>none</p>
</policy_published>
<record>
<row>
<source_ip>203.0.113.10</source_ip>
<count>42</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>pass</dkim>
<spf>pass</spf>
</policy_evaluated>
</row>
<identifiers><header_from>example.com</header_from></identifiers>
<auth_results>
<dkim><domain>example.com</domain><result>pass</result></dkim>
<spf><domain>example.com</domain><result>pass</result></spf>
</auth_results>
</record>Este registro representa 42 mensajes de 203.0.113.10 usando example.com en la dirección From visible. Ambos métodos de autenticación pasaron y se alinearon. El receptor no aplicó ninguna acción de DMARC a esos mensajes; esto no determina su ubicación en la bandeja de entrada.
¿Qué campos identifican un problema de autenticación?
Compara policy_evaluated con auth_results para distinguir un fallo de autenticación de un fallo de alineación de dominio.
| Campo | Qué revisar |
|---|---|
source_ip | Identifica el servidor de envío y el servicio responsable. |
count | Cuenta los mensajes representados por este registro, no por el informe completo. |
header_from | Confirma el dominio mostrado al destinatario. |
disposition | Revisa si el receptor aplicó none, quarantine o reject. |
dkim y spf en policy_evaluated | Revisa si cada método pasó y se alineó para DMARC. |
auth_results | Compara los resultados brutos de autenticación y los dominios que autenticaron. |
Por ejemplo, SPF puede pasar en auth_results pero fallar en policy_evaluated cuando su dominio autenticado no se alinea con el dominio From. Un pase alineado de DKIM aún puede hacer que ese mensaje pase DMARC. Cómo funciona DMARC explica esa relación.
¿Qué debes hacer con cada fuente de envío?
Asocia cada fuente con un servicio que autorices antes de cambiar la política. Los resultados de autenticación por sí solos no te dicen si tu organización pretendía que ese servicio enviara correo.
- Para un remitente conocido que pasa y se alinea, confirma que su volumen reportado coincide con el tráfico que esperas.
- Para un remitente conocido que falla, corrige su autenticación o alineación y revisa informes posteriores para ver el resultado.
- Para un remitente desconocido que pasa, identifica quién lo configuró y si debe conservar la autorización.
- Para un remitente desconocido que falla, investiga si es un servicio legítimo mal configurado o un uso no autorizado de tu dominio.
Resuelve los fallos legítimos antes de pasar de monitoreo a cuarentena o rechazo, porque esos mensajes serían candidatos a aplicación de la política. Corregir fallos de DMARC cubre las causas comunes.
¿Cómo inspeccionas los informes de un dominio de envío de Bird?
Puedes dirigir los informes agregados a tu propio buzón mediante la dirección rua en tu registro DMARC. Usa el analizador de informes de DMARC para inspeccionar el XML, o abre un informe en un editor de texto.
La verificación DNS de Bird comprueba tu política publicada; los informes de los receptores describen resultados de autenticación para los mensajes. Son comprobaciones separadas. La guía de autenticación cubre la política y los registros DNS que debes publicar.