¿Microsoft 365 crea el registro DMARC por mí?

No. SPF y DKIM se configuran dentro de la consola de administración, pero el registro TXT de DMARC en _dmarc lo publicas tú en tu propio DNS. La excepción es el dominio onmicrosoft.com del tenant, cuyo registro DMARC Microsoft te hace crear desde el centro de administración de Microsoft 365.

¿Puedo ir directo a p=reject si SPF y DKIM ya pasan?

Puedes, y en un tenant con proveedores externos casi siempre rompe algo. Empieza en p=none, lee dos semanas de reportes agregados, alinea cada remitente que encuentres y pasa una semana en cuarentena antes de rechazar.

¿Por qué los reportes muestran fallas de mis propios usuarios?

Casi siempre es reenvío o un relay sin autenticar. El correo reenviado rompe SPF porque el servidor que reenvía no está en tu registro, y las impresoras o aplicaciones que usan Direct Send llegan sin autenticación alguna. DKIM en tu dominio propio es lo que mantiene el correo reenviado pasando.

DMARC en Office 365: el registro exacto y el paso a reject

Imagina una agencia de carga de 25 personas que trabaja con Microsoft 365. El correo funciona, nadie piensa en él. Hasta que un cliente reenvía una factura que la empresa nunca emitió, con el dominio propio en el campo De, y esa misma semana contabilidad nota que sus facturas reales están cayendo en spam de Gmail. Dos síntomas, un solo hueco: el dominio publica SPF y DKIM, así que el correo que sale del tenant se ve correcto, pero nada le dice al servidor que recibe qué hacer con el correo que no pasa esas revisiones.

Esa instrucción es DMARC, y es el único registro que Microsoft no crea por ti. SPF y DKIM se configuran dentro de la consola. DMARC es un registro TXT que publicas en tu propio DNS, y es la única de las tres piezas que a la vez protege el dominio contra la suplantación y te dice quién está enviando en tu nombre.

Este es el orden en que lo trabajamos en un tenant de Microsoft 365: el registro del primer día, qué muestran los reportes, cómo subimos la política y las trampas propias de Exchange Online.

Qué agrega DMARC sobre el SPF y el DKIM que te da Microsoft

SPF responde una pregunta: ¿este mensaje salió de un servidor que el dominio autorizó? DKIM responde otra: ¿este mensaje se firmó con una llave que el dominio publicó y llegó sin alteraciones? Las dos pueden pasar y el mensaje seguir mintiendo sobre quién lo envió, porque ambas revisan un dominio que el lector nunca ve.

SPF revisa el remitente del sobre, la dirección del comando SMTP MAIL FROM. DKIM revisa el dominio de la etiqueta d= de la firma. La dirección que tu destinatario realmente lee es la del encabezado De, y hasta aquí nadie comparó las dos.

DMARC es esa comparación. Exige que el dominio del encabezado De coincida con el dominio que pasó SPF o con el que firmó con DKIM. Con uno de los dos basta. Esa coincidencia se llama alineación, y por defecto DMARC usa alineación relajada, que acepta un subdominio del mismo dominio organizacional. Puedes endurecerla con aspf=s y adkim=s, y en una empresa pequeña con proveedores externos normalmente no conviene.

Con esa comparación en su lugar pasan dos cosas. Puedes indicarle a quien recibe que ponga en cuarentena o rechace el correo que falla, y puedes pedir reportes con todas las fuentes que envían usando tu dominio. Los reportes son la parte que casi todos se saltan, y la que hace que subir la política sea seguro.

Hoy además hay un piso mínimo. Desde el 1 de febrero de 2024 Google exige a quien envía más de 5,000 mensajes diarios a Gmail publicar un registro DMARC, y p=none cumple con esa regla. Microsoft aplicó un requisito equivalente para Outlook.com, Hotmail.com y Live.com, anunciado el 30 de abril de 2025 y aplicado desde el 5 de mayo de 2025, primero enviando a correo no deseado y después rechazando con 550 5.7.515. Las dos reglas piden el registro, no la aplicación estricta. Aplicarlo es lo que te protege, y esa decisión es tuya.

El registro TXT exacto en _dmarc, etiqueta por etiqueta

Este es el registro del primer día para un dominio que nunca ha tenido DMARC:

Host:  _dmarc
Tipo:  TXT
TTL:   1 hora
Valor: v=DMARC1; p=none; rua=mailto:dmarc@ejemplo.com; fo=1

De izquierda a derecha:

v=DMARC1 es obligatorio y tiene que ir primero, o el registro se ignora.
p= es la política del dominio: none, quarantine o reject. Es una instrucción para los servidores que reciben, no un interruptor dentro de tu tenant.
rua= es a dónde llegan los reportes agregados. Esta etiqueta es lo que hace útil al registro desde el primer día. Apúntala a un buzón compartido o a un grupo que alguien abra, no a una persona que puede irse de la empresa.
ruf= pide reportes de falla por mensaje. Muchos proveedores grandes no los envían, y los que sí pueden incluir contenido del mensaje, así que trata ese buzón como sensible o deja la etiqueta fuera.
sp= define una política distinta para los subdominios. Si la omites, los subdominios heredan lo que diga p=, que suele ser lo que quieres una vez que la raíz está en reject.
pct= aplica la política a una muestra del correo que falla. Solo significa algo en quarantine o reject, así que es una rampa, no un ajuste permanente.
fo=1 pide un reporte de falla cuando cualquiera de las dos revisiones no alinea, y no solo cuando fallan las dos.

Dos detalles que confunden dentro de un panel de DNS. El host es _dmarc, no el dominio a secas, y algunos paneles quieren _dmarc.ejemplo.com escrito completo mientras otros agregan el dominio por ti. Y todo el valor va en un solo registro TXT. Un segundo registro DMARC en el mismo host no se suma: quien encuentra dos trata al dominio como si no tuviera política utilizable.

Publicarlo no cambia nada en la entrega. Lo que hace es abrir el flujo de evidencia del que dependen todas las decisiones siguientes.

Qué muestran los reportes en un tenant de Microsoft 365

Los reportes agregados llegan como XML comprimido, un archivo por proveedor receptor por día, normalmente dentro de las 48 horas siguientes a publicar el registro. Cada uno agrupa los mensajes por IP de origen y dice si SPF y DKIM pasaron y si cada uno alineó con tu dominio del De. Dale dos semanas, porque los remitentes mensuales son justo los que rompen un cambio de política.

En un tenant típico de M365 aparecen cuatro grupos:

Exchange Online. El correo normal de los usuarios. Si el SPF incluye spf.protection.outlook.com y DKIM firma con tu dominio propio, esas filas pasan alineadas. Si DKIM todavía firma con el dominio onmicrosoft.com del tenant, la alineación la sostiene SPF solo, y eso aguanta hasta que alguien reenvía un mensaje.
Proveedores externos. El CRM, la plataforma de facturación electrónica, la mesa de ayuda, la herramienta de marketing, la tienda en línea. Estas filas definen tu calendario: cada una necesita su propia configuración del lado del proveedor antes de que la política pueda subir.
Relays y dispositivos en sitio. Un Exchange viejo en configuración híbrida, una multifuncional que escanea y envía, un sistema administrativo que manda estados de cuenta.
Reenvíos y suplantación real. Una lista de correo o una regla de reenvío rompe SPF en mensajes perfectamente legítimos. Todo lo que queda después de explicar el resto es alguien más usando tu dominio, y es la razón para seguir.

Lee el primer archivo tú mismo en lugar de confiar en un resumen. Si el XML te resulta ajeno, pega uno aquí y mira las filas por fuente.

Subir a cuarentena y después a reject

No movemos la política por calendario. La movemos cuando el inventario de remitentes que salió de los reportes está completo y cada entrada está alineada o retirada a propósito. La secuencia que seguimos:

Primero el correo del propio tenant. Que el SPF tenga el include de Microsoft y siga por debajo del límite de 10 consultas. Que DKIM esté activado para el dominio propio en el portal de Defender, con los dos CNAME, selector1._domainkey y selector2._domainkey, publicados, para que Microsoft pueda rotar llaves sin cortar nada.
Arregla los proveedores externos uno por uno. Cada uno tiene su camino: un return-path propio o un subdominio de envío, CNAME de DKIM, o un subdominio delegado con su propio SPF. Arregla uno, espera a verlo alineado en el siguiente reporte y pasa al que sigue. Si cambias cuatro a la vez no sabes cuál funcionó.
Resuelve los relays. Una impresora o una aplicación que no puede autenticarse no sigue enviando con el dominio principal. Muévela a envío SMTP autenticado, a un conector con restricción por IP, o a un subdominio propio.
Una semana en p=quarantine. Lo que falla cae en no deseado en vez de en la bandeja, y eso se recupera. Revisa los reportes y, sobre todo, pregúntale a quien manda correo poco frecuente si algo rebotó.
Pasa a p=reject. Si quieres rampa, pct=25 y luego pct=50 te compran una falla más lenta. Si el inventario está de verdad completo, la rampa sobre todo compra tiempo.

Deja la etiqueta rua para siempre. Una política en reject sin nadie leyendo reportes es una configuración que se va a romper en silencio la primera vez que marketing contrate una herramienta nueva.

Las trampas de Microsoft que no salen en las guías genéricas

El dominio onmicrosoft.com. Todo tenant tiene uno y sirve para suplantar. La documentación de Microsoft es explícita: SPF y DKIM ya están configurados para el dominio *.onmicrosoft.com, pero el registro DMARC no, y se crea desde el centro de administración de Microsoft 365 y no en tu DNS público. Es fácil blindar el dominio propio y dejar este abierto.

Dominios que tienes y de los que nunca envías. Microsoft recomienda publicar en los dominios estacionados un registro DMARC que diga que de ahí nunca debe salir correo, con la forma v=DMARC1; p=reject; rua=mailto:d@rua.contoso.com; ruf=mailto:d@ruf.contoso.com. Ese dominio defensivo que registraste hace tres años es un canal gratis de suplantación hasta que lo hagas.

Direct Send. Exchange Online acepta correo sin autenticar en el puerto 25 dirigido a los buzones de tu propio tenant, que es como siempre han funcionado las impresoras y los escáneres, y también como alguien de afuera deja un mensaje que parece venir de un compañero. Microsoft agregó un control a nivel de organización para esto, RejectDirectSend, que se ajusta con Set-OrganizationConfig. Si lo activas, primero inventaría los dispositivos que dependen de eso y muévelos a envío autenticado o a un conector restringido.

Reenvíos. Las reglas de reenvío automático y las listas de correo rompen SPF por diseño, porque el servidor que reenvía no está en tu registro SPF. DKIM sobrevive al reenvío mientras el mensaje no se reescriba. Esa es la razón práctica por la que DKIM tiene que estar funcionando en el dominio propio antes de endurecer, no solo SPF.

Lo que entra es otra configuración. Publicar DMARC protege a los demás del correo falso que dice venir de ti. No hace nada contra el correo falso que llega a tus usuarios. Eso lo decide tu política antiphishing, donde respetar el p=quarantine y el p=reject de otros se controla aparte. Revísalo de una vez.

Qué vigilamos después del cambio

El primer mes leemos los reportes cada semana buscando tres cosas: una fuente que nunca había aparecido, una fuente conocida cuya tasa de alineación bajó, y un aumento del correo rechazado desde tus propios rangos de IP. Lo primero suele ser una herramienta que alguien contrató. Lo segundo suele ser una llave rotada o un proveedor que cambió de infraestructura. Lo tercero amerita una llamada.

Después de eso, mensual alcanza, mientras alguien siga abriendo ese buzón.

Cómo ayuda Guanacos Tech

Hacemos este trabajo en tenants de Microsoft 365 con la misma frecuencia que en Google Workspace. Un proyecto típico son dos semanas de reportes, un inventario de remitentes, el trabajo de alineación proveedor por proveedor, y la subida hasta reject con alguien mirando mientras pasa. Si prefieres delegarlo antes que aprender el XML, nuestra consultoría de entregabilidad de correo cubre exactamente esto. Trae tu dominio a la llamada de 30 minutos y te decimos qué hay publicado hoy y qué tan lejos estás de aplicar la política.

DMARC en Office 365: el registro, cómo subir la política y los reportes que nadie lee