¿Cómo se distingue en un reporte DMARC el correo propio, el de terceros y la suplantación?

Por la IP de origen, su DNS inverso y los dominios de auth_results. Tu proveedor principal aparece con DKIM alineado en pass. Un tercero legítimo (CRM, facturación, newsletter) suele pasar DKIM o SPF, pero con su propio dominio, así que no alinea. El reenvío rompe SPF y a veces conserva DKIM. La suplantación viene de IPs sin relación contigo y falla todo.

← Todos los artículos

Reportes DMARC (rua): qué dicen y cómo los usa un sistema de correo profesional

Q: ¿Qué es el rua de DMARC y para qué sirve?

rua es la etiqueta del registro DMARC que dice a qué dirección deben mandar los receptores sus reportes agregados. Sirve para ver, con datos de Gmail, Outlook, Yahoo y otros, qué servidores enviaron correo con tu dominio en el From y si pasaron SPF y DKIM alineados. Sin esos reportes, cambiar la política de p=none a quarantine o reject es apostar a ciegas.

Q: ¿Qué trae un reporte agregado de DMARC?

Un XML con tres partes: report_metadata (quién lo manda, un report_id y el rango de fechas), policy_published (la política que el receptor leyó en tu DNS) y una lista de record. Cada record agrupa los mensajes de una IP de origen: cuántos fueron (count), qué hizo el receptor (disposition), si DKIM y SPF pasaron alineados (policy_evaluated), el dominio del From (header_from) y los dominios que realmente firmaron o pasaron SPF (auth_results). No trae asuntos, destinatarios ni contenido.

Q: ¿Quién manda los reportes DMARC y en qué formato llegan?

Los grandes receptores de correo, como Google, Microsoft y Yahoo, mandan uno al día por cada dominio que les envió correo. Llega como un correo normal a la dirección del rua, con el XML comprimido en .zip o .gz como adjunto. Si la dirección está en otro dominio, ese dominio debe autorizarlo con un TXT en ._report._dmarc. que contenga v=DMARC1.

Q: ¿Cómo procesa los reportes DMARC un sistema de correo profesional?

Los recibe en una dirección dedicada, extrae el XML con topes de tamaño antes y después de descomprimir (contra bombas de compresión), descarta duplicados por la pareja reportero + report_id, guarda los conteos por IP de origen, resuelve el DNS inverso de cada IP para saber quién es y manda un resumen semanal con el porcentaje alineado y las fuentes que fallan.

Q: ¿Cuándo se puede subir de p=none a quarantine y a reject?

Cuando los reportes lo demuestran: un criterio razonable es dos semanas seguidas con 99 % o más de los mensajes alineados y ninguna fuente legítima fallando. Entonces se pasa a p=quarantine subiendo pct de 25 a 100, y con otras dos semanas limpias a p=reject. Si una fuente legítima empieza a fallar, se baja un escalón y se corrige esa fuente.

📅 5 Oct 2026 ⏱ 9 min de lectura

Un buzón rojo con máscara de lucha libre recibe sobres con gráficas de barras y, al lado, una hoja de reporte revisada con lupa

Casi todos los registros DMARC que se ven en la práctica dicen lo mismo: v=DMARC1; p=none. La política existe, pero no hace nada. Y muchos ni siquiera llevan la parte que la vuelve útil: el rua, la dirección a la que Gmail, Outlook y Yahoo mandan cada día un reporte de quién está enviando correo con tu dominio.

Este artículo es sobre esos reportes: qué traen línea por línea, cómo se procesan sin abrirle la puerta a un archivo malicioso, cómo se separa el correo propio del de terceros y de la suplantación, y cómo se usan para subir la política a quarantine y reject con datos en vez de con fe. Si las siglas son nuevas, empieza por qué son DKIM, SPF y DMARC.

¿Qué es el rua de DMARC y para qué sirve?

El rua es la etiqueta del registro DMARC que le dice a los receptores a dónde mandar sus reportes agregados. Cada receptor grande que recibió correo con tu dominio en el From te manda, una vez al día, el resumen de lo que vio: qué IPs enviaron, cuántos mensajes y si pasaron SPF y DKIM alineados.

Se declara en el mismo TXT de _dmarc:

_dmarc.ejemplo.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@ejemplo.com"

Sirve para una sola cosa, pero es la que importa: saber qué se rompería antes de endurecer la política. Con p=reject el receptor tira todo lo que no alinea, incluida la factura que manda tu sistema contable con tu dominio si nadie lo configuró bien. Sin reportes, eso lo descubres cuando un cliente dice que no le llegó nada.

¿Qué trae un reporte agregado de DMARC?

Un XML con quién lo manda, la política que leyó en tu DNS y una fila por cada IP que envió correo como tu dominio. No trae asuntos, destinatarios ni contenido: son conteos. Por eso se llama agregado, y por eso los receptores grandes sí lo mandan.

Este es un reporte realista de un día, recortado a tres filas que muestran los tres casos que importan (las IPs son de documentación):

<feedback>
  <report_metadata>
    <org_name>google.com</org_name>
    <email>noreply-dmarc-support@google.com</email>
    <report_id>10394882716253948172</report_id>
    <date_range><begin>1790985600</begin><end>1791071999</end></date_range>
  </report_metadata>
  <policy_published>
    <domain>ejemplo.com</domain>
    <adkim>r</adkim><aspf>r</aspf>
    <p>none</p><sp>none</sp><pct>100</pct>
  </policy_published>

  <!-- 1. Tu proveedor principal: DKIM alineado, todo bien -->
  <record>
    <row>
      <source_ip>198.51.100.23</source_ip>
      <count>412</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>pass</dkim><spf>fail</spf>
      </policy_evaluated>
    </row>
    <identifiers><header_from>ejemplo.com</header_from></identifiers>
    <auth_results>
      <dkim><domain>ejemplo.com</domain><result>pass</result></dkim>
      <spf><domain>amazonses.com</domain><result>pass</result></spf>
    </auth_results>
  </record>

  <!-- 2. Un CRM legítimo que firma con su propio dominio: no alinea -->
  <record>
    <row>
      <source_ip>203.0.113.10</source_ip>
      <count>120</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>fail</dkim><spf>fail</spf>
      </policy_evaluated>
    </row>
    <identifiers><header_from>ejemplo.com</header_from></identifiers>
    <auth_results>
      <dkim><domain>crm-proveedor.com</domain><result>pass</result></dkim>
      <spf><domain>bounce.crm-proveedor.com</domain><result>pass</result></spf>
    </auth_results>
  </record>

  <!-- 3. Alguien haciéndose pasar por ti -->
  <record>
    <row>
      <source_ip>192.0.2.77</source_ip>
      <count>38</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>fail</dkim><spf>fail</spf>
      </policy_evaluated>
    </row>
    <identifiers><header_from>ejemplo.com</header_from></identifiers>
    <auth_results>
      <spf><domain>ejemplo.com</domain><result>fail</result></spf>
    </auth_results>
  </record>
</feedback>

Cómo se lee cada bloque:

Elemento	Qué dice	Para qué sirve
`report_metadata`	Quién manda el reporte, su `report_id` y el rango de fechas en segundos Unix.	La pareja `org_name` + `report_id` identifica al reporte: es la llave para no contarlo dos veces.
`policy_published`	El registro `_dmarc` tal como lo leyó el receptor: `p`, `sp`, `pct` y el modo de alineación.	Confirma que el receptor ve lo que crees que publicaste. Un cambio de DNS tarda en aparecer aquí.
`source_ip` + `count`	Desde qué IP salieron y cuántos mensajes fueron.	Es la unidad de análisis: todo se agrupa por fuente.
`policy_evaluated`	Lo que hizo el receptor (`disposition`: `none`, `quarantine`, `reject`) y si DKIM y SPF pasaron alineados.	Es lo que decide DMARC. Basta con que uno de los dos sea `pass` para que el mensaje pase.
`header_from`	El dominio del `From` visible.	Separa tu dominio de sus subdominios, que pueden tener otra política (`sp`).
`auth_results`	Los resultados crudos: qué dominio firmó DKIM y qué dominio pasó SPF, alineen o no.	Explica el porqué de un fallo: dice quién firmó en vez de ti.

La fila 1 enseña la trampa más común. SPF dice pass en auth_results pero fail en policy_evaluated: pasó para amazonses.com, el dominio del sobre, que no es el tuyo. Pasar no es alinear. Como DKIM sí firmó con ejemplo.com, el mensaje pasa DMARC de todos modos.

¿Quién manda los reportes DMARC y en qué formato llegan?

Los grandes receptores, como Google, Microsoft y Yahoo, mandan uno al día por dominio, como correo normal con el XML comprimido en .zip o .gz adjunto. Un dominio que envía a muchos proveedores distintos recibe varios cada día; uno chico, dos o tres.

El adjunto tiene un nombre con forma fija, receptor!dominio!inicio!fin.xml.gz, y el asunto dice Report Domain: ejemplo.com Submitter: google.com. Ninguno de los dos es confiable para procesar: hay reporteros que mandan un .zip declarado como application/octet-stream. Lo que sí es confiable son los primeros bytes del archivo.

Hay dos tipos de reporte, y conviene no confundirlos:

	`rua` (agregado)	`ruf` (de fallo)
Qué trae	Conteos por IP: cuántos pasaron y cuántos no.	Un mensaje individual que falló, a veces con encabezados o partes del contenido.
Cada cuándo	Uno al día por receptor.	Uno por fallo, casi en tiempo real.
Quién lo manda	Prácticamente todos los receptores grandes.	Muy pocos: Gmail y Outlook.com no los mandan, por privacidad.
Para qué sirve	Decidir la política con datos.	Depurar un caso concreto, cuando llega.

La etiqueta fo=1 pide reporte de fallo cuando falla cualquiera de los dos mecanismos, en vez de sólo cuando fallan los dos (el valor por defecto, fo=0). Ojo: fo sólo afecta a ruf. Ponerla no cambia en nada los reportes agregados.

Si el rua apunta a otro dominio, por ejemplo un servicio de análisis, el receptor primero verifica que ese dominio acepte tus reportes. Lo hace leyendo un TXT con un nombre construido así:

; En el DNS de ejemplo.com
_dmarc.ejemplo.com.                     TXT  "v=DMARC1; p=none; rua=mailto:dmarc@reportes-externos.com; fo=1"

; En el DNS de reportes-externos.com: autoriza recibir los de ejemplo.com
ejemplo.com._report._dmarc.reportes-externos.com.  TXT  "v=DMARC1"

Sin ese segundo registro los reportes no salen, y nadie te avisa. Si la dirección del rua está en tu mismo dominio no hace falta.

¿Cómo procesa los reportes DMARC un sistema de correo profesional?

Como datos no confiables que llegan de internet: con una dirección dedicada, topes de tamaño, deduplicación y agregación por fuente. Un archivo comprimido que cualquiera puede mandarte es exactamente la forma de una bomba de descompresión, y un reporte puede llegar dos veces.

Paso	Qué se hace	Por qué
1. Dirección dedicada	`dmarc@` separada de tu correo, procesada por código.	Son correos automáticos diarios; en una bandeja humana se ignoran en una semana.
2. Detectar el formato	Por la firma del archivo: `PK` es zip, `1F 8B` es gzip.	El nombre y el tipo MIME mienten con frecuencia.
3. Topes de tamaño	Un máximo para el adjunto, otro para lo descomprimido y otro de filas por reporte.	Un zip de kilobytes puede expandirse a gigas. El tope de lo descomprimido se aplica mientras se descomprime, no después.
4. Parsear sin sorpresas	XML sin entidades externas; números como texto.	Un `report_id` de 20 dígitos pierde precisión si se lee como número y deja de servir como llave.
5. Deduplicar	Llave única `(org_name, report_id)`.	Los reporteros reintentan; contar dos veces infla los números.
6. Guardar por fuente	Una fila por IP con mensajes, pasa y falla.	Las preguntas siempre son por fuente: ¿quién es esta IP y por qué falla?
7. Identificar	DNS inverso de cada IP, con caché y tiempo límite.	`a8-23.smtp-out.amazonses.com` dice más que `198.51.100.23`. Un PTR que no contesta no debe colgar el proceso.
8. Resumir	Un correo semanal con el porcentaje alineado, la semana anterior para comparar y las fuentes que fallan.	Un dato diario es ruido; la tendencia de dos semanas es lo que permite decidir.

Un error de un solo reporte nunca debe tumbar el resto. Se registra, se sigue con el siguiente adjunto, y el correo de reportes no comparte proceso crítico con el correo de verdad.

¿Cómo se distingue el correo propio, el de terceros y la suplantación?

Cruzando la IP de origen, su DNS inverso y los dominios de auth_results. Toda fuente cae en una de cuatro clases, y cada una pide una acción distinta. Confundirlas es la forma más común de romper correo legítimo al endurecer la política.

Clase	Cómo se ve en el reporte	Qué hacer
Tu envío principal	DNS inverso de tu proveedor; DKIM `pass` con tu dominio.	Nada. Es la línea base del porcentaje alineado.
Tercero legítimo (CRM, facturación, newsletter)	DNS inverso del proveedor; DKIM o SPF en `pass` pero con su dominio, así que no alinea.	Configurar en ese proveedor DKIM con tu dominio (o un Return-Path propio). Sin eso, `reject` le tira el correo.
Reenvío	IP de un servidor de correo conocido (una universidad, un buzón que reenvía a Gmail); SPF falla, DKIM a veces sobrevive.	No se arregla desde tu lado. Por eso DKIM es el que importa: sobrevive al reenvío, SPF no.
Suplantación	IPs sin relación contigo, sin DNS inverso o de redes residenciales; falla todo.	Nada que corregir: es justo lo que `quarantine` y `reject` van a detener.

El primer reporte de un dominio con algunos años suele dar sorpresas en la segunda fila: el formulario de la web que manda avisos con tu dominio, la plataforma de facturación electrónica, el sistema de citas. Encontrarlos es el punto de todo el ejercicio, y es mucho mejor encontrarlos en un reporte que en una queja.

¿Cuándo se puede subir de p=none a quarantine y a reject?

Cuando los reportes lo demuestran, no cuando pasa cierto tiempo. Un criterio razonable: dos semanas seguidas con 99 % o más de los mensajes alineados y ninguna fuente legítima fallando. Dos semanas, porque hay envíos que sólo salen una vez por semana o a fin de mes.

La etiqueta pct es lo que hace el paso intermedio seguro: pct=25 aplica quarantine a una cuarta parte de lo que falla y trata el resto como none. Los registros de cada escalón se ven así:

; Semana 0: observar
_dmarc.ejemplo.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@ejemplo.com"

; Puerta 1 cumplida: cuarentena gradual
_dmarc.ejemplo.com.  TXT  "v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@ejemplo.com"
_dmarc.ejemplo.com.  TXT  "v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc@ejemplo.com"

; Puerta 2 cumplida: rechazo
_dmarc.ejemplo.com.  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@ejemplo.com"

Dos detalles. El rua se queda en reject: es justo cuando un tercero nuevo que nadie configuró empezaría a perder correo en silencio. Y la revisión del estándar conocida como DMARCbis reemplaza pct por una bandera de prueba t=y; conviene revisar qué aceptan tus receptores cuando actualices el registro.

Qué hace MailMask con esto

Cuando conectas un dominio, MailMask te da los registros DNS que hacen falta, y el de DMARC viene incluido: v=DMARC1; p=none; rua=mailto:dmarc@tudominio. El correo que sale de MailMask va firmado con DKIM de tu propio dominio, que es lo que alinea. La dirección dmarc@ la creas como cualquier otra, para que los reportes no se mezclen con tu correo. Y si tu DNS vive en MailMask, la API y el MCP tienen una plantilla dmarc que escribe el registro por ti.

Si te interesa lo que pasa del otro lado, sigue con cómo evitar que tus correos caigan en spam o con la anatomía de un dominio en Amazon SES.

Resumen rápido

El rua te manda cada día, desde cada receptor grande, quién envió correo como tu dominio y si alineó.
Pasar no es alinear: SPF puede dar pass para el dominio de tu proveedor y aun así fallar DMARC. Lo que decide es policy_evaluated.
Procésalos como datos hostiles: dirección dedicada, firma del archivo, topes al descomprimir y llave única (org_name, report_id).
Clasifica cada fuente en propia, tercero legítimo, reenvío o suplantación. Sólo la segunda pide trabajo de tu lado.
Sube la política con una puerta: dos semanas ≥ 99 % alineado y cero fuentes legítimas fallando, pct gradual y el rua siempre puesto.