DMARC para Office 365: Configuración paso a paso y sus mejores prácticas

Microsoft respalda y recomienda la configuración de DMARC a los usuarios de Microsoft 365 (también conocido como Office 365 o M365), lo que les permite adoptar protocolos de autenticación de correo electrónico de manera uniforme en todos sus dominios registrados. En este blog, explicamos los pasos para configurar DMARC en Office 365 con el fin de validar cualquier correo electrónico de Office 365 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

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

DMARC es un protocolo de autenticación de correo electrónico que protege los dominios contra la suplantación de identidad y el phishing. (Autenticación, notificación y conformidad de mensajes basados en dominios) funciona como complemento de SPF y DKIM, alineando los resultados de la autenticación con la política del dominio e indicando a los servidores receptores cómo gestionar los mensajes que no superan dichas comprobaciones.

En un entorno de Microsoft 365, DMARC desempeña una doble función. Protege tu dominio contra la suplantación de identidad por parte de atacantes y, además, contribuye a que los destinatarios externos confíen en tus correos electrónicos legítimos.

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

Uno de los errores más comunes entre los administradores es pensar que Microsoft 365 se encarga de gestionar el DMARC por ti.

Microsoft 365 realiza la validación DMARC, pero solo para el correo electrónico entrante. Exchange Online Protection (EOP) comprueba automáticamente los registros SPF, DKIM y DMARC de los mensajes que recibe tu organización. Esto significa que tus usuarios están protegidos, en cierta medida, contra los correos electrónicos suplantados.

Sin embargo, en lo que respecta al correo electrónico saliente, Microsoft no hace nada a menos que lo configures. Si deseas proteger tu dominio y cumplir con los requisitos de cumplimiento normativo actuales, debes publicar un registro DMARC en tu DNS.

Esta distinción es fundamental. Microsoft protege tu bandeja de entrada, pero DMARC protege la reputación de tu dominio, por lo que Microsoft 365 necesita DMARC incluso si ya se utiliza EOP. La configuración que vas a implementar se aplica a la protección de los mensajes salientes.

Requisitos previos: Configurar SPF y DKIM para Microsoft 365

Antes de publicar un registro DMARC, debes asegurarte de que tanto SPF como DKIM estén correctamente configurados para tu dominio. DMARC no autentica los correos electrónicos por sí solo, sino que se basa íntegramente en los resultados de SPF y/o DKIM. Si estos faltan o no están sincronizados, 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 una configuración de Microsoft 365, esto suele incluir los propios servidores de correo de Microsoft y cualquier servicio de terceros que utilices.

Configuración manual del SPF (método DNS)

Para configurar SPF manualmente:

1. Ve a tu proveedor de alojamiento DNS (por ejemplo, GoDaddy, Cloudflare, etc.)
2. Crea o actualiza un registro TXT para tu dominio principal

Utiliza el siguiente registro SPF estándar de Microsoft 365:

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

Si utilizas servicios adicionales (como Mailchimp o Salesforce), debes incluirlos también. Por ejemplo:

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

Configuración automática del SPF (con PowerDMARC)

La creación manual de registros SPF puede resultar compleja, sobre todo cuando intervienen varios servicios. Son habituales errores como sobrepasar los límites de consultas DNS o las configuraciones incorrectas.

El uso de las herramientas SPF de PowerDMARC simplifica este proceso. El generador de SPF crea automáticamente un registro válido basándose en tus fuentes de envío.

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.

A diferencia de SPF, DKIM en Microsoft 365 requiere tanto una configuración de DNS como una activación en el Centro de administración.

Configuración manual de DKIM (DNS + Centro de administración)

Para habilitar DKIM manualmente:

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 → DKIM
3. Selecciona tu dominio

Fuente de la imagen

Antes de poder habilitar DKIM, Microsoft te pedirá que añadas dos registros CNAME a tu DNS.

Suelen tener el siguiente aspecto:

selector1._domainkey.tudominio.com → selector1-tudominio.com._domainkey.tudominio.onmicrosoft.com

selector2._domainkey.tudominio.com → selector2-tudominio-com._domainkey.tudominio.onmicrosoft.com

Una vez publicados estos registros, vuelve al portal de administración y haz clic en «Habilitar» junto a DKIM. Una vez activado, Microsoft comenzará a firmar todos los correos electrónicos salientes con DKIM.

Configuración automática de DKIM (con PowerDMARC)

La configuración de DKIM puede resultar confusa, sobre todo para los administradores que no estén familiarizados con los registros CNAME y los formatos de selector.

PowerDMARC simplifica este proceso generando automáticamente los registros DKIM correctos para tu dominio, ofreciendo la publicación automática en el DNS para eliminar los errores de introducción manual y proporcionando una herramienta de verificación de DKIM para confirmar que DKIM está correctamente habilitado

¿Cómo configurar DMARC para Office 365?

Una vez que SPF y DKIM estén correctamente configurados, puedes pasar a configurar DMARC. En Microsoft 365, este proceso se lleva a cabo a nivel de DNS, pero para hacerlo correctamente es necesario comprender tu ecosistema de correo electrónico, elegir la política adecuada y supervisar los resultados antes de su aplicación.

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én envía correos electrónicos en nombre de tu dominio. Este es uno de los pasos más importantes, ya que si se omite a un remitente legítimo, esto puede provocar fallos en la entrega más adelante.

Entre las fuentes de envío suelen figurar:

• Microsoft 365 (Exchange Online)
• Plataformas de marketing (Mailchimp, HubSpot, etc.)
• Sistemas CRM (Salesforce)
• Herramientas de atención al cliente (Zendesk, Freshdesk)
• Aplicaciones o servidores internos

Si alguno de ellos no está debidamente autenticado mediante SPF o DKIM, no superará la verificación DMARC una vez que se active la aplicación de esta política.

Paso 2: Crea tu registro DMARC

Un registro DMARC es un registro TXT publicado en tu DNS. Define tu política e indica a los servidores receptores cómo gestionar los correos electrónicos que no superan la autenticación. Puedes crear un registro DMARC exclusivo de Office 365 para tu dominio utilizando la herramienta de generación instantánea de registros DMARC de PowerDMARC.

Un registro DMARC básico tiene este aspecto: v=DMARC1; p=none; rua=mailto:[email protected]; fo=1

Analicémoslo:

v=DMARC1 – Especifica la versión de DMARC
p=none – Modo de supervisión (sin aplicación)
rua=mailto:[email protected] – Destinatario de los informes agregados
fo=1 – Habilita la notificación de fallos

Este es el punto de partida recomendado, ya que te permite recopilar datos sin afectar al envío de correos electrónicos.

Paso 3: Publicar el registro DMARC en el DNS

Una vez que el registro esté listo, debes añadirlo a tu DNS.

Utiliza la siguiente configuración:

Tipo de registro: TXT
Host/Nombre: _dmarc
Valor: Tu registro DMARC
TTL: 1 hora (o el valor predeterminado)

Paso 4: Supervisar los informes DMARC

Una vez habilitado DMARC con una política p=none, empezarás a recibir informes de los servidores receptores. Estos informes te permiten saber quién envía correos electrónicos utilizando tu dominio, qué mensajes superan o no la autenticación, y el estado de alineación de SPF y DKIM.

Los informes DMARC suelen enviarse en formato XML y pueden resultar difíciles de interpretar manualmente. Sin un análisis adecuado, es fácil pasar por alto errores de configuración o remitentes no autorizados.

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

Una vez que hayas revisado tus informes y hayas confirmado que todos los remitentes legítimos están debidamente autenticados, puedes empezar a reforzar tu política DMARC.

Una progresión típica es la siguiente:

Empieza con la supervisión: v=DMARC1; p=none; rua=mailto:[email protected]

↓

Enviar a cuarentena (los correos electrónicos sospechosos se envían a la carpeta de spam): v=DMARC1; p=quarantine; rua=mailto:[email protected];

↓

Por último, aplica el rechazo: v=DMARC1; p=reject; rua=mailto:[email protected]; adkim=r; aspf=r

Paso 6: Configurar DMARC para diferentes tipos de dominios

El procedimiento puede variar 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 implementació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 de la supervisión a la cuarentena y, finalmente, al rechazo. La duración de cada fase depende de la complejidad de tu entorno de correo electrónico, pero saltarse pasos 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 y, desde julio de 2023, Microsoft respeta de forma predeterminada 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 validació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 comprobación DMARC con una política p=quarantine se envían a cuarentena. Esto se controla mediante la configuración«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.

Fuente de la imagen

Explicación del comportamiento «oreject»

Antes de julio de 2023, Microsoft aplicaba una anulació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 puerta de enlace, EOP lo desviaba a la carpeta de correo no deseado del destinatario y marcaba el encabezado con la acción «oreject».

Microsoft tomó esta decisión deliberadamente, ya que el correo reenviado y el tráfico de las listas de correo suelen incumplir las normas SPF y DKIM durante el tránsito. Esto significa que un mensaje legítimo que supera la autenticación en el remitente original puede fallar en el momento en que lo recibe un destinatario secundario. Un rechazo definitivo con el valor «p=reject» habría descartado un volumen significativo de correo legítimo junto con los mensajes falsificados. La carpeta de correo no deseado fue una solución intermedia: los destinatarios podían recuperar el correo si lo necesitaban y, técnicamente, se respetaba la política del remitente.

La contrapartida era que los mensajes falsificados que deberían haber sido rechazados seguían llegando a las bandejas de entrada de los usuarios (en la carpeta de correo no deseado), donde un destinatario distraído podría abrirlos. Para los equipos de seguridad, esto significaba que la aplicación de DMARC nunca resultaba tan estricta como sugería la política.

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

Dado que se ha modificado el valor predeterminado, EOP ahora interpreta «p=reject» como un rechazo efectivo en los flujos Direct-MX. 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 su política antiphishing.

Para solucionar este problema: comprueba la configuración en Microsoft 365 Defender → Correo electrónico y colaboración → Políticas de amenazas → Antiphishing → Configuración de suplantación de identidad. La opción está activada de forma predeterminada, pero es posible que los inquilinos que hayan migrado desde configuraciones anteriores la tengan desactivada.

2. El correo pasa por una puerta de enlace de un tercero antes de llegar a Microsoft 365.

Si tu servidor MX apunta a un dispositivo de seguridad (Proofpoint, Mimecast, etc.) que a su vez reenvía el correo a EOP, Microsoft no podrá volver a evaluar DMARC a menos que actives el «Filtrado mejorado para conectores» en el portal de Defender. Sin esta configuración, EOP se fía del veredicto de la puerta de enlace anterior y, por defecto, rechaza los mensajes que no superan la validación.

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 de transporte que asignen un nivel de confianza en el spam (SCL -1) eludirán por completo la aplicación de DMARC y el mensaje llegará a la bandeja de entrada independientemente de la política establecida.

Para una gestión más estricta, activa Spoof Intelligence en el portal de Defender junto con «Honor DMARC». Spoof Intelligence evalúa la reputación del remitente independientemente de DMARC y pone en cuarentena los mensajes que parecen intentos de suplantación de identidad, incluso cuando la autenticación se supera técnicamente.

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

Para las organizaciones que desean garantizar el rechazo del correo que no cumple con DMARC, una regla de transporte de Exchange Online es el mecanismo más fiable.

Cómo crear la regla:

1. Ve al Centro de administración de Exchange → Flujo de correo → Reglas y crea una nueva regla.
2. Establece la condición: el encabezado de un mensaje incluye cualquiera de estas palabras. Nombre del encabezado: Authentication-Results. Valor del encabezado: dmarc=fail action=oreject.
3. Configura la acción: rechaza el mensaje con la siguiente 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».
4. (Opcional) Añade una excepción para remitentes internos de confianza o reenviadores legítimos conocidos a fin de evitar falsos positivos.
5. Configura el modo de la regla en «Prueba con sugerencias de políticas» durante la primera semana. Revisa los mensajes detectados en el registro de mensajes antes de cambiar al modo «Aplicar».

Para obtener más información, puede consultar la documentación detallada de Microsoft sobre las reglas de flujo de correo.

Cuándo utilizar este enfoque:

Las reglas de transporte resultan útiles cuando la normativa o las políticas internas exigen el rechazo efectivo del correo defectuoso, cuando su organización es un objetivo de suplantación de identidad de gran valor (comunicaciones financieras, jurídicas o ejecutivas), o cuando se desea un comportamiento coherente en los flujos de MX directo y de 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 significativo 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 mensajes, pero tiene implicaciones más amplias para todas las organizaciones.

En términos generales, los requisitos de Microsoft para los remitentes de correo electrónico se ajustan a la tendencia general del sector hacia una autenticación más estricta y una mayor responsabilidad de los remitentes. La actualización establece límites claros, medidas coercitivas y expectativas que antes se aplicaban de forma más flexible.

Principales cambios 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 consumidores de Microsoft deben contar ahora con un registro DMARC válido.
• Aplicable a Outlook.com, Hotmail.com y Live.com: la aplicación de estas medidas se centra específicamente en el ecosistema de buzones de correo para particulares de Microsoft, y no solo en los clientes empresariales.
• Requisito mínimo: DMARC con p=none: aunque se acepta una política de supervisión, ya no se tolera la ausencia de un registro DMARC a gran escala.
• Mayor énfasis en la coincidencia del dominio: la autenticación por sí sola no es suficiente; para que DMARC se apruebe, SPF y DKIM deben coincidir con el dominio visible del campo «De».
• Rechazo definitivo por incumplimiento: los correos electrónicos que no cumplan los requisitos pueden bloquearse con el mensaje: 550 5.7.515 Acceso denegado; el dominio remitente [SendingDomain] no cumple el nivel de autenticación requerido.

Este cambio sitúa a Microsoft a la altura de Google y Yahoo, que introdujeron requisitos similares en febrero de 2024, lo que significa que los tres principales proveedores de correo electrónico exigen ahora la autenticación a los remitentes masivos.

Plataformas como PowerDMARC cubren esta necesidad ofreciendo programas de cumplimiento específicos para adaptarse a los requisitos de los proveedores de correo electrónico en todas tus fuentes de envío.

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, capacidades que sí ofrecen las plataformas especializadas en autenticación de correo electrónico.

Falta de informes legibles para las personas

Aunque Microsoft envía ahora informes DMARC a los usuarios empresariales, no existe un sistema integrado que permita agregar e interpretar dichos informes de forma significativa. Estos informes se envían en formato XML y pueden resultar difíciles de analizar sin herramientas especializadas. Como consecuencia, las organizaciones suelen carecer 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 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 plena aplicación de las mismas, a una escala que Microsoft 365 no ofrece de forma nativa.

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

1. No hay ningún registro DMARC publicado

Este es el problema más habitual. La frase «No hay ningún registro DMARC publicado» significa, básicamente, que a tu dominio le falta un registro TXT de DMARC en el DNS, por lo que los destinatarios no disponen de ninguna política sobre la que basar su respuesta.

Para solucionar este problema, primero

• Compruébalo con la ayuda de una herramienta de verificación de DMARC.
• Si la herramienta devuelve el error «Falta el registro DMARC», la solución consiste en publicar un registro que comience por v=DMARC1; p=none; rua=mailto:[email protected], de modo que puedas empezar a recopilar informes antes de endurecer la política.
• Una vez que te hayas familiarizado con la configuración, puedes pasar gradualmente a la aplicación de las normas mientras supervisas tus informes.

2. El reenvío incumple las normas SPF y DKIM

El reenvío de correo electrónico es la principal causa de que el correo legítimo no llegue a su destino. Cuando un intermediario (una lista de correo, un servicio de reenvío o un dispositivo de seguridad) modifica un encabezado incluido en la firma DKIM, la firma deja de ser válida y DKIM falla. El SPF suele fallar al mismo tiempo, ya que la IP del servidor de reenvío no figura en tu registro.

A continuación se indican tres posibles prácticas recomendadas para solucionar este problema:

• Es preferible utilizar la firma DKIM en el origen, ya que DKIM se conserva mejor que SPF tras el reenvío cuando no se reescriben los encabezados
• Evita utilizar el «Sender Rewriting Scheme» (SRS) como solución, ya que, aunque corrige el SPF, no restablece la coincidencia del dominio «From», por lo que DMARC sigue fallando
• Configura los generadores de sellos ARC (Authenticated Received Chain) de confianza en Microsoft Defender para cualquier servicio de reenvío que modifique legítimamente tu correo. Microsoft aceptará el resultado de la autenticación previa a través de la cadena ARC en lugar de rechazar el mensaje directamente.

3. Error permanente de SPF debido a un número excesivo de consultas DNS

Si SPF deja de funcionar de repente para todas las fuentes legítimas y devuelve un Permerror, la causa suele ser estructural, más que de configuración.

Puede haber dos posibles causas para esto:

• La primera es que has superado el límite de 10 consultas que impone el SPF a los mecanismos «include», «a», «mx», «redirect», «exists» y «ptr». Las consultas anidadas dentro de las inclusiones de proveedores también cuentan, por lo que un registro que a simple vista parece correcto puede llegar discretamente a 12 o 13. Cuando se supera ese límite, todos los receptores devuelven un «permerror» y la alineación DMARC basada en SPF se colapsa para todo el dominio de golpe.

Qué hacer: Empieza por revisar tu registro con una herramienta de consulta de SPF y elimina los proveedores que ya no utilices. Pero esto es solo una solución temporal. Una solución a largo plazo consiste en utilizar una solución de SPF alojada, como PowerSPF, con optimización de macros SPF para la gestión dinámica de las consultas de SPF.

• La segunda causa, si observas errores de «temperror» específicamente en destinos de Microsoft, podrían ser los tiempos de espera del DNS. Si los tiempos de espera se producen en una entrada concreta, ese es el proveedor que debes eliminar o excluir del registro.

4. No se están respetando las políticas de «p=rechazar»

Desde julio de 2023, Microsoft aplica por defecto la política «p=reject», es decir, un mensaje con errores debe rechazarse directamente. Si no es así, es porque se da una de estas cuatro situaciones:

• Es posible que la opción de respetar DMARC esté desactivada en su política antiphishing: asegúrese de que la opción «Respetar la política del registro DMARC cuando se detecte que el mensaje es falso» esté activada, y de que la acción para p=reject esté configurada en Rechazar (no en Cuarentena).
• Hay una puerta de enlace de terceros conectada a Microsoft 365: si tu MX apunta a una puerta de enlace de seguridad de terceros, Microsoft no aplicará DMARC a menos que habilites el filtrado mejorado para conectores.
• La autenticación compuesta anula el resultado: Microsoft superpone señales de reputación al DMARC. Un mensaje puede no superar la validación DMARC y, aun así, entregarse si compauth=pass
  (Más información al respecto en la comunidad de aprendizaje de Microsoft).
• Una regla de permiso de un cliente elude el filtrado: un remitente incluido en la lista de permitidos, un conector de entrada de confianza o una regla que asigne un nivel de confianza de spam (SCL) de 1 evitará por completo la aplicación de DMARC.

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 esta responsabilidad sea urgente para cualquiera que envíe grandes volúmenes de correo.

El procedimiento más seguro es el más lento: configura p=none, supervisa tus informes durante dos o cuatro semanas, corrige los remitentes que aparezcan en la lista, y luego pasa a p=quarantine y, finalmente, a p=reject. Saltarse pasos es la razón más común por la que el correo legítimo deja de funcionar durante la implementación.

Una vez que se llega a la fase de aplicación, el trabajo pasa de la configuración al seguimiento. 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. Ahí es donde una plataforma DMARC especializada demuestra su utilidad. Las herramientas de generación de informes y análisis de PowerDMARC convierten el XML sin procesar en información clara y señalizan las desviaciones antes de que se conviertan en un problema de entregabilidad.

Empieza por comprobar tu registro DMARC actual para ver cuál es tu situación actual.

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.

¿Es obligatorio el uso de DMARC en Microsoft?

Sí, Microsoft exige el uso de DMARC a los remitentes de gran volumen. Además, se recomienda encarecidamente a todas las organizaciones que lo utilicen para garantizar la entrega y la protección.

¿Qué es el error 550 5.7.515?

Este error indica que tus correos electrónicos están siendo rechazados debido a la ausencia de políticas DMARC o a que estas no cumplen con las normas de aplicación de Microsoft.

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

Históricamente, Microsoft ha aplicado una configuración interna denominada «oreject» (rechazo de origen), que desvía los mensajes que no superan la validación DMARC a la carpeta de correo no deseado en lugar de rechazarlos directamente en la puerta de enlace. Esta medida se diseñó para proteger a los remitentes legítimos de una pérdida accidental, pero hace que los mensajes falsificados sigan siendo visibles para los destinatarios.

Dos cosas que debes saber:

1) Desde los cambios en la aplicación de la normativa de mayo de 2025, Microsoft está adoptando una política más estricta de rechazo efectivo para los remitentes de gran volumen.

2) Si quieres garantizar el rechazo de los mensajes dentro de tu propio entorno de Microsoft 365, crea una regla de transporte de Exchange que rechace los mensajes de forma definitiva.

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

Empieza por la supervisión (p=ninguna) para controlar tus fuentes de envío y canales de correo electrónico; 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 en orden.

• Acerca de
• Últimas publicaciones

Yunes Tarada

Experto en seguridad de dominios y correo electrónico de 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)

• compauth=fail: Explicación de la autenticación compuesta de Microsoft - 1 de junio de 2026
• ¿Es suficiente Windows Defender para la seguridad de las pequeñas empresas? - 14 de mayo de 2026
• DMARCbis explicado: qué va a cambiar y cómo prepararse - 16 de abril de 2026