A veces, incluso un pequeño detalle, como un guion en tu correo electrónico, puede marcar una gran diferencia. Si buscas respuestas sobre el uso del signo menos,...
Puntos Clave
- El XML sin formato se formatea intencionadamente para su procesamiento automático. La forma más rápida de obtener valor es analizar los informes y convertirlos en una tabla de fuentes y resultados; manualmente para revisiones ocasionales o mediante un analizador DMARC para una monitorización continua.
- El método más eficaz para bloquear los correos electrónicos desechables es el bloqueo en tiempo real en el formulario de registro mediante una API de validación que comprueba si se utiliza una lista de dominios desechables actualizada periódicamente.
- El objetivo de la lectura de informes es operativo: inventariar a cada remitente, confirmar que los legítimos cumplen con los requisitos de validación e identificar las fuentes no autorizadas o mal configuradas antes de endurecer las políticas.
- Los informes "aburridos" (tasas de aprobación consistentes de remitentes conocidos sin sorpresas) son la señal de que es seguro pasar de p=ninguno a p=cuarentena y p=rechazo.
Entre 24 y 72 horas después de publicar un registro DMARC, llega el primer informe agregado, que revela inmediatamente todos los servidores legítimos y no autorizados que enviaron correo electrónico como su dominio durante ese período. El problema, como se documenta en DMARC.orgLa especificación del protocolo establece que estos informes son archivos XML con formato de máquina, diseñados para analizadores automatizados, no para lectores humanos.
Saber leer los informes DMARC transforma esos datos brutos en inteligencia operativa. La visibilidad es realmente valiosa, pero solo después de que el XML se decodifica en algo que se pueda utilizar. estadísticas de spam de correo electrónico Demuestra por qué esa visibilidad es importante: la suplantación de identidad y la falsificación son comunes, por lo que necesitas informes DMARC para identificar qué fuentes envían correos electrónicos en nombre de tu dominio.
Cómo leer los informes DMARC
La primera lectura tarda entre 15 y 30 minutos. Las lecturas posteriores de los mismos remitentes tardan entre 2 y 3 minutos una vez que el patrón resulta familiar. Los pasos que se describen a continuación explican cómo generar un informe agregado DMARC completo, de principio a fin.
Aquí hay un fragmento XML anonimizado que ilustra la estructura del informe utilizada en los pasos de revisión que se describen a continuación:
<?xml version="1.0" encoding="UTF-8" ?>
<feedback>
<report_metadata>
<org_name>google.com</org_name>
<email>[email protected]</email>
<report_id>10296513920663916120</report_id>
<date_range>
<begin>1716768000</begin>
<end>1716854400</end>
</date_range>
</report_metadata>
<policy_published>
<domain>yourdomain.com</domain>
<adkim>r</adkim>
<aspf>r</aspf>
<p>none</p>
<pct>100</pct>
</policy_published>
<record>
<row>
<source_ip>209.85.220.41</source_ip>
<count>847</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>pass</dkim>
<spf>pass</spf>
</policy_evaluated>
</row>
<auth_results>
<dkim>
<domain>yourdomain.com</domain>
<result>pass</result>
</dkim>
<spf>
<domain>yourdomain.com</domain>
<result>pass</result>
</spf>
</auth_results>
</record>
<record>
<row>
<source_ip>198.51.100.23</source_ip>
<count>312</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>fail</dkim>
<spf>fail</spf>
</policy_evaluated>
</row>
<auth_results>
<dkim>
<domain>unknownsender.net</domain>
<result>fail</result>
</dkim>
<spf>
<domain>unknownsender.net</domain>
<result>fail</result>
</spf>
</auth_results>
</record>
</feedback>Paso 1: Configure una bandeja de entrada o un servicio para recibir informes.
Confirme que una bandeja de entrada dedicada está recopilando informes en la dirección especificada en la etiqueta rua= de su registro DMARC (por ejemplo, sales@costex.comLos proveedores de correo electrónico envían informes agregados diariamente, por lo que incluso un dominio con poco tráfico acumula docenas de archivos XML al mes; por lo tanto, una bandeja de entrada compartida general se vuelve rápidamente inmanejable.
Para dominios pequeños con necesidades de revisión ocasionales, un buzón dedicado funciona bien. Para informes que superen unos pocos por semana, o para organizaciones que administran varios dominios, configure la etiqueta rua= para que apunte a la dirección de entrada de un analizador DMARC para su análisis automatizado.
Paso 2: Abra y descomprima el archivo XML.
Descargue el archivo adjunto del correo electrónico del informe. La mayoría de los informes llegan como archivos .xml.gz o .zip que requieren descompresión (en macOS y Linux, haga doble clic o use gunzip; en Windows, haga clic con el botón derecho y seleccione "Extraer").
Abre el archivo .xml resultante en cualquier editor de texto, como VS Code, Sublime Text o Notepad++. También puedes abrirlo en un navegador, lo que suele facilitar la lectura del XML, ya que las secciones aparecen como nodos desplegables en lugar de un único bloque de texto.
Para consultar un informe de vez en cuando, abrir el archivo XML manualmente es suficiente. Si recibe varios informes por semana, utilice un analizador automatizado. Los informes DMARC siguen una estructura consistente, por lo que las herramientas pueden convertir el XML en tablas y resúmenes mucho más rápido.
Paso 3: Identificar la organización informante y la política
Localiza el Bloque ubicado en la parte superior del archivo. Identifica la organización que genera el informe (Google, Microsoft, Yahoo, Mail.ru u otras) y las marcas de tiempo Unix del inicio y el final del período del informe. Al convertir estas marcas de tiempo a fechas legibles, se confirma el período de 24 horas que abarca el informe.
Localiza el Bloquea inmediatamente después. Muestra la política DMARC que estuvo activa durante el período del informe (p=ninguna, p=cuarentena o p=rechazo) y los modos de alineación para SPF (aspf) y DKIM (adkim). El valor r significa alineación relajada; s significa estricta.
Confirme que la política que se muestra en el informe coincide con la que muestra actualmente su registro DNS. Si no coincide, significa que el informe abarca un período anterior a la propagación de un cambio de política reciente, lo cual es normal y no representa un problema; simplemente proporciona contexto para interpretar los resultados.
Paso 4: Revise cada fuente de envío en la sección de registros.
Desplázate hacia la bloques. Cada registro representa una IP emisora y sus resultados, agrupados por número de mensajes. En el fragmento anterior, 209.85.220.41 envió 847 mensajes y superó la verificación DMARC; 198.51.100.23 envió 312 mensajes y falló tanto en SPF como en DKIM.
Para cada registro, capture el y La dirección IP identifica qué servidor afirmó enviar mensajes en nombre de su dominio, mientras que el recuento muestra cuántos mensajes provinieron de ese servidor durante el período del informe.
Realice una búsqueda DNS inversa en cada dirección IP de origen desconocida. Los remitentes legítimos se resuelven a nombres de host reconocibles (mail-sor-f41.google.com para Gmail, sendgrid.net para SendGrid y amazonses.com para AWS SES). Las direcciones IP no reconocidas requieren investigación antes de asumir que son legítimas.
Paso 5: Verifique la alineación de SPF y DKIM para cada remitente.
Dentro de cada registro, encontrará el Bloque. Contiene el resultado SPF y el resultado DKIM para esa IP de origen, junto con el dominio que evaluó cada método de autenticación.
DMARC requiere que solo uno de SPF o DKIM pase en modo alineado para que el mensaje general pase DMARC. Este campo muestra el veredicto final (ninguno, cuarentena o rechazo) en función de la política vigente durante el período de informe.
Marca cualquier registro donde tanto SPF como DKIM muestren fallos, y se supone que el remitente es legítimo. Se trata de un remitente mal configurado que debe corregirse antes de que la política pueda endurecerse de forma segura. Un registro que muestre spf=fail pero dkim=pass generalmente no presenta problemas, ya que el mensaje sigue pasando la verificación DMARC en general.
Qué información proporciona cada campo XML en un informe DMARC.
Los informes agregados de DMARC siguen la RFC 7489. Todos los informes compatibles utilizan la misma estructura, independientemente del proveedor de correo electrónico que los haya enviado. Utilice esta referencia de campo durante cualquier revisión de informes:
- — La organización que realiza la denuncia (Google, Microsoft, Yahoo, etc.). Confirma qué proveedor de correo electrónico envió el informe. Los grandes proveedores suelen enviar informes separados por dominio.
- — Marcas de tiempo Unix para el inicio y el final del período cubierto. La mayoría de los informes cubren un período de 24 horas, aunque algunos proveedores envían informes con menos frecuencia.
- — la política DMARC activa durante la ventana (etiqueta p) más los modos de alineación para SPF (aspf) y DKIM (adkim). La alineación relajada (r) permite que los subdominios cumplan con la alineación; la estricta (s) requiere una coincidencia exacta.
- — la dirección IP que envió los mensajes. Utilice DNS inverso para identificar el servicio remitente.
- — el número de mensajes enviados desde esta dirección IP de origen durante el período del informe. Un número elevado de mensajes provenientes de direcciones IP desconocidas es una señal de alerta.
- — El veredicto final de DMARC: ninguno (no se tomó ninguna medida), cuarentena (enviado a la carpeta de spam) o rechazo (devuelto).
- — Los resultados de SPF y DKIM para el origen. Cada uno muestra el dominio autenticado y un veredicto de aprobado/reprobado. La coincidencia entre el dominio autenticado y el dominio de origen es lo que determina si DMARC se supera en general, no solo si SPF o DKIM se superan de forma aislada.
Qué buscar en los informes DMARC
Una vez que conozca estos cuatro patrones, los informes DMARC serán mucho más fáciles de leer. En lugar de examinar una gran cantidad de XML, podrá clasificar cada registro en una categoría clara.
Remitentes legítimos que muestran dmarc=pass
Si un remitente conocido, como su proveedor de servicios de correo electrónico (ESP), plataforma de marketing, servicio de asistencia técnica o CRM, aparece en el informe con los atributos dkim=pass y spf=pass, significa que la configuración funciona correctamente para esa fuente.
Verifique que la dirección IP de origen pertenezca al proveedor esperado mediante DNS inverso, especialmente para registros con un número elevado de direcciones. Se espera un gran volumen de correo proveniente de una IP conocida con dmarc=pass. Confírmelo una vez y luego utilícelo como referencia para informes futuros.
Fuentes sospechosas con un elevado número de mensajes.
Las direcciones IP desconocidas que envían cientos o miles de mensajes con dmarc=fail se dividen en dos categorías: remitentes no autorizados que suplantan activamente su dominio o un remitente legítimo olvidado (una antigua herramienta de marketing, una integración de TI en la sombra) que nunca se autenticó correctamente.
Investiga consultando los registros WHOIS de IP y DNS inverso. Una IP de spam conocida suele indicar suplantación de identidad, mientras que una plataforma SaaS olvidada suele indicar un problema de autenticación. Estos dos casos requieren respuestas diferentes: bloquear o rechazar el correo falsificado, pero corregir la configuración SPF o DKIM para remitentes legítimos.
SPF falla, pero DKIM pasa: normalmente reenvío
Un mensaje que no supera la verificación SPF pero sí la DKIM suele indicar un reenvío de correo electrónico. El servidor de reenvío no figura en el registro SPF del remitente original, por lo que SPF falla. Sin embargo, DKIM funciona de manera diferente. Firma las cabeceras del mensaje, y esa firma suele permanecer intacta cuando se reenvía el correo. Por eso, DKIM puede seguir funcionando incluso cuando SPF falla.
DMARC se ejecuta correctamente siempre que SPF o DKIM coincidan, por lo que estos registros no representan un problema. Para dominios con destinatarios que utilizan el reenvío de correo, este comportamiento es el esperado. El informe muestra cómo el reenvío afecta la autenticación, no un fallo en la configuración de DMARC.
Picos repentinos de volumen provenientes de direcciones IP desconocidas: generalmente se trata de suplantación de identidad.
Una IP desconocida que de repente envía un gran volumen de mensajes con fallos tanto en SPF como en DKIM es la señal clásica de suplantación de identidad. Alguien está enviando correos electrónicos haciéndose pasar por tu dominio a través de su propia infraestructura, intentando eludir los filtros de spam mediante el uso indebido de las señales de confianza de tu dominio.
Verifique la IP en herramientas de inteligencia de amenazas como AbuseIPDB o Cisco Talos. Si la IP está vinculada a spam o abuso, es probable que el pico sea malicioso. Es entonces cuando cambiar a p=reject se vuelve importante. Una vez que todos los remitentes legítimos estén alineados, la aplicación completa ayuda a bloquear el correo falsificado antes de que pueda dañar su cuenta. reputación del remitente de correo electrónico.
Herramientas para analizar y visualizar informes DMARC
La mayoría de los equipos pasan de la revisión manual de XML a un analizador automatizado durante la primera semana de recibir informes. La elección depende del volumen, el presupuesto y la profundidad del análisis requerido.
Para la mayoría de los equipos que se inician en este campo, MXToolbox para comprobaciones manuales ocasionales y Postmark DMARC Digests para monitorización pasiva constituyen una combinación práctica y gratuita. Se recomienda utilizar un analizador especializado como DMARCian cuando el número de dominios o el volumen de informes diarios hagan que la revisión manual resulte inviable.
De los informes a la acción: cuándo endurecer su política
Leer los informes DMARC solo es útil si se utilizan para tomar decisiones. El proceso es sencillo: identificar a todos los remitentes, corregir los problemas de alineación y, a continuación, proceder a la aplicación de la normativa.
- Fase de inventario (semanas 1-4 en p=ninguno): Identifique todas las fuentes legítimas que envían mensajes como su dominio. Si alguna fuente necesita trabajo de alineación, complete el SPF, DKIM y DMARC preparación antes de pasar a la aplicación de la ley.
- Fase de alineación (semanas 4-8 en p=ninguno): Confirme que todas las fuentes legítimas cumplan con los requisitos de SPF o DKIM, alineándose con el dominio del remitente. Corrija las que no los cumplan agregando la fuente a SPF, habilitando la firma DKIM o ambas cosas. El objetivo antes de aplicar medidas coercitivas es lograr tasas de aprobación superiores al 95 % para todos los remitentes legítimos durante varios ciclos de informes consecutivos.
- Fase de aplicación (semana 8+ en p=cuarentena, luego p=rechazo): Una vez que los informes muestren una alineación consistente sin fallos de alto volumen por parte de remitentes legítimos, pase a p=cuarentena. Permanezca allí durante 2 a 4 semanas y continúe el monitoreo. Luego, avance a p=rechazo. Mantenga el monitoreo en p=rechazo, ya que los nuevos remitentes agregados a la pila pueden introducir nuevos fallos de alineación.
Combine el ajuste de listas con una sólida higiene de listas en todo momento. La autenticación confirma que el correo electrónico proviene de usted, mientras que las listas limpias evitan las tasas de rebote que dañan la reputación independientemente del estado de autenticación. Validar las listas antes de los envíos importantes mantiene las tasas de rebote bajo control, y Limpiando tu lista de correo electrónico La eliminación de contactos obsoletos o inválidos protege las señales de reputación que respaldan cada etapa del avance de la política.
Cómo convertir los datos de DMARC en decisiones
Los informes agregados de DMARC contienen datos operativos. El objetivo no es analizarlos teóricamente, sino actuar en función de lo que revelan. Corrija los remitentes legítimos que no cumplan con los requisitos de alineación. Investigue las direcciones IP desconocidas. Implemente medidas coercitivas una vez que sus fuentes de confianza funcionen correctamente.
El objetivo es un informe sin sobresaltos: fuentes conocidas, tasas de aprobación constantes y ausencia de picos repentinos de tráfico provenientes de direcciones IP desconocidas. Esta previsibilidad es lo que hace que p=reject sea seguro, y p=reject es lo que protege su dominio contra la suplantación de identidad.
Como parte de la fase de alineación, valida tus listas de envío con DeBounce. Validación de listas de correo electrónico Elimina las direcciones no válidas, desechables y de alto riesgo de las listas que alimentan tus flujos de envío autenticados, lo que mantiene bajas las tasas de rebote y protege la reputación que estás construyendo mediante la autenticación. Sube tu lista, elimina lo que no corresponde y envía con la seguridad de que la autenticación y los datos limpios funcionan en conjunto.
