Guía de configuración de DMARC para Office 365 (2026)

Utiliza esta guía paso a paso para configurar DMARC en Office 365. Descubre los cambios relevantes en materia de cumplimiento normativo, los métodos habituales para resolver problemas y por qué Microsoft 365 por sí solo no es suficiente para garantizar la seguridad del correo electrónico.

Microsoft respalda y fomenta la configuración de DMARC para Office 365, también conocido como Microsoft 365 o M365. Esto les permite adoptar protocolos de autenticación de correo electrónico de forma uniforme en todos sus dominios registrados. Como expertos en protocolos de autenticación, aprovechamos este blog para explicar los pasos necesarios para configurar DMARC en Office 365 con el fin de validar cualquier correo electrónico que:

• Direcciones de correo electrónico en línea con Microsoft
• Dominios personalizados añadidos en el centro de administración
• Dominios aparcados o inactivos, pero registrados

Lee esta guía para comprender cómo funciona DMARC en Microsoft 365, los pasos para configurarlo, cómo modificar los requisitos de autenticación y por qué herramientas como PowerDMARC son necesarias para implementar la aplicación de las normas de forma gradual.

Respuesta rápida

Si prefieres una versión resumida, este es el proceso básico de configuración de DMARC en Microsoft 365:

1. Configurar SPF: añade «v=spf1 include:spf.protection.outlook.com -all» a tu DNS
2. Activar DKIM: ve a Microsoft 365 Defender → Correo electrónico y colaboración → Políticas y reglas → Políticas de amenazas → DKIM → selecciona el dominio → Activar (requiere dos registros CNAME)
3. Publicar DMARC: crea un registro TXT en _dmarc.tudominio.com que comience con v=DMARC1; p=none; rua=mailto:[email protected]
4. Supervisa los informes durante 2 a 4 semanas y, a continuación, pasa gradualmente de p=cuarentena a p=rechazo.

Si quieres seguir una guía más detallada, lee este blog hasta el final.
Nota: Este procedimiento rápido solo funciona si todas las fuentes de envío legítimas de Microsoft 365 y de terceros están correctamente autenticadas y alineadas. Si utilizas plataformas como CRM, herramientas de automatización de marketing, sistemas de asistencia técnica o herramientas de facturación, identifícalas antes de pasar a la aplicación de las medidas.

¿Qué es DMARC y por qué es importante para Microsoft 365?

DMARC son las siglas de «Domain-based Message Authentication, Reporting, and Conformance» (Autenticación, notificación y conformidad de mensajes basados en dominios). Se trata de un protocolo de autenticación de correo electrónico que ayuda a proteger los dominios contra la suplantación de identidad, el phishing y el uso no autorizado.

DMARC funciona sobre la base de SPF y DKIM. Comprueba si un mensaje supera las verificaciones de SPF o DKIM y si el dominio que supera dichas verificaciones coincide con el dominio visible en el campo «De». A continuación, indica a los servidores de correo receptores qué hacer con los mensajes que no superan la autenticación.

Para los usuarios de Microsoft 365, DMARC es importante por dos razones:

• Ayuda a evitar que los atacantes se hagan pasar por tu dominio.
• Mejora la confianza y la capacidad de entrega del correo electrónico saliente legítimo.

Exchange Online Protection comprueba el DMARC en el correo entrante, pero eso no protege automáticamente tu propio dominio contra la suplantación de identidad en otros sitios. Para proteger la identidad del correo saliente, debes publicar los registros SPF, DKIM y DMARC de tu dominio.

Para obtener información más detallada sobre la implementación, consulta la guía de DMARC de PowerDMARC.

DMARC 2026: Actualización de los RFC 9989, 9990 y 9991

En mayo de 2026, se actualizó DMARC mediante tres RFC de la IETF:

El RFC 9989 deja obsoletos los RFC 7489 y 9091 y eleva a DMARC a la categoría de «estándar propuesto». Para los propietarios de dominios, el cambio práctico más importante es el paso de la identificación de dominios organizativos basada en la Lista de Sufijos Públicos (Public Suffix List) al recorrido del árbol DNS (DNS Tree Walk).

Los registros DMARC existentes siguen empezando por:

txt

v=DMARC1

Por eso, la mayoría de los administradores de Microsoft 365 hacen no necesitan volver a configurar sus registros DNS de inmediato. No obstante, deberías revisar:

• sp= Comportamiento de la política de subdominios
• Cualquier estructura compleja de subdominios delegados
• Dominios y subdominios que envían correo electrónico a través de Microsoft 365 o plataformas de terceros
• Dominios inactivos y que no envían mensajes que deberían bloquearse

Si tu organización utiliza una jerarquía de dominios compleja, publica registros DMARC explícitos para cada dominio y subdominio que envíe correo electrónico. Esto reduce la ambigüedad a medida que los destinatarios pasan de un procesamiento DMARC más antiguo al comportamiento establecido en la norma RFC 9989.

Para obtener más información, consulta la guía de PowerDMARC sobre los actualización de los RFC 9989, 9990 y 9991 de DMARC.

¿Se encarga Microsoft 365 de gestionar el DMARC por ti?

Microsoft 365 realiza la validación DMARC del correo electrónico entrante, pero no configura por completo la protección del dominio saliente para tu dominio personalizado.

Exchange Online Protection evalúa automáticamente los protocolos SPF, DKIM y DMARC en los mensajes que recibe tu organización. Esto ayuda a proteger a los usuarios frente al correo entrante falsificado.

En el caso del correo electrónico saliente, la responsabilidad es diferente. Debes configurar el SPF, habilitar el DKIM y publicar un registro DMARC en el DNS para cada dominio de envío.

La forma más sencilla de entender esta distinción es la siguiente: Microsoft protege tu bandeja de entrada de Microsoft 365, mientras que DMARC protege la identidad de tu dominio en todo el ecosistema del correo electrónico en general.

Si solo utilizas los controles nativos de Microsoft 365, es posible que aún te falten:

• Informes DMARC legibles para el ser humano
• Transparencia respecto a los remitentes externos
• Orientaciones para pasar de «p=none» a «enforcement»
• Supervisión centralizada en todos los dominios
• Gestión del límite de consultas SPF
• Avisos cuando los proveedores o los registros DNS dejan de estar sincronizados

Para obtener un desglose detallado, consulta por qué los usuarios de Microsoft 365 siguen necesitando DMARC.

Requisitos previos: Configurar SPF y DKIM para Microsoft 365

Antes de publicar un registro DMARC, asegúrate de que tanto SPF como DKIM estén correctamente configurados para tu dominio. DMARC no autentifica los correos electrónicos por sí solo; se basa íntegramente en los resultados de SPF y/o DKIM. Si faltan o no están alineados, DMARC fallará y los correos electrónicos legítimos podrían verse afectados una vez que se active la aplicación de la política.

Paso 1: Configurar SPF para Microsoft 365

El SPF (Sender Policy Framework) define qué servidores de correo están autorizados a enviar correos electrónicos en nombre de tu dominio.

En el caso de un dominio exclusivo de Microsoft 365, el registro SPF estándar es:

v=spf1 include:spf.protection.outlook.com -all

Si utilizas remitentes de terceros, inclúyelos en el mismo registro SPF:

v=spf1 include:spf.protection.outlook.com include:_spf.salesforce.com -all

Importante: Solo puede existir un registro TXT de SPF por dominio. La presencia de varios registros SPF provoca un error «SPF PermError» y puede impedir la autenticación.

SPF también tiene un límite máximo de 10 consultas DNS. Si se supera este límite, se produce un «SPF PermError», que DMARC interpreta como un fallo. Si utilizas varios servicios SaaS, utiliza el servicio SPF alojado de PowerSPF con macros para mantenerte siempre por debajo del límite sin necesidad de realizar modificaciones manuales en el DNS. También puedes comprobar tu registro SPF actual o utilizar este generador de SPF de forma gratuita.

Paso 2: Habilitar DKIM para Microsoft 365

DKIM (DomainKeys Identified Mail) añade una firma criptográfica a tus correos electrónicos. Esto permite a los servidores receptores verificar que el mensaje no ha sido alterado y que procede realmente de tu dominio.

⚠️  DKIM en Microsoft 365 no está habilitado de forma predeterminada para los dominios personalizados. Debes habilitarlo explícitamente en el centro de administración.

Configuración manual de DKIM: DNS + Centro de administración

1. Accede al portal de Microsoft 365 Defender
2. Ve a «Correo electrónico y colaboración» → «Políticas y reglas» → «Políticas de amenazas» → «Configuración de autenticación de correo electrónico» → «DKIM»
3. Selecciona tu dominio.

Antes de poder activarlo, Microsoft te pedirá que añadas dos registros CNAME:

selector1._domainkey
selector1-<CustomDomainWithDashes>._domainkey.<InitialDomainPrefix>.<DynamicPartitionCharacter>-v1.dkim.mail.microsoft

selector2._domainkey
selector2-<CustomDomainWithDashes>._domainkey.<InitialDomainPrefix>.<DynamicPartitionCharacter>-v1.dkim.mail.microsoft

1. Una vez publicados estos registros CNAME, vuelve al portal de Defender y activa la opción «Habilitar» para DKIM.

Una vez activado, Microsoft comienza a firmar todos los correos electrónicos salientes con DKIM. Comprueba tu configuración utilizando el comprobador DKIM gratuito.

Cómo configurar DMARC para Office 365

Una vez configurados SPF y DKIM, puedes publicar DMARC. El proceso de configuración de DMARC en Microsoft 365 se lleva a cabo en el DNS, y no en el Centro de administración de Microsoft 365, en el caso de la mayoría de los dominios personalizados.

Paso 1: Identificar todas las fuentes de envío de correos electrónicos

Antes de publicar un registro DMARC, es necesario tener una visión completa de quiénes envían correos electrónicos en nombre de tu dominio. Si se omite a algún remitente legítimo, pueden producirse errores de entrega una vez que se active la aplicación de la política.

Entre las fuentes de envío habituales de Microsoft 365 se incluyen:

• Microsoft 365 (Exchange Online)
• Plataformas de marketing (Mailchimp, HubSpot, Klaviyo)
• Sistemas CRM (Salesforce, HubSpot CRM)
• Herramientas de atención al cliente (Zendesk, Freshdesk, Intercom)
• Aplicaciones internas o servidores de correo locales
• Pasarelas de correo electrónico o dispositivos de seguridad de terceros

Aquí es donde fracasan muchas implementaciones de DMARC. Puede parecer que un dominio se utiliza «exclusivamente para Microsoft 365», pero las facturas, los boletines informativos, los restablecimientos de contraseña, las actualizaciones de tickets y las notificaciones de RR. HH. suelen proceder de fuera de Microsoft 365.

Si no estás seguro de qué sistemas envían mensajes en tu nombre, empieza con «p=none» y utiliza los informes agregados de DMARC para identificarlos.

Paso 2: Crea tu registro DMARC

Un registro DMARC es un registro TXT publicado en tu DNS en _dmarc.tudominio.com. Utiliza el generador de registros DMARC para crear un registro válido y sin errores en cuestión de segundos.

Un registro inicial recomendado tiene este aspecto:

v=DMARC1; p=none; rua=mailto:[email protected];

Analicémoslo:

• v=DMARC1 — especifica la versión de DMARC
• p=none — modo de supervisión (sin aplicación de normas; solo recopilación de datos)
• rua=mailto:… — donde se envían los informes agregados (RUA)

Paso 3: Publicar el registro DMARC en el DNS

Añade el siguiente registro TXT en tu proveedor de alojamiento DNS:

Nota: Tras la publicación, puede que el registro tarde algún tiempo (normalmente, entre unos minutos y unas horas) en propagarse a nivel mundial.

Tras la publicación, comprueba tu registro con una herramienta de verificación DMARC para asegurarte de que no hay errores de sintaxis y de que el registro se resuelve correctamente.

Paso 4: Supervisar los informes DMARC

Tras habilitar DMARC con una política «p=none», empezarás a recibir informes agregados de DMARC (RUA) de los servidores receptores. Estos informes ofrecen información sobre: quién envía correos electrónicos utilizando su dominio, qué mensajes superan o no la autenticación y el estado de alineación de SPF y DKIM.

Los informes DMARC se reciben en formato XML sin procesar, lo que dificulta su interpretación sin herramientas específicas. El analizador de informes de PowerDMARC los convierte en paneles de control fáciles de entender para que puedas identificar los problemas y avanzar con seguridad hacia la aplicación de las políticas.

Paso 5: Pasar gradualmente a la aplicación de la ley

Una vez que hayas comprobado que todos los remitentes legítimos están debidamente autenticados, endurece tu política DMARC por etapas:

Fase 1 — Seguimiento (p = ninguna):

v=DMARC1; p=none; rua=mailto:[email protected]

Etapa 2 — Cuarentena (los correos electrónicos sospechosos se envían a la carpeta de spam):

v=DMARC1; p=cuarentena; rua=mailto:[email protected]; pct=25; t=y

Fase 3 — Aplicación (rechazar el correo no autenticado):

v=DMARC1; p=reject; rua=mailto:[email protected]; adkim=r; aspf=r

Consejo: No te precipites a la hora de rechazar. La aplicación prematura de las normas es la causa más habitual de que se bloqueen correos electrónicos legítimos durante la fase de implantación.

Paso 6: Configurar DMARC para diferentes tipos de dominios

El procedimiento varía en función del dominio que estés configurando.

Paso 7: Valida y mantén tu configuración de DMARC en Microsoft 365

DMARC no es una configuración que se establece una sola vez. A medida que cambia tu ecosistema de correo electrónico, tu configuración debe adaptarse. Incluso después de alcanzar el nivel p=reject, es fundamental realizar un seguimiento continuo para mantener la capacidad de entrega y la seguridad.

Deberías hacer lo siguiente con regularidad:

• Revisar los informes DMARC
• Actualiza el SPF al añadir nuevos remitentes
• Asegúrate de que DKIM siga activado y configurado correctamente
• Supervisar la actividad no autorizada

Implementación de la política DMARC: por qué es importante una aplicación gradual

Pasar directamente a una política de rechazo es uno de los errores más comunes en la implementación de DMARC. Sin una visión clara de los flujos de correo electrónico, la aplicación de esta política puede interrumpir la comunicación legítima.

Una implantación por fases te permite supervisar y corregir los problemas antes de aplicar políticas estrictas. La mayoría de las organizaciones siguen un proceso que va desde la supervisión hasta la cuarentena y, finalmente, el rechazo. La duración de cada fase depende de la complejidad de tu entorno de correo electrónico, y saltarse pasos solo aumenta el riesgo de que se produzcan fallos de entrega no deseados.

Cómo gestiona Exchange Online los mensajes DMARC entrantes

Exchange Online Protection evalúa automáticamente el DMARC en todos los mensajes entrantes. Desde julio de 2023, Microsoft ha respetado por defecto la política publicada por el remitente. Cuando el registro MX del dominio del destinatario apunta directamente a Microsoft 365, los mensajes que no superan la verificación DMARC según una política p=reject se rechazan en la puerta de enlace. Del mismo modo, los mensajes que no superan la verificación según una política p=quarantine se envían a cuarentena. Esto se controla mediante la política ««Respetar la política del registro DMARC cuando se detecte que el mensaje es falso»» de la política antiphishing, que está habilitada de forma predeterminada.

Para obtener una guía detallada sobre cómo configurar este parámetro y todas las opciones relacionadas, consulta la guía de PowerDMARC sobre la política antiphishing de Office 365.

Fuente: Microsoft

Explicación del comportamiento «oreject»

Anteriormente, Microsoft aplicaba una excepción interna denominada «action=oreject» (rechazo en origen) a los mensajes entrantes que incumplían la política «p=reject» del remitente. En lugar de rechazar el correo directamente en la pasarela, EOP lo desviaba a la carpeta de correo no deseado del destinatario y marcaba el encabezado con la acción «oreject».

Microsoft lo hizo a propósito; los correos reenviados y el tráfico de las listas de correo suelen incumplir las normas SPF y DKIM durante el tránsito, y un rechazo definitivo con el parámetro «p=reject» habría provocado el descarte de un volumen considerable de correo legítimo. La carpeta de correo no deseado fue una solución intermedia: los destinatarios podían recuperar el correo si era necesario y, técnicamente, se respetaba la política del remitente.

Cuándo volverás a ver «oreject» hoy

Dado que se ha modificado el valor por defecto, EOP ahora interpreta «p=reject» como un rechazo real en los flujos MX directos. Sin embargo, el comportamiento anterior no ha desaparecido por completo. Seguirás viendo «oreject» en tres casos:

1. La opción «Honor DMARC» está desactivada en tu política antiphishing: compruébalo en Microsoft 365 Defender → Correo electrónico y colaboración → Políticas de amenazas → Antiphishing → Configuración de suplantación de identidad
2. El correo pasa por una puerta de enlace de terceros (Proofpoint, Mimecast) antes de llegar a Microsoft 365: activa el «Filtrado mejorado para conectores» en el portal de Defender.
3. Una regla de permiso a nivel de inquilino está eludiendo el filtrado: los remitentes incluidos en la lista de permitidos, los conectores de entrada de confianza o las reglas con SCL -1 omiten por completo la aplicación de DMARC.

Qué es «compauth» y la autenticación compuesta

Microsoft superpone señales de reputación a los resultados de DMARC mediante un sistema denominado «autenticación compuesta» (compauth). Esto significa que, técnicamente, un mensaje puede no superar la verificación DMARC, pero aun así ser entregado si las señales de reputación de Microsoft indican que el remitente es legítimo (compauth=pass). Por el contrario, un mensaje puede superar la verificación de DMARC y, aun así, acabar en la bandeja de correo no deseado si compauth falla. Al solucionar problemas de entrega de DMARC en M365, comprueba siempre el encabezado «Authentication-Results» para ver el código «reason=». Consulta esta guía completa sobre fallos de compauth y la autenticación compuesta para obtener más información.

Endurecimiento de la aplicación de las normas de transporte en el ámbito de las importaciones

Para aquellas organizaciones que deseen garantizar el rechazo del correo que no cumpla con DMARC, una regla de transporte de Exchange Online es el mecanismo más fiable:

1. Ve a Centro de administración de Exchange → Flujo de correo → Reglas → Crear una nueva regla
2. Condición establecida: El encabezado de un mensaje incluye cualquiera de estas palabras. Nombre del encabezado: Authentication-Results. Valor del encabezado: dmarc=fail action=oreject
3. Acción definida: Rechazar el mensaje con la explicación «El mensaje no ha superado la autenticación DMARC y ha sido rechazado de acuerdo con la política de la organización».

1. (Opcional) Añadir una excepción para remitentes internos de confianza o reenviadores legítimos conocidos
2. Durante la primera semana, configura el modo de reglas en «Prueba sin política» o «Prueba con consejos sobre políticas», si está disponible; revisa los mensajes coincidentes en el historial de mensajes antes de pasar al modo «Aplicar».

Utiliza este enfoque cuando la normativa o las políticas internas exijan el rechazo efectivo del correo defectuoso, cuando tu organización sea un objetivo de suplantación de identidad de gran valor (comunicaciones financieras, jurídicas o ejecutivas), o cuando desees un comportamiento coherente tanto en los flujos directos de MX como en los de las pasarelas de terceros.

La aplicación de DMARC por parte de Microsoft en mayo de 2025: qué ha cambiado

En mayo de 2025, Microsoft introdujo un cambio importante en la forma en que gestiona los correos electrónicos no autenticados procedentes de remitentes externos. Este cambio afecta principalmente a los remitentes que envían grandes volúmenes de correo, pero tiene implicaciones más amplias para todas las organizaciones.

Comparativa de la aplicación de las políticas de los proveedores de buzones de correo

Requisitos clave introducidos por Microsoft

• DMARC obligatorio para remitentes masivos: los dominios que envíen más de 5.000 correos electrónicos al día a los servicios para particulares de Microsoft deben disponer de un registro DMARC válido
• Se aplica al ecosistema de buzones de correo para particulares de Microsoft: Outlook.com, Hotmail.com y Live.com
• Requisito mínimo: DMARC con p=none: se acepta incluso una política de supervisión, pero ya no se tolera la ausencia de un registro DMARC a gran escala.
• Se hace especial hincapié en la coincidencia de dominios: la autenticación por sí sola no es suficiente; SPF y DKIM deben coincidir con el dominio visible del campo «De»
• Rechazo definitivo por incumplimiento: 550 5.7.515 Acceso denegado, el dominio remitente no cumple con el nivel de autenticación requerido

Este cambio sitúa a Microsoft a la altura de Apple, los requisitos de autenticación de correo electrónico de Google y Yahoo, lo que significa que ahora todos los principales proveedores de correo electrónico exigen la autenticación a los remitentes masivos. Consulta los requisitos de DMARC de Microsoft para Outlook para consultar una lista completa de verificación del cumplimiento.

Por qué Microsoft 365 por sí solo no es suficiente

Aunque Microsoft 365 ofrece una sólida protección contra el correo entrante, sus capacidades para gestionar y supervisar DMARC a gran escala son limitadas.

No hay informes legibles para el ser humano

Microsoft envía ahora informes DMARC a los usuarios empresariales cuando el registro MX apunta directamente a Office 365. Sin embargo, estos archivos XML sin procesar son difíciles de interpretar sin herramientas especializadas. Sin un análisis adecuado, las organizaciones carecen de visibilidad sobre quién envía correos electrónicos en su nombre y si dichas fuentes están debidamente autenticadas.

No hay directrices de aplicación

Microsoft no ofrece orientación automatizada para pasar de la supervisión a la aplicación de medidas. Esto obliga a los administradores a interpretar manualmente los datos y a tomar decisiones que pueden afectar al envío de correos electrónicos.

No apto para la gestión continua

Una solución DMARC especializada no solo transforma los informes sin procesar en información útil. Permite una supervisión continua, simplifica la gestión de políticas y ayuda a las organizaciones a avanzar de forma segura hacia la aplicación plena de las mismas, a una escala que Microsoft 365 simplemente no ofrece.

Solución de problemas comunes relacionados con DMARC en Office 365

También puedes formar parte de la comunidad de aprendizaje de Microsoft para mantenerte al día sobre Office 365 y los requisitos de su protocolo de autenticación.

Avanzando con DMARC en Microsoft 365

DMARC en Microsoft 365 plantea un problema de dos vertientes. Exchange Online Protection se encarga automáticamente de la validación del correo entrante, pero la protección del correo saliente es responsabilidad exclusiva del usuario. Los cambios en la aplicación de la normativa previstos para mayo de 2025 hacen que esa responsabilidad sea urgente para cualquiera que envíe gran volumen de correo, y la publicación de DMARCbis en mayo de 2026 indica que el sector del correo electrónico está considerando DMARC como una infraestructura permanente y formal.

El método más seguro es más lento, pero eficaz: publica «p=none», supervisa tus informes durante dos a cuatro semanas, corrige los remitentes que aparezcan y, a continuación, pasa a «p=quarantine» y, finalmente, a «p=reject». Saltarse estos pasos es lo que provoca que el correo empresarial legítimo se vea afectado durante la implementación.

El trabajo pasa de la configuración al seguimiento una vez que se alcanza la fase de aplicación. Se añaden nuevos remitentes y los proveedores externos modifican su infraestructura, lo que puede alterar silenciosamente la alineación si nadie supervisa los informes. Da prioridad a la seguridad del correo electrónico comprobando tu registro DMARC actual para ver cuál es tu situación actual.

Para obtener una referencia completa de todas las etiquetas, políticas y opciones de implementación de DMARC, consulta la guía de DMARC.

Preguntas frecuentes

¿Configuran automáticamente DMARC en Microsoft 365?

Microsoft valida DMARC para el correo electrónico entrante, pero no lo configura para tu dominio personalizado. Debes publicar tú mismo manualmente el registro TXT de DMARC para el correo saliente. La protección del dominio requiere que publiques tú mismo los registros SPF, DKIM y DMARC en el DNS.

¿Es obligatorio el uso de DMARC en Microsoft?

Sí. Microsoft ha establecido como obligatorio el uso de DMARC (como mínimo, p=none) para los dominios que envíen más de 5.000 correos electrónicos al día a Outlook.com, Hotmail.com y Live.com a partir de 2025. Los remitentes que no cumplan este requisito serán rechazados a nivel de servidor, sin llegar a ninguna bandeja de entrada. Microsoft también recomienda encarecidamente a todos los remitentes que implementen DMARC, independientemente del volumen de correo que envíen.

¿Qué es el error 550 5.7.515?

Este error de Microsoft 365 significa que tus correos electrónicos están siendo rechazados porque tu dominio de envío no cumple los requisitos de autenticación. La solución consiste en publicar un registro DMARC válido (como mínimo, p=none) y asegurarte de que tanto SPF como DKIM estén configurados y alineados con tu dominio de remitente.

¿Por qué siguen llegando correos electrónicos con el indicador «p=reject»?

Hay cuatro motivos habituales: (1) la opción «Honor DMARC» está desactivada en tu política antiphishing; (2) hay una pasarela de terceros situada delante de Microsoft 365; (3) no está activado el «Filtrado mejorado para conectores»; (4) la autenticación compuesta de Microsoft (compauth) está anulando el resultado de fallo de DMARC; (5) una regla de permiso del inquilino está eludiendo por completo el filtrado. Aunque Microsoft ha adoptado un enfoque más estricto de rechazo real para los remitentes de gran volumen, estas anulaciones siguen activas en entornos mal configurados.

¿Debería usar «cuarentena» o «rechazar»?

Empieza por la supervisión (p=ninguna) para conocer tus fuentes de envío; a continuación, pasa a la cuarentena y utiliza el rechazo solo cuando estés seguro de que todas las fuentes legítimas están correctamente identificadas. Pasar directamente al rechazo sin realizar un seguimiento previo es la principal causa de pérdida de correos electrónicos legítimos durante la implantación de DMARC.

¿Qué supone DMARCbis para los administradores de Microsoft 365?

DMARCbis (RFC 9989, publicado en mayo de 2026) eleva oficialmente a DMARC a la categoría de «estándar propuesto». Para la mayoría de los administradores de M365, no es necesario realizar cambios inmediatos en el DNS, ya que los registros DMARC existentes siguen siendo válidos. El cambio clave que hay que tener en cuenta es el enfoque de «DNS Tree Walk» para determinar los dominios de la organización, que sustituye a la Lista de Sufijos Públicos. Revisa tu etiqueta sp= (política de subdominios) para confirmar que sigue aplicándose correctamente según la nueva lógica.

¿Se aplica DMARC a los dominios de onmicrosoft.com?

Sí. El dominio onmicrosoft.com (MOERA) suele pasarse por alto, pero los atacantes lo utilizan activamente para la suplantación de identidad. Microsoft configura automáticamente el SPF para los dominios MOERA, pero el DKIM y el DMARC deben publicarse manualmente. Utiliza una política estricta «p=reject» en estos dominios, ya que normalmente no se utilizan para el correo saliente legítimo.

¿Es obligatorio el uso de DMARC para cumplir con la norma PCI DSS?

A partir del 31 de marzo de 2025, la sección 5.4.1 de la norma PCI DSS v4.0 estableció que los controles contra el phishing, incluidos DMARC, SPF y DKIM, son totalmente obligatorios para todas las organizaciones que gestionan datos de tarjetas de pago. Todas las evaluaciones de 2026 se llevarán a cabo con arreglo a la norma PCI DSS v4.0.1, sin periodo de gracia. Si su organización procesa pagos con tarjeta y utiliza Microsoft 365, DMARC es un requisito de cumplimiento estricto.

• Acerca de
• Últimas publicaciones

Yunes Tarada

Experto en seguridad de dominios y correo electrónico en PowerDMARC

Yunes es jefe de equipo de operaciones en PowerDMARC con conocimientos especializados en autenticación y seguridad del correo electrónico. Yunes es Administrador Asociado de Azure certificado por Microsoft y cuenta con certificaciones de CompTIA A+ y muchas más.

Últimos mensajes de Yunes Tarada (ver todos)

• Aplanamiento SPF: ¿qué es y para qué sirve? - 28 de julio de 2026
• Guía de configuración de DMARC para Office 365 (2026) - 21 de julio de 2026
• Cómo solucionar los errores «La firma DKIM no es válida» y «El hash del cuerpo no se ha verificado» - 16 de julio de 2026