Puedes pedirle a los buzones que pongan en cuarentena o rechacen el correo que usa tu dominio y no pasa DMARC. Si publicas esa política antes de saber quién envía a tu nombre, la factura, el formulario del sitio o el boletín pueden rebotar. El reporte agregado, el de la etiqueta rua, es la lista que se lee primero, con la política todavía en p=none.

Qué trae un reporte agregado

DMARC está descrito en el RFC 7489. La etiqueta rua indica a qué casilla deben mandar el resumen. No es una copia de cada mensaje. Es un XML, casi siempre comprimido con gzip, que llega adjunto a un correo.

El asunto suele traer tres datos: Report Domain: (tu dominio), Submitter: (quién armó el reporte) y Report-ID:. El nombre del archivo sigue la forma receptor!tudominio.cl!inicio!fin.xml.gz. Esos números son segundos desde el 1 de enero de 1970, en UTC. El intervalo que puedes pedir con ri vale 86400 segundos si no lo escribes: un día. Quien genera reportes tiene que poder enviar ese resumen diario. Un intervalo más corto queda a su criterio.

El propio reporte, cuando viaja por correo, tiene que salir con DMARC alineado y en pass. Así reduces el riesgo de procesar un resumen falso.

No todos los buzones del mundo envían reportes. Los que participan te muestran el correo que les llegó con tu dominio en el campo De. El volumen que no pasa por ellos no aparece.

La etiqueta ruf es otra cosa: pide reportes de fallo, casi inmediatos, que pueden incluir cabeceras y trozos del mensaje. Esta guía usa solo rua. Deja ruf y fo fuera hasta que tengas claro qué datos salen de tu dominio y quién los va a leer.

Publica el registro en p=none

El registro es un TXT en el nombre _dmarc. En el panel sueles escribir _dmarc y la zona completa .tudominio.cl. Tiene que haber uno solo. Si quedan dos registros válidos, el RFC indica que el receptor no aplique política.

Crea antes la casilla que va a recibirlo. Si el buzón no existe, el primer reporte rebota y pierdes el día. Una dirección del mismo dominio, por ejemplo [email protected], evita un paso extra. Si rua apunta a otro dominio organizacional, ese dominio tiene que autorizarte: un TXT en tudominio.cl._report._dmarc.otrodominio que empiece con v=DMARC1. Sin ese TXT, el receptor ignora el destino. Una casilla gratuita en otro dominio no publica esa autorización por ti.

Un punto de partida, con los nombres de tu empresa:

_dmarc.tudominio.cl.  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]; adkim=r; aspf=r; pct=100"

p=none pide que no cambien la entrega por DMARC. adkim=r y aspf=r son la alineación relajada, que es el valor por defecto. pct=100 aplica esa política de monitoreo a todo el flujo. Comprueba el TXT con dig txt _dmarc.tudominio.cl +short.

Si el DNS está en el hosting, el registro se agrega en la zona. En cPanel está en Zone Editor. En DirectAdmin, en Administración DNS. Si ya existe _dmarc, edítalo. No agregues un segundo TXT.

Esa misma pantalla muestra el SPF. No lo reemplaces ahora. Tiene que haber un solo TXT que empiece con v=spf1. El ejemplo que trae el formulario no es el SPF de tu cuenta. Si el correo ya funciona, conserva el valor que está publicado.

Con la zona en Cloudflare, el TXT queda en Solo DNS: un TXT no se proxea. Si vas a copiar la zona, conserva el _dmarc que ya tengas. El detalle de MX, SPF, DKIM y DMARC está en la guía de Cloudflare delante del hosting.

Cómo se lee una fila

Abre el .xml.gz. Muchos clientes lo descomprimen al guardar el adjunto. Arriba vas a encontrar dos bloques y, después, una fila por cada grupo de mensajes parecidos.

BloqueQué anotar
report_metadataQuién envía el reporte, el identificador y el rango de fechas, en UTC
policy_publishedLa política que ese buzón vio: p, sp, pct, adkim y aspf
rowLa IP de origen (source_ip) y cuántos mensajes agrupa (count)
policy_evaluateddisposition (none, quarantine o reject) y si SPF y DKIM quedaron alineados
identifiersheader_from: el dominio del campo De
auth_resultsEl resultado crudo de SPF y de DKIM, y el dominio que se comprobó

disposition es lo que se hizo con tu política. Con p=none vas a ver none aunque la fila esté fallando: el RFC pide que esa política no cambie la entrega que el buzón ya iba a hacer. none no significa que el mensaje haya entrado a la bandeja. Para eso sigue sirviendo la guía de correos que llegan a spam.

Si cambias la política a mitad de un día, un mismo reporte puede mezclar el criterio viejo y el nuevo. El RFC lo admite. Juzga el cambio con el reporte del día siguiente, cuando policy_published ya muestre el valor nuevo.

Una misma IP puede salir en varias filas si los resultados no son iguales. Suma count para estimar el volumen. No cuentes filas.

SPF, DKIM y la alineación

DMARC pasa si al menos uno de estos dos mecanismos produce un pass y, además, el dominio de ese pass coincide con el dominio del campo De. Las dos condiciones van juntas. Un pass en el dominio de otro servicio no alcanza.

En el XML hay dos capas:

  • auth_results dice si la firma o el SPF salieron bien, y para qué dominio.
  • policy_evaluated dice pass solo cuando ese mecanismo pasó y quedó alineado con tu De. Si ves fail ahí y pass en auth_results, la comprobación fue de otro dominio.

La alineación relajada (r) compara el dominio organizacional. [email protected] y una firma DKIM con d=news.tudominio.cl quedan alineados. La estricta (s) exige el mismo nombre completo: en ese ejemplo, fallaría. Empieza con r. Pasa a s solo cuando cada envío legítimo use el nombre exacto.

SPF, para DMARC, mira el dominio del sobre (Mail From, el return-path), no el De que ve la persona y no el nombre del HELO. DKIM mira el d= de una firma que verifique. Si el mensaje trae varias firmas, basta con que una esté alineada y verifique.

Para DMARC solo cuenta un resultado pass. Un softfail o un fail no alinean el mensaje. ~all y -all dejan fuera del pass a quien no está en el SPF. La diferencia entre ambos se nota en receptores que miran SPF por su cuenta. El significado de cada mecanismo está en las guías de zona DNS de cPanel y de DirectAdmin.

Un reenvío suele romper el SPF: la IP que entrega ya no es la tuya. DKIM puede seguir verificando si el reenvío no tocó el mensaje. Por eso conviene una firma DKIM de tu dominio, además del include: de SPF. Quien reenvía correo de forma habitual puede implementar ARC. Yahoo lo recomienda para ese caso.

Tres filas y qué hacer con cada una

Este XML está abreviado y usa dominios e IP de documentación. 203.0.113.10, 198.51.100.20 y 192.0.2.50 no son servidores de Bitsur ni de un proveedor. No los copies a tu zona.

<record>
  <row>
    <source_ip>203.0.113.10</source_ip>
    <count>38</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>pass</dkim>
      <spf>pass</spf>
    </policy_evaluated>
  </row>
  <identifiers><header_from>tudominio.cl</header_from></identifiers>
  <auth_results>
    <dkim><domain>tudominio.cl</domain><result>pass</result><selector>default</selector></dkim>
    <spf><domain>tudominio.cl</domain><result>pass</result></spf>
  </auth_results>
</record>
Casillas del día a díaFacturadorOrigen que no reconoces
source_ip203.0.113.10198.51.100.20192.0.2.50
count3812400
header_fromtudominio.cltudominio.cltudominio.cl
DKIM en auth_resultspass, d=tudominio.clpass, d=facturador.examplefail
SPF en auth_resultspass, tudominio.clpass, bounce.facturador.examplefail
policy_evaluateddkim pass, spf passdkim fail, spf faildkim fail, spf fail
Con p=nonedisposition nonedisposition nonedisposition none

La primera fila está alineada. Son las casillas, si el volumen y la IP coinciden con tu correo. No la toques.

La segunda es el caso típico de un servicio legítimo. El facturador firma y autoriza su propio dominio, y el De que ve el cliente es el tuyo. DMARC falla. Si el calendario coincide con tus facturas, no lo bloquees: pídele al proveedor el include: de SPF que documenta y un DKIM con d= de tu dominio. Suele ser un CNAME en selector._domainkey. El selector sale en el reporte. Agrega el include: al SPF que ya tienes, en el mismo TXT.

La tercera no está en tu inventario, falla las dos comprobaciones y mueve mucho volumen. No agregues esa IP al SPF para forzar un pass. Ese tráfico es el que más adelante quieres rechazar. Mientras sigas en p=none, anótalo y compáralo al día siguiente. Si desaparece al cambiar una contraseña o al apagar un formulario, era una herramienta tuya. Si se mantiene y nadie en la empresa lo reconoce, es suplantación o una cuenta que no debería enviar.

Servicios que envían a nombre de tu dominio

Antes de endurecer la política, arma el inventario. La guía de correos a spam parte por el mismo listado: casilla, formulario, facturación, CRM y campaña. Anota quién lo administra, qué dirección aparece en el De y qué día sale correo.

Estas son las filas que una pyme suele encontrar:

  • Casillas. Webmail, Outlook y el celular. DKIM del correo y SPF del mismo servicio, con header_from de tu dominio. Si DKIM del hosting está apagado, la fila puede pasar solo por SPF, o fallar si el sobre usa otro nombre.
  • Formulario del sitio. A veces sale por el servidor del hosting y a veces por un servicio externo. Si el De es [email protected] y el SPF no incluye esa máquina, vas a ver fail. Confirma también que la respuesta al visitante use su dirección, no la tuya.
  • Facturación electrónica. El volumen sigue los días hábiles y el dominio DKIM es el del facturador, no el tuyo, hasta que actives la firma que ellos documentan.
  • CRM y boletín. Pasan lo mismo: pass en el dominio de la plataforma y fail en policy_evaluated, mientras el De siga siendo tu marca. El día del envío tiene que coincidir con la fila.

Para cada servicio que quieras conservar, pide tres datos por escrito. No inventes el valor a partir del nombre comercial.

  1. El include: o las IP que su documentación manda poner en el SPF.
  2. El DKIM de tu dominio: nombre (selector._domainkey) y si es CNAME o TXT. La firma tiene que usar d=tudominio.cl o un subdominio tuyo, no solo el dominio de ellos.
  3. La dirección exacta del De. Si usan boletas.tudominio.cl, esa fila va a mostrar ese header_from.

El SPF queda en un solo TXT. La forma, con los valores que te entreguen, se parece a esto:

v=spf1 include:el-valor-de-tu-correo include:el-valor-del-proveedor ~all

el-valor-de-tu-correo representa lo que ya está publicado y funciona. Léelo antes de editar. Si no sabes cuál conservar, pídeselo a quien administra el DNS. En DirectAdmin, DKIM de las casillas se activa en la lista de cuentas, no pegando un TXT de ejemplo. En cPanel, Email Deliverability separa DKIM y SPF. Si el aviso dice que el servidor no controla el DNS, el botón de instalar no escribe en la zona real.

Los subdominios heredan la política. Si no hay un _dmarc propio en el nombre del De, se usa el del dominio organizacional. Sin etiqueta sp, la política del subdominio es la misma p. Un boletín en news.tudominio.cl entra en la misma decisión que el dominio pelado. Aliénalo, o publica un registro aparte, antes de pasar a rechazo.

Un reporte muy grande puede no caber en la casilla. El RFC menciona, como observación habitual, un límite de unos diez megabytes en quien recibe el XML ya comprimido. Si un día no llega el resumen de un buzón grande y el resto sí, revisa el espacio de dmarc@ antes de concluir que ese buzón dejó de participar.

De p=none a cuarentena y a rechazo

Sube de a un peldaño. Cada peldaño se decide con reportes, no con la sensación de que “ya debería estar en reject”.

  1. Cierra el inventario: persona, herramienta, De y responsable.
  2. Publica p=none con rua, en alineación relajada. Espera el primer reporte. Puede tardar un día, porque el intervalo por defecto es de 86400 segundos y el DNS tiene que propagarse.
  3. Lee una semana de trabajo y, además, el día en que salen las facturas y el día del boletín. El correo de las personas aparece en cualquier jornada hábil. No pases de etapa mientras una fila que reconoces siga con policy_evaluated en fail.
  4. Corrige esas filas: include: en el SPF único y DKIM alineado. Vuelve a leer. La fila legítima tiene que mostrar pass en dkim o en spf dentro de policy_evaluated.
  5. Cuando lo que falla sea solo lo que no reconoces, puedes pedir cuarentena. El RFC 7489 define p=quarantine como tratar ese correo como sospechoso: carpeta de spam, más revisión o una marca. No promete una carpeta con el mismo nombre en todos los buzones.

Si quieres un paso intermedio, pct existe para eso. Es el porcentaje del flujo al que se le aplica la política. El valor por defecto es 100. Con p=quarantine y pct=25, el receptor debería aplicar la cuarentena a una parte de los mensajes que fallan. El RFC muestra un sorteo, no una cuota exacta por proveedor, y no todos los buzones lo aplican igual. Sigue leyendo rua: el porcentaje no reemplaza esa revisión.

v=DMARC1; p=quarantine; pct=25; rua=mailto:[email protected]; adkim=r; aspf=r
  1. Sube a pct=100 cuando, durante varios reportes seguidos, tus servicios conocidos estén en pass y la cuarentena no haya desviado facturas ni respuestas de formularios. Pregúntale a quien emite los documentos y a quien recibe los contactos del sitio.
  2. p=reject pide que el receptor rechace durante la transacción SMTP. Lo que todavía falle puede rebotar: un formulario nuevo, un facturador que cambió de plataforma o un subdominio que no alineaste. Publícalo cuando la cuarentena ya haya mostrado que el correo legítimo sigue en pass.
v=DMARC1; p=reject; rua=mailto:[email protected]; adkim=r; aspf=r

Deja rua puesto después del cambio. El reporte es la forma de ver si apareció un emisor nuevo. Un rechazo no avisa dentro del XML con el texto del rebote del cliente. Si alguien te dice que una factura rebotó, cruza la hora con la IP y el header_from de ese día.

Qué piden Gmail, Yahoo y Outlook

Estas reglas son las que publican esos buzones para quien les envía correo. Están vigentes en sus páginas al escribir esta guía. Una pyme que no llega a los umbrales de volumen igual tiene que autenticar: la exigencia básica no parte en los miles de mensajes.

Gmail. Las directrices para remitentes rigen desde el 1 de febrero de 2024 para cuentas personales @gmail.com y @googlemail.com. Quien envía, sin importar el volumen, necesita SPF o DKIM, DNS directo e inverso válidos, TLS y mensajes en el formato del RFC 5322. La tasa de spam que muestra Postmaster Tools tiene que mantenerse bajo el 0,3 %. Hacia esas cuentas personales, la clave DKIM debe ser de 1024 bits o más. Recomiendan 2048 bits si tu proveedor lo permite.

Quien envía más de 5.000 mensajes al día a cuentas de Gmail necesita, además, SPF y DKIM y un DMARC. La política puede ser p=none. El dominio del De tiene que alinearse con el de SPF o con el de DKIM. Los mensajes comerciales y los de suscripción tienen que traer baja en un clic. Google recomienda publicar los reportes DMARC para ver quién usa tu dominio.

Yahoo. En el Sender Hub, la aplicación empieza en febrero de 2024. Todo remitente necesita SPF o DKIM, una tasa de quejas bajo el 0,3 %, DNS directo e inverso válidos y correo conforme a los RFC 5321 y 5322.

Para el remitente masivo piden SPF y DKIM, un DMARC de al menos p=none que además pase, y el De alineado con SPF o con DKIM. La alineación relajada les sirve. Recomiendan con énfasis la etiqueta rua mientras se ajusta el dominio. La baja en un clic es obligatoria en el correo comercial. También aceptan el método mailto, y hay que procesar la baja en un plazo de dos días. La aplicación de esa baja partió en junio de 2024. En las preguntas frecuentes definen al remitente masivo como quien envía un volumen significativo, y dicen de forma expresa que no van a publicar un umbral numérico. No traslades a Yahoo la cifra de 5.000 de Gmail. El correo suplantado sí cuenta para lo que ellos revisan. Si no cumples, el mensaje puede ir a spam o ser rechazado.

Outlook.com. La página de políticas fija el 5 de mayo de 2025 como inicio de requisitos de autenticación para dominios que envían más de 5.000 correos al día a Outlook.com. El mensaje que no cumple va a correo no deseado. Si el problema sigue, pueden rechazarlo con 550 5.7.515. El artículo de soporte de ese error precisa el umbral: 5.000 mensajes o más hacia los servicios de consumo de Microsoft (Outlook.com, Hotmail, Live.com, MSN) con el mismo dominio en el De.

Ahí piden que SPF y DKIM pasen los dos, un registro DMARC (el ejemplo que dan es v=DMARC1; p=none) y que al menos uno de los dos quede alineado con el De. La página de políticas recomienda p=reject como política más firme. Esa recomendación no reemplaza la lectura de tus reportes: para cumplir el requisito publicado, p=none alcanza. Outlook.com recomienda SPF, DKIM y DMARC a todo remitente, también por debajo de ese volumen.

Llegar a 5.000 mensajes no es la meta. Es el punto en que Gmail y Outlook.com agregan obligaciones. Por debajo, SPF o DKIM ya son requisito hacia Gmail y hacia Yahoo, y el reporte agregado es lo que te deja subir la política sin apagar la facturación.

Si quieres que lo revisemos

Escríbenos con el dominio, dónde está el DNS (cPanel, DirectAdmin o Cloudflare) y la lista de herramientas que envían. No mandes contraseñas en el primer mensaje. La casilla dmarc@ puede vivir en el correo corporativo, junto al resto de las direcciones del dominio. Quien lee ese buzón tiene que ser una persona, no una dirección que nadie abre.

Preguntas frecuentes

¿p=none deja pasar una suplantación?

Pide a los receptores que no cambien la entrega por culpa de DMARC. El fraude igual queda en el reporte, con IP y volumen. Los otros filtros del buzón siguen activos.

¿Puedo pasar a p=reject el primer día?

Cuando las filas que reconoces estén alineadas y lo que falla sea un origen que no operas. El primer reporte casi siempre muestra un facturador, un formulario o un boletín en fail.

¿El reporte me dice si caí en spam?

No. Dice autenticación y la disposición que pediste. La bandeja se investiga con el mensaje, las cabeceras y la guía de correos a spam.

¿Sirve un Gmail personal como rua?

Solo si ese otro dominio publica la autorización externa del RFC 7489. Una casilla de tu propio dominio recibe el reporte sin ese TXT.

¿El formulario del sitio aparece en el XML?

Si el De usa tu dominio, sí: como una source_ip y un count. Si esa fila está en fail, corrígela antes de la cuarentena.