Configurar DMARC para validar el dominio de la dirección del remitente para remitentes en la nube

Sugerencia

¿Sabía que puede probar las características de Microsoft Defender para Office 365 Plan 2 de forma gratuita? Use la prueba de 90 días de Defender para Office 365 en el Centro de pruebas del portal de Microsoft Defender. Obtenga información sobre quién puede registrarse y probar los términos en Probar Microsoft Defender para Office 365.

La autenticación de mensajes basada en dominio, informes y conformidad (DMARC) es un método de autenticación por correo electrónico para validar el correo enviado desde la organización de Microsoft 365. Esta validación ayuda a evitar los remitentes suplantados que se utilizan en ataques de suplantación de correo electrónico empresarial (BEC), ransomware y otros ataques de phishing.

Para habilitar DMARC para un dominio, cree un registro TXT en DNS. La validación de DMARC de un mensaje de correo electrónico implica los siguientes elementos:

  • Compruebe que los dominios de las direcciones MAIL FROM y FROM se alinean: SPF y DKIM no requieren que los dominios de las siguientes direcciones de correo electrónico se "alineen" (coincidan):

    • La dirección MAIL FROM: la dirección de correo electrónico utilizada en la transmisión del mensaje entre los servidores de correo electrónico SMTP. Esta dirección también se conoce como la dirección 5321.MailFrom, el remitente P1 o el remitente del sobre.
    • Dirección de origen: la dirección de correo electrónico del campo De encabezado que se muestra como remitente del mensaje en los clientes de correo electrónico. Esta dirección también se conoce como la dirección 5322.From o remitente P2.

    Para obtener más información sobre cómo estas direcciones de correo electrónico pueden estar en dominios diferentes y usarse para la suplantación de identidad, consulte Por qué el correo electrónico de Internet necesita autenticación.

    • DMARC usa el resultado de SPF para comprobar las dos condiciones siguientes:

      • El mensaje procede de un origen autorizado para el dominio usado en la dirección MAIL FROM (requisito básico de SPF).
      • Los dominios de las direcciones MAIL FROM y From del mensaje están alineados. Este resultado requiere efectivamente que las fuentes válidas del mensaje estén en el dominio de la dirección From.

    • DMARC usa el resultado de DKIM para comprobar que el dominio que firmó el mensaje (el valor d= en un campo de encabezado DKIM-Signature tal como lo valida el valor del selector s= ) se alinea con el dominio de la dirección Desde.

    Un mensaje pasa DMARC si se superan una o ambas comprobaciones de SPF o DKIM descritas. Un mensaje produce un error en DMARC si se producen errores en las comprobaciones SPF y DKIM descritas.

  • Directiva DMARC: especifica qué hacer con los mensajes que producen un error en DMARC (rechazo, cuarentena o ninguna instrucción).

  • Informes de DMARC: especifica dónde enviar informes:

    • Informes agregados (un resumen periódico de los resultados positivos y negativos de DMARC).
    • Informes forenses (también conocidos como informes de errores; resultados de errores casi inmediatos de DMARC similares a un informe de no entrega o mensaje de rebote).

Antes de empezar, esto es lo que necesita saber sobre DMARC en Microsoft 365 en función de su dominio de correo electrónico:

  • Si usa solo el dominio de dirección de enrutamiento de correo electrónico de Microsoft Online (MOERA) para el correo electrónico (por ejemplo, contoso.onmicrosoft.com): Aunque SPF y DKIM ya están configurados para el dominio *.onmicrosoft.com, debe crear el registro TXT de DMARC para el dominio *.onmicrosoft.com en el centro de administración de Microsoft 365. Para obtener instrucciones, consulte Uso del Centro de administración de Microsoft 365 para agregar registros TXT de DMARC para dominios *.onmicrosoft.com en Microsoft 365. Para obtener más información sobre los dominios *.onmicrosoft.com, consulte ¿Por qué tengo un dominio "onmicrosoft.com"?

  • Si usa uno o varios dominios personalizados para el correo electrónico (por ejemplo, contoso.com): si aún no lo ha hecho, debe configurar SPF para todos los dominios y subdominios personalizados que use para el correo electrónico. También es necesario configurar la firma DKIM utilizando el dominio o subdominio personalizado, de modo que el dominio utilizado para firmar el mensaje coincida con el dominio de la dirección De. Para obtener instrucciones, consulte los artículos siguientes:

    Después de eso, también debe configurar los registros TXT de DMARC para los dominios personalizados, como se describe en este artículo. También tiene las siguientes consideraciones:

    • Subdominios:

      • Para los servicios de correo electrónico que no están bajo su control directo (por ejemplo, servicios de correo electrónico masivos), use un subdominio (por ejemplo, marketing.contoso.com) en lugar de su dominio de correo electrónico principal (por ejemplo, contoso.com). No quiere que los problemas con el correo enviado desde esos servicios de correo electrónico afecten a la reputación del correo enviado por los usuarios en el dominio de correo electrónico principal. Para obtener más información sobre cómo agregar subdominios, consulte ¿Puedo agregar subdominios personalizados o varios dominios a Microsoft 365?.
      • A diferencia de SPF y DKIM, el registro TXT de DMARC para un dominio cubre automáticamente todos los subdominios (incluidos los subdominios inexistentes) que no tienen su propio registro TXT de DMARC. En otras palabras, puede interrumpir la herencia de DMARC en un subdominio mediante la creación de un registro TXT de DMARC en ese subdominio. Sin embargo, cada subdominio requiere un registro SPF y DKIM para DMARC.

    • Si posee dominios registrados pero no utilizados: si posee dominios registrados que no se usan para correo electrónico o nada (también conocidos como dominios estacionados), configure los registros TXT de DMARC en esos dominios para especificar que ningún correo electrónico debe proceder de esos dominios. Esta directiva incluye el dominio *.onmicrosoft.com si no lo usa para el correo electrónico.

  • Las comprobaciones de DMARC para el correo entrante pueden necesitar ayuda: si usa un servicio de correo electrónico que modifica los mensajes en tránsito antes de la entrega a Microsoft 365, es posible que pueda identificar el servicio como un sellador de ARC de confianza. Los selladores ARC de confianza evitan que los mensajes modificados fallen automáticamente en las comprobaciones de DMARC. Para obtener más información, consulte Pasos siguientes.

El resto de este artículo trata la creación de registros TXT de DMARC, la implementación gradual de dominios personalizados y el control de DMARC de entrada en Microsoft 365.

Sugerencia

Para crear el registro TXT de DMARC para su dominio *.onmicrosoft.com en el centro de administración de Microsoft 365, consulte Uso del centro de administración de Microsoft 365 para agregar registros TXT de DMARC para dominios *.onmicrosoft.com en Microsoft 365.

No hay portales de administración ni cmdlets de PowerShell en Microsoft 365 para que pueda administrar los registros TXT de DMARC en los dominios personalizados . En su lugar, se crea el registro TXT de DMARC en el registrador de dominios o el servicio de hospedaje DNS (a menudo la misma empresa).

Se proporcionan instrucciones para crear el registro TXT de prueba de propiedad de dominio para Microsoft 365 en muchos registradores de dominio. Puede usar estas instrucciones como punto de partida para crear registros TXT de DMARC. Para obtener más información, consulte Agregar registros DNS para conectar el dominio.

Si no está familiarizado con la configuración de DNS, póngase en contacto con el registrador de dominios y solicite ayuda.

Sintaxis de los registros TXT de DMARC

Los registros TXT de DMARC se describen exhaustivamente en RFC 7489.

La sintaxis básica del registro TXT de DMARC para un dominio en Microsoft 365 es:

Nombre de host: _dmarc
Valor TXT: v=DMARC1; <DMARC policy>; <Percentage of DMARC failed mail subject to DMARC policy>; <DMARC reports>

Otra posibilidad:

Nombre de host: _dmarc
Valor TXT: v=DMARC1; p=<reject | quarantine | none>; pct=<0-100>; rua=mailto:<DMARCAggregateReportURI>; ruf=mailto:<DMARCForensicReportURI>

Por ejemplo:

Nombre de host: _dmarc
Valor TXT: v=DMARC1; p=reject; pct=100; rua=mailto:rua@contoso.com; ruf=mailto:ruf@contoso.com

  • Se requiere el valor _dmarc del nombre de host.

  • v=DMARC1; identifica el registro TXT como un registro TXT de DMARC.

  • Directiva DMARC: indica al sistema de correo electrónico de destino qué hacer con los mensajes que producen errores dmARC (rechazar, poner en cuarentena o sin acción):

    • p=reject: se deben rechazar los mensajes. Lo que realmente sucede con el mensaje depende del sistema de correo electrónico de destino, pero los mensajes suelen descartarse.
    • p=quarantine: Los mensajes deben aceptarse, pero marcarse. Lo que realmente sucede con el mensaje depende del sistema de correo electrónico de destino. Por ejemplo, es posible que el mensaje se ponga en cuarentena como correo no deseado, se entregue en la carpeta de Email no deseado o se entregue en la Bandeja de entrada con un identificador agregado al cuerpo del asunto o del mensaje.
    • p=none: no hay ninguna acción sugerida para los mensajes que producen un error en DMARC. Lo que sucede con el mensaje depende de las características de protección de correo electrónico en el sistema de correo electrónico de destino. Use este valor para probar y ajustar la directiva DMARC.

    Sugerencia

    El correo saliente de los dominios de Microsoft 365 que no cumplen las comprobaciones de DMARC por el servicio de correo electrónico de destino se enruta a través del grupo de entrega de alto riesgo para los mensajes salientes si la directiva DMARC para el dominio es p=reject o p=quarantine. No hay ninguna opción para anular este comportamiento.

  • Porcentaje de mensajes que no superan DMARC a los que se aplica la directiva DMARC: Indica al sistema de correo electrónico de destino a cuántos mensajes que no superan DMARC (porcentaje) se les aplica la directiva DMARC. Por ejemplo, pct=100 significa que todos los mensajes que producen un error en DMARC obtienen la directiva DMARC aplicada a ellos. Use valores inferiores a 100 para probar y optimizar la directiva DMARC. Si no usa pct=, el valor predeterminado es pct=100.

  • Informes de DMARC:

    • URI de informe agregado de DMARC: el rua=mailto: valor identifica dónde enviar el informe agregado de DMARC. El informe Agregado tiene las siguientes propiedades:

      • Los mensajes de correo electrónico que contienen el informe agregado se suelen enviar una vez al día (el informe contiene los resultados de DMARC del día anterior). La línea Asunto contiene el dominio de destino que envió el informe (Submitter) y el dominio de origen para los resultados de DMARC (dominio de informe).
      • Los datos DMARC están en un archivo adjunto de correo electrónico XML que probablemente esté comprimido con GZIP. El esquema XML se define en el apéndice C de RFC 7489. El informe contiene la siguiente información:
        • Las direcciones IP de los servidores o servicios que envían correo mediante el dominio.
        • Si los servidores o servicios pasan o no la autenticación DMARC.
        • Las acciones que DMARC aplica al correo que no supera la autenticación DMARC (según la política de DMARC).

      Sugerencia

      La información del informe agregado puede ser vasta y difícil de analizar. Para ayudar a entender los datos, puede usar las siguientes opciones para los informes de DMARC:

      • Cree automatización mediante PowerShell o Microsoft Power BI.
      • Use un servicio externo. Para obtener una lista de servicios, busque DMARC en el catálogo de Asociación de seguridad inteligente de Microsoft (MISA) en https://www.microsoft.com/misapartnercatalog. Los servicios de informes de DMARC describen los valores personalizados necesarios en el registro TXT de DMARC.

    • URI del informe forense de DMARC: el ruf=mailto: valor identifica dónde enviar el informe forense de DMARC (también conocido como informe de errores de DMARC). El informe se genera y se envía inmediatamente después de un error de DMARC, como un informe de no entrega (también conocido como NDR o mensaje de rebote).

    Sugerencia

    Debe revisar periódicamente los informes agregados de DMARC para supervisar de dónde procede el correo electrónico de sus dominios y para comprobar si hay errores de DMARC involuntarios (falsos positivos).

    Los sistemas de correo electrónico de destino individuales son responsables de enviarle informes de DMARC. La cantidad y variedad de informes de DMARC varían de la misma manera que el volumen y la variedad de correo enviado desde su organización varía. Por ejemplo, espere un menor volumen de correo durante los días festivos y un mayor volumen de correo durante los eventos de la organización. Es mejor designar personas específicas para supervisar los informes de DMARC y usar un buzón específico o un grupo de Microsoft 365 para recibir los informes de DMARC (no entregar los informes al buzón de un usuario).

Para obtener más información sobre DMARC, use los siguientes recursos:

Use el Centro de administración de Microsoft 365 para agregar registros TXT de DMARC para dominios *.onmicrosoft.com en Microsoft 365

Realice los pasos siguientes para agregar un registro TXT de DMARC para el dominio *.onmicrosoft.com en el Centro de administración de Microsoft 365.

  1. En el centro de administración de Microsoft 365 en https://admin.microsoft.com, seleccione Mostrar todo>Configuración>Dominios. O bien, para ir directamente a la página Dominios , use https://admin.microsoft.com/Adminportal/Home#/Domains.

  2. En la página Dominios , seleccione el dominio *.onmicrosoft.com de la lista haciendo clic en cualquier lugar de la fila que no sea la casilla situada junto al nombre de dominio.

  3. En la página de detalles del dominio que se abre, seleccione la pestaña Registros DNS .

  4. En la pestaña Registros DNS , seleccione Agregar registro.

  5. En el panel desplegable Agregar un registro DNS personalizado que se abre, configure los siguientes valores:

    • Tipo: compruebe que txt (texto) está seleccionado.

    • Nombre del TXT: Escriba _dmarc.

    • Valor TXT: Introduzca v=DMARC1; p=reject.

      Sugerencia

      Para especificar destinos para los informes dmarc aggregate y DMARC Forensic, use la sintaxis v=DMARC1; p=reject; rua=mailto:<emailaddress>; ruf=mailto:<emailaddress>. Por ejemplo, v=DMARC1; p=reject; rua=mailto:rua@contoso.onmicrosoft.com; ruf=mailto:ruf@contoso.onmicrosoft.com.

      Los proveedores de informes de DMARC en el catálogo MISA en https://www.microsoft.com/misapartnercatalog facilitan la visualización e interpretación de los resultados de DMARC.

    • TTL: compruebe que se ha seleccionado 1 hora .

    Cuando termine en el panel flotante Agregar un registro DNS personalizado, seleccione Guardar.

Configuración de DMARC para dominios personalizados activos en Microsoft 365

Sugerencia

Antes de configurar DMARC para dominios personalizados o subdominios, debe crear registros TXT de SPF y configurar la firma DKIM para todos los dominios y subdominios personalizados que use para enviar correo electrónico en Microsoft 365.

Se recomienda un enfoque gradual para configurar DMARC para los dominios de Microsoft 365. El objetivo es llegar a tener una directiva DMARC p=reject para todos sus dominios y subdominios personalizados, pero debe probar y verificar durante el proceso para evitar que los sistemas de correo electrónico de destino rechacen correo legítimo debido a fallos de DMARC involuntarios.

El plan de implementación de DMARC debe seguir estos pasos. Comience con un dominio o subdominio con un volumen de correo bajo o menos orígenes de correo electrónico potenciales (menos posibilidad de que se bloquee el correo legítimo de orígenes desconocidos):

  1. Comience con una directiva DMARC de p=none y supervise los resultados del dominio. Por ejemplo:

    Registro TXT de DMARC para marketing.contoso.com:

    Nombre de host: _dmarc
    Valor TXT: v=DMARC1; p=none; pct=100; rua=mailto:rua@marketing.contoso.com; ruf=mailto:ruf@marketing.contoso.com

    Los informes agregados de DMARC y los informes forenses de DMARC proporcionan el número y las fuentes de los mensajes que superan y no superan las comprobaciones de DMARC. Puede ver cuánto tráfico de correo legítimo está cubierto o no por DMARC y solucionar cualquier problema. También puede ver cuántos mensajes fraudulentos se envían y desde dónde se envían.

  2. Aumente la directiva DMARC a p=quarantine y supervise los resultados del dominio.

    Después de tiempo suficiente para supervisar los efectos de p=none, puede aumentar la directiva DMARC a p=quarantine para el dominio. Por ejemplo:

    Registro TXT de DMARC para marketing.contoso.com:

    Nombre de host: _dmarc
    Valor TXT: v=DMARC1; p=quarantine; pct=100; rua=mailto:rua@marketing.contoso.com; ruf=mailto:ruf@marketing.contoso.com

    También puede usar el pct= valor para afectar gradualmente a más mensajes y comprobar los resultados. Por ejemplo, puede avanzar en los siguientes incrementos:

    • pct=10
    • pct=25
    • pct=50
    • pct=75
    • pct=100

  3. Aumente la directiva DMARC a p=reject y supervise los resultados del dominio.

    Después de tiempo suficiente para supervisar los efectos de p=quarantine, puede aumentar la directiva DMARC a p=reject para el dominio. Por ejemplo:

    Registro TXT de DMARC para marketing.contoso.com:

    Nombre de host: _dmarc
    Valor TXT: v=DMARC1; p=reject; pct=100; rua=mailto:rua@marketing.contoso.com; ruf=mailto:ruf@marketing.contoso.com

    También puede usar el pct= valor para afectar gradualmente a más mensajes y comprobar los resultados.

  4. Repita los tres pasos anteriores para los subdominios restantes de mayor volumen o complejidad, guardando el dominio primario por última vez.

    Sugerencia

    Bloquear correo electrónico legítimo en grandes cantidades es inaceptable para los usuarios, pero es casi inevitable que se produzcan algunos falsos positivos. Vaya despacio y metódicamente a tratar los problemas que se revelan en los informes de DMARC. Los proveedores de informes de DMARC en el catálogo MISA en https://www.microsoft.com/misapartnercatalog facilitan la visualización e interpretación de los resultados de DMARC.

  5. Los subdominios heredan la configuración del registro TXT de DMARC del dominio principal, que puede sustituir mediante un registro TXT de DMARC independiente en el subdominio. Cuando haya terminado de configurar DMARC en un dominio y todos los subdominios, y la configuración de DMARC sea efectivamente idéntica para el dominio primario y todos los subdominios, puede eliminar los registros TXT de DMARC en los subdominios y confiar en el único registro TXT de DMARC en el dominio primario.

Registros TXT de DMARC para dominios estacionados en Microsoft 365

Sugerencia

El registro TXT de SPF recomendado para dominios estacionados que no envían correo se describe en Registros TXT de SPF para dominios de nube personalizados. Como se describe en Configuración de DKIM para firmar correo desde el dominio en la nube, los registros CNAME de DKIM no se recomiendan para dominios estacionados.

  1. Si ha registrado dominios de los que nadie en Internet debe esperar recibir correo, cree el siguiente registro TXT de DMARC en el registrador de dominios del dominio:

    Nombre de host: _dmarc
    Valor TXT: v=DMARC1; p=reject;

    • El pct= valor no se incluye, porque el valor predeterminado es pct=100.
    • Puede decirse que los valores rua=mailto: y ruf=mailto: no son necesarios en este caso, porque ningún correo válido debería proceder de remitentes del dominio.

  2. Si no usa el dominio *.onmicrosoft.com para enviar correo, también debe agregar el registro TXT de DMARC para el dominio *.onmicrosoft.com.

DMARC para el correo entrante en Microsoft 365

Las siguientes características y comportamientos influyen en cómo Microsoft 365 evalúa DMARC para los mensajes entrantes y si se envían informes de DMARC.

  • Las siguientes características de seguridad integradas para todos los buzones de correo en la nube afectan a las comprobaciones de DMARC en el correo entrante:

    • Si la inteligencia contra la suplantación de identidad está habilitada o deshabilitada en la directiva contra la suplantación de identidad (phishing) que comprobó el mensaje. Desactivar la inteligencia contra la suplantación desactiva únicamente la protección implícita contra la suplantación procedente de las comprobaciones de autenticación compuesta.
    • Si la opción Respetar la directiva del registro DMARC cuando se detecte que el mensaje es suplantado está habilitada o deshabilitada en la directiva de antiphishing que evaluó el mensaje, y las acciones especificadas en función de la directiva DMARC del dominio de origen (p=quarantine, o p=reject en el registro TXT de DMARC).

    Para obtener información completa, consulte Protección contra suplantación de identidad y directivas DMARC de remitente.

    Para ver los valores predeterminados de esta configuración en las directivas contra phishing, compruebe los valores de configuración de la tabla en Configuración de directivas anti phishing para todos los buzones de correo en la nube.

  • Microsoft 365 no envía informes forenses de DMARC (también conocidos como informes de errores de DMARC), incluso si existe una dirección válida ruf=mailto: en el registro TXT de DMARC del dominio de origen.

  • Microsoft 365 envía informes agregados de DMARC a todos los dominios con una dirección válida rua=mailto: en los registros TXT de DMARC, siempre y cuando el registro MX del dominio de Microsoft 365 apunte directamente a Microsoft 365.

    Si enruta el correo de Internet a través de un servicio o dispositivo que no sea de Microsoft antes de su entrega a Microsoft 365 (los puntos de registro MX en algún lugar distinto de Microsoft 365), no se enviarán los informes agregados de DMARC. Esta limitación incluye escenarios híbridos en los que el correo se entrega al entorno local antes de enrutarse a Microsoft 365 mediante un conector.

    Sugerencia

    Cuando un servicio o dispositivo que no es de Microsoft se encuentra delante del correo que fluye a Microsoft 365, el filtrado mejorado para conectores (también conocido como lista de omitir) identifica correctamente el origen de los mensajes de Internet para SPF, DKIM (si el servicio modifica los mensajes) y la validación de DMARC.

Solución de problemas de DMARC

Para obtener una tabla de referencia rápida de errores, causas y correcciones de DMARC, consulte Solución de problemas de autenticación de correo electrónico en Microsoft 365.

Esta sección le ayuda a diagnosticar y resolver errores comunes de DMARC, a comprender cómo actúa Microsoft 365 en diferentes directivas de DMARC e interpretar informes forenses y agregados de DMARC.

Diagrama del proceso de solución de problemas de DMARC

Diagnóstico de errores de alineación

Como se describe en Configurar DMARC para validar el dominio de la dirección del remitente para remitentes en la nube, un mensaje supera DMARC si al menos una comprobación de alineación se realiza correctamente (SPF o DKIM). Un mensaje produce un error en DMARC solo si se producen errores en ambas comprobaciones de alineación.

Modos de alineación

Las aspf etiquetas (SPF) y adkim (DKIM) del registro TXT de DMARC controlan la estricta coincidencia del dominio From con el dominio autenticado. Ambos son opcionales y el valor predeterminado r es (relajado), pero s (estricto) también está disponible. En el ejemplo siguiente se muestra un registro TXT de DMARC que usa la alineación SPF estricta (aspf=s) y la alineación DKIM relajada (adkim=r):

Hostname: _dmarc
TXT value: v=DMARC1; p=reject; aspf=s; adkim=r; pct=100; rua=mailto:dmarc@contoso.com
  • Relajado (rvalor predeterminado): los dominios organizativos (dominios raíz) deben coincidir. Se permiten subdominios.
  • Strict (s): los FQDN deben coincidir exactamente. No hay coincidencia de subdominios.

Nota:

Las aspf etiquetas y adkim son independientes. Puede usar modos diferentes para cada uno, como se muestra en el ejemplo. Un mensaje supera la verificación DMARC si cualquiera de las dos comprobaciones de alineación tiene éxito, por lo que un error estricto en una comprobación no importa si la otra comprobación se supera con una alineación menos estricta.

Ejemplos:

Dirección del remitente MAIL FROM / DKIM-Signature d= dirección Relajado (r) Estricto (s)
user@contoso.com contoso.com ✅ Aprobado ✅ Aprobado
user@contoso.com bounces.contoso.com ✅ Aprobado ❌ Fallido
user@marketing.contoso.com contoso.com ✅ Aprobado ❌ Fallido
user@contoso.com contoso.onmicrosoft.com ❌ Fallido ❌ Fallido
user@contoso.com adatum.net ❌ Fallido ❌ Fallido

Escenarios comunes de error de alineación

En la tabla siguiente se enumeran los escenarios comunes de error de alineación de DMARC, sus síntomas, las causas principales y las correcciones recomendadas.

Escenario Síntoma Causa principal Solución
Un servicio ajeno a Microsoft envía en su nombre SPF pasa para adatum.com, pero se produce un error en DMARC MAIL FROM utiliza el dominio del servicio (por ejemplo, bounce.adatum.com) y no se aplica la firma DKIM con tu dominio. Configure la firma DKIM con su dominio en el servicio, o cambie MAIL FROM a su dominio/subdominio
Reenvío automático de Microsoft 365 DMARC falla en el destino. El reenvío cambia el remitente del sobre; La firma DKIM podría interrumpirse Utiliza selladores de confianza ARC en el destino o utiliza DKIM (se mantiene tras el reenvío si no se modifica el cuerpo del mensaje).
Envíos desde subdominios con alineación estricta aspf=s provoca errores para los remitentes de subdominios MAIL FROM es sub.contoso.com pero From es contoso.com Cambie a aspf=r (relajado) o asegúrese de que la dirección del remitente coincida con el subdominio.
No coincidencia de dominio de firma DKIM DKIM pasa, pero DMARC sigue fallando El valor de DKIM d= (por ejemplo, adatum.com) no coincide con el dominio From (contoso.com) Configurar la firma DKIM personalizada en el servicio con tu dominio
Buzón compartido o grupo de distribución DMARC produce un error intermitente Reply-from o la redirección modifican las direcciones del sobre. Compruebe que DKIM esté intacto; considere el uso de ARC para servicios intermediarios

Diagnóstico de errores de alineación a partir de encabezados de mensaje

Paso 1: Abra los encabezados del mensaje y busque el encabezado Authentication-Results de Microsoft 365. En el ejemplo siguiente se muestra un encabezado Authentication-Results en el que SPF y DKIM superan la comprobación individualmente, pero DMARC falla porque ninguno de los dominios se alinea con el dominio de la dirección From:

Authentication-Results: spf=pass (sender IP is 198.51.100.10)
  smtp.mailfrom=bounces.adatum.com; dkim=pass (signature was verified)
  header.d=adatum.com; dmarc=fail action=oreject
  header.from=contoso.com;compauth=fail reason=000

Paso 2: Identificar el error de alineación:

Comprobar Campo de encabezado Valor en el ejemplo ¿Coincide con Desde (contoso.com)?
Alineación SPF smtp.mailfrom= bounces.adatum.com ❌ No (dominio de organización diferente)
Alineación DKIM header.d= adatum.com ❌ No (dominio de organización diferente)
Resultado de DMARC dmarc= fail Error en ambas comprobaciones

Paso 3: Determine la corrección respondiendo a las siguientes preguntas:

  1. ¿Puede cambiar la dirección MAIL FROM por su dominio (por ejemplo, bounces.contoso.com en lugar de bounces.adatum.com)?
    • Sí: configure el cambio MAIL FROM en el servicio para corregir la alineación de SPF.
    • No: use la alineación DKIM en su lugar (vaya al paso 2).
  2. ¿Puede el servicio firmar con su dominio (d=contoso.com)?
    • Sí: configure la firma DKIM personalizada en el servicio.
    • No: considere la posibilidad de usar una estrategia de subdominio:
      • Enviar desde un subdominio (por ejemplo, sub.contoso.com).
      • Publique un registro DMARC independiente para ese subdominio.
      • Haga que el servicio firme con DKIM usando d=sub.contoso.com.

Comprobación de la alineación de mensajes recientes en PowerShell

Conéctese a Exchange Online PowerShell y ejecute los siguientes comandos:

# Get recent messages and check authentication results
$messages = Get-MessageTrace -StartDate (Get-Date).AddDays(-1) -EndDate (Get-Date) -PageSize 100

foreach ($msg in $messages) {
    $details = Get-MessageTraceDetail -MessageTraceId $msg.MessageTraceId -RecipientAddress $msg.RecipientAddress
    $authEvent = $details | Where-Object { $_.Event -eq "Receive" }
    if ($authEvent.Detail -match "dmarc=fail") {
        Write-Output "DMARC FAIL: From=$($msg.SenderAddress), Subject=$($msg.Subject)"
    }
}

Efecto de la directiva DMARC en el comportamiento de Microsoft 365

Como se describe en DMARC para el correo de entrada, el comportamiento de Microsoft 365 depende de la configuración Respetar la directiva del registro DMARC. Para obtener detalles completos, consulte Protección contra suplantación de identidad y directivas DMARC del remitente.

En el siguiente resumen se muestra el comportamiento general de los mensajes entrantes que no superan DMARC cuando Respetar la directiva del registro DMARC está Activado (recomendado):

Directiva DMARC del remitente Estado del mensaje Resultados de autenticación CompAuth
p=none No hay ninguna acción específica de DMARC. Todavía se aplica otro filtrado. dmarc=fail action=none Basado en la autenticación compuesta (SPF, DKIM, inteligencia de suplantación de identidad)
p=quarantine Carpeta de Email no deseado (configurable para poner en cuarentena) dmarc=fail action=quarantine compauth=fail reason=100
p=reject Rechazado durante SMTP (550 5.7.1) dmarc=fail action=oreject compauth=fail reason=100

Precaución

Tenga cuidado al anular p=reject para remitentes legítimos. Si su organización recibe legítimamente correo de un remitente cuya DMARC produce un error (por ejemplo, correo reenviado, listas de correo), use uno de estos enfoques:

  • Configure al remitente como un sellador ARC de confianza (opción preferida).
  • Cree una regla de flujo de correo con condiciones específicas (ip del remitente y dominio de remitente) para omitir el filtrado de correo no deseado.
  • Añada una entrada de permiso en la Lista de permisos/bloqueos del inquilino (temporal, caduca en 30 días).

Valores de acción de DMARC en Authentication-Results

En el encabezado Authentication-Results, puede ver estos valores de acción de DMARC:

Valor de acción Significado
action=none El remitente publicó p=none; no se realizó ninguna acción
action=quarantine Remitente publicado p=quarantine; mensaje en cuarentena o en la bandeja de correo no deseado
action=oreject Remitente publicado p=reject; mensaje rechazado ("o" = origen)
action=pct.quarantine El remitente publicó p=quarantine con pct= inferior a 100; este mensaje estaba dentro del porcentaje muestreado
action=pct.reject El remitente publicó p=reject con pct= inferior a 100; este mensaje estaba dentro del porcentaje muestreado

Interpretación del informe DMARC

Esta sección te ayuda a interpretar los informes agregados y forenses de DMARC que los receptores envían a tus direcciones rua y ruf. Para obtener información sobre cómo configurar los rua valores y ruf en el registro TXT de DMARC, vea Sintaxis para registros TXT de DMARC.

Informes agregados

En el ejemplo siguiente se muestra la estructura XML de un informe agregado:

<?xml version="1.0" encoding="UTF-8"?>
<feedback>
  <report_metadata>
    <org_name>microsoft.com</org_name>           <!-- Reporting organization -->
    <email>dmarceng@microsoft.com</email>
    <report_id>unique-report-id</report_id>
    <date_range>
      <begin>1700000000</begin>                   <!-- Unix timestamp: start -->
      <end>1700086400</end>                       <!-- Unix timestamp: end -->
    </date_range>
  </report_metadata>

  <policy_published>
    <domain>contoso.com</domain>                  <!-- Your domain -->
    <adkim>r</adkim>                              <!-- DKIM alignment mode -->
    <aspf>r</aspf>                                <!-- SPF alignment mode -->
    <p>reject</p>                                 <!-- Domain policy -->
    <sp>quarantine</sp>                           <!-- Subdomain policy -->
    <pct>100</pct>                                <!-- Percentage -->
  </policy_published>

  <record>
    <row>
      <source_ip>198.51.100.10</source_ip>        <!-- Sending IP -->
      <count>1523</count>                         <!-- Number of messages -->
      <policy_evaluated>
        <disposition>none</disposition>           <!-- What receiver did -->
        <dkim>pass</dkim>                         <!-- DKIM alignment result -->
        <spf>fail</spf>                           <!-- SPF alignment result -->
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>contoso.com</header_from>      <!-- From address domain -->
      <envelope_from>bounces.adatum.com</envelope_from>
    </identifiers>
    <auth_results>
      <dkim>
        <domain>contoso.com</domain>
        <result>pass</result>
        <selector>selector1</selector>
      </dkim>
      <spf>
        <domain>bounces.adatum.com</domain>
        <result>pass</result>                     <!-- SPF passed but... -->
      </spf>
    </auth_results>
  </record>
</feedback>

Leer informes agregados

Use la tabla siguiente para interpretar los campos más importantes de un informe agregado de DMARC y determinar qué acción de solución de problemas se debe realizar.

Elemento XML Lo que te indica Acción de solución de problemas
<source_ip> La dirección IP que envió los mensajes Identificar si se trata de un remitente legítimo o no autorizado
<count> Número de mensajes de este origen Recuento alto de direcciones IP desconocidas = posible suplantación de identidad
<disposition> Acción que realizó el receptor (none, quarantine, reject) Comprobación de que el receptor respeta la directiva
<dkim> debajo de <policy_evaluated> Si DKIM está alineado (no solo ha superado la verificación) fail = El dominio DKIM no coincide con el dominio del remitente
<spf> debajo de <policy_evaluated> Si SPF está alineado (no solo aprobado) fail = El dominio MAIL FROM no coincide con el dominio De
<domain> debajo de <auth_results><spf> Dominio con el que se ha comprobado SPF Si es diferente del dominio De = problema de alineación
<domain> debajo de <auth_results><dkim> Dominio de firma DKIM Debe coincidir el dominio From para la alineación de DMARC
<result> debajo de <auth_results> Resultado en bruto de SPF/DKIM: aprobado/fallido (antes de la comprobación de alineación) pass + alineación fail = problema de alineación clásica

Sugerencia

La información más importante de los informes agregados es identificar la brecha entre el paso de autenticación y el paso de alineación:

  • <auth_results><spf><result>pass</result> + <policy_evaluated><spf>fail</spf> = SPF ha superado la comprobación, pero los dominios no están alineados.
  • Esta combinación significa que el remitente está autorizado (paso SPF), pero no está configurado correctamente para DMARC (error de alineación).

Patrones comunes de informes agregados y correcciones

En la tabla siguiente se muestran patrones comunes que puede encontrar en informes agregados y las acciones que normalmente requieren.

Patrón en el informe Interpretación Corregir
IP conocida, autenticación SPF = aprobada, alineación SPF = fallida Servicio legítimo con un dominio MAIL FROM incorrecto Configurar el servicio para que use tu dominio en MAIL FROM o configurar la firma DKIM con tu dominio
IP conocida, autenticación DKIM = aprobada, alineación DKIM = fallida El servicio firma DKIM con su propio dominio Configura DKIM personalizado en el servicio con d=contoso.com
IP desconocida, alto volumen, todo falla Posible campaña de suplantación de identidad/phishing No se necesita ninguna acción. Su política de DMARC protege a los destinatarios.
IP conocida (Microsoft 365), SPF alineado = aprobado Flujo de correo normal de Microsoft 365 Correcto. No se necesita ninguna acción.
Bajo volumen del servicio legítimo, error de SPF+DKIM Servicio no incluido en SPF y que no firma con DKIM Adición de servicio al registro SPF o configuración de DKIM
Correo reenviado (IP de listas de correo), todos fallan El reenvío de correo invalida SPF; la modificación del cuerpo del mensaje invalida DKIM Es normal en el correo reenviado. Use ARC o acepte algunos errores.

Informes forenses

Como se indica en la sección DMARC para correo entrante , Microsoft 365 no envía informes forenses. Sin embargo, es posible que los reciba de otros proveedores. En la tabla siguiente se comparan los dos tipos de informe:

Aspecto Informes agregados (rua) Informes forenses (ruf)
Frequency Diariamente (normalmente) Casi en tiempo real (por cada error)
Contenido Estadísticas de resumen por dirección IP de origen Detalles de mensajes individuales
Volume Un informe por día por reportero Un informe por error (puede ser de gran volumen)
Privacidad Solo direcciones IP y recuentos Puede incluir encabezados o el cuerpo del mensaje (redactados)
Soporte técnico Ampliamente compatible con los receptores Compatibilidad limitada (muchos receptores no envían ruf)
Caso de uso Análisis de tendencias, identificación de remitentes desconocidos Depuración de errores específicos, investigación forense

Nota:

Si necesita detalles de error por mensaje de Microsoft 365, use el seguimiento de mensajes y el análisis del encabezado de mensaje en lugar de los informes forenses.

En el ejemplo siguiente se muestra la estructura de un informe forense de DMARC (formato AFRF/RFC 6591) que un receptor envía a su ruf dirección cuando se produce un error en un mensaje DMARC. Busque los Feedback-Typecampos , Source-IPy Authentication-Results para identificar los detalles del error:

From: noreply-dmarc-support@fabrikam.com
To: ruf@contoso.com
Subject: Report Domain: contoso.com Submitter: fabrikam.com

Feedback-Type: auth-failure
User-Agent: fabrikam.com/dmarc-reporter
Version: 1
Original-Mail-From: bounces@adatum.com
Arrival-Date: Mon, 15 Jan 2024 10:30:00 -0000
Source-IP: 198.51.100.10
Authentication-Results: fabrikam.com; dmarc=fail (p=reject)
  header.from=contoso.com
Reported-Domain: contoso.com
Original-Envelope-Id: <abc123@mail.adatum.com>

Procedimientos recomendados para informes de DMARC

Use los siguientes procedimientos recomendados para administrar los informes de DMARC de forma eficaz.

Recomendación Detalles
Uso de un buzón dedicado para rua Cree un buzón compartido (por ejemplo, dmarc-reports@contoso.com). No use buzones de usuario individuales.
Uso de un grupo de Microsoft 365 Los grupos proporcionan una mejor colaboración y acceso compartido para el equipo de seguridad.
Consideración de un servicio de informes de DMARC Los servicios de informes DMARC procesan archivos XML para generar paneles. Busque DMARC en el catálogo MISA.
Empezar solo con rua Agregue ruf más adelante si es necesario. Los informes forenses pueden generar un gran volumen.
Supervisión periódica Revise los informes agregados semanalmente durante la implementación inicial; mensual una vez estable
Establecer expectativas realistas No todos los receptores envían informes. La cobertura suele ser del 70 al 90 % del volumen total de correo

Informes entre dominios

Si la dirección DMARC rua o ruf pertenece a un dominio distinto del dominio supervisado, el dominio receptor debe publicar un registro DNS TXT que autorice la entrega del informe:

Ejemplo: DMARC para contoso.com enviar informes a dmarc@fabrikam.com

Para autorizar fabrikam.com a recibir informes DMARC en nombre de contoso.com, el administrador de fabrikam.com debe publicar el siguiente registro TXT de DNS:

Hostname: contoso.com._report._dmarc
Type: TXT
Value: v=DMARC1;

Sin este registro, los receptores no entregan informes DMARC a la dirección externa.

Referencia rápida de solución de problemas de DMARC

En la tabla siguiente se proporciona una referencia rápida para los síntomas comunes de DMARC, sus causas probables, pasos de diagnóstico y resoluciones.

Síntoma Causa probable Paso de diagnóstico Solución
dmarc=fail pero SPF y DKIM pasan de forma individual Error de alineación: los dominios no coinciden From Comprobar smtp.mailfrom= y header.d= vs header.from= en Authentication-Results Configuración de SPF/DKIM con dominios alineados
dmarc=bestguesspass No se ha publicado ningún registro DMARC para el dominio From Consultar el registro TXT _dmarc.domain.com Microsoft deduce que se ha aprobado. Publique un registro DMARC explícito.
dmarc=fail action=oreject pero se entregó el mensaje Honor DMARC desactivado, o lista de permitidos/anulación activada Comprobación de la configuración de directivas contra suplantación de identidad (phishing) y la lista de inquilinos permitidos o bloqueados Habilite Respetar la directiva del registro DMARC si desea una aplicación estricta
dmarc=fail para mensajes reenviados El reenvío rompe la alineación de SPF; los cambios en el cuerpo del mensaje rompen DKIM Comprueba si el mensaje ha pasado por un intermediario (encabezados X-MS-Exchange) Configura un sellador ARC de confianza para el servicio de reenvío
dmarc=fail para remitente SaaS que no es de Microsoft El servicio usa su propio dominio en MAIL FROM y DKIM d= Consulta los informes agregados de la dirección IP del servicio Configurar la firma DKIM personalizada en el servicio y alinear MAIL FROM
dmarc=temperror o dmarc=permerror Problemas de DNS al recuperar el registro DMARC (tiempo de espera, error de sintaxis) Validación de la sintaxis del registro DMARC con nslookup -type=TXT _dmarc.domain.com Corregir errores de sintaxis DNS; asegurarse de que solo existe un _dmarc registro TXT
compauth=fail reason=000 Error de autenticación compuesta (error explícito) Comprobar todos los resultados de autenticación (SPF, DKIM, DMARC, ARC) Corrección de problemas subyacentes de SPF/DKIM/DMARC
compauth=fail reason=100 error explícito de DMARC con aplicación de la directiva La directiva DMARC del remitente produjo el error Corrige la alineación en el origen o configura ARC/anulación si es legítimo
Informes agregados que no se reciben rua dirección inaccesible o falta autenticación entre dominios Comprobar que el buzón de correo existe y el registro de autorización de DNS para dominios externos Corregir el enrutamiento del buzón de correo; añadir el registro TXT domain._report._dmarc

Flujo de trabajo de diagnóstico de DMARC

Siga estos pasos para diagnosticar un mensaje con dmarc=fail:

  1. Identifique el dominio From: encuentre el valor header.from= en el encabezado Authentication-Results.

  2. Comprobación de la alineación de SPF: ¿el smtp.mailfrom= dominio coincide con el header.from= dominio?

    • Sí (mismo dominio organizativo con aspf=r): SPF está alineado.
    • No: se produce un error en la alineación SPF.
    • ¿Ha superado el SPF en algún momento (spf=pass frente a spf=fail)? Si spf=fail, corrija primero el SPF añadiendo el remitente al registro SPF.

  3. Comprobar la alineación de DKIM: ¿El valor header.d= de DKIM-Signature coincide con el dominio header.from=?

    • Sí (mismo dominio organizativo con adkim=r): DKIM está alineado.
    • No: se produce un error en la alineación DKIM.
    • ¿Ha superado el DKIM en algún momento (dkim=pass frente a dkim=fail)? Si dkim=fail, corrija DKIM publicando la clave y verificando la firma.

  4. Si se produce un error en ambas alineaciones, se produce un error en DMARC. Opciones de resolución:

    • Corrección de la alineación de SPF: cambie la dirección MAIL FROM a su dominio.
    • Corrección de la alineación de DKIM: inicie sesión con d=contoso.com.
    • Usar un subdominio: enviar desde sub.domain.com con su propio registro DMARC.
    • Si el mensaje se reenvía: configura un sellador ARC de confianza.

  5. Compruebe la acción de la directiva:

    • p=none: No hay ningún efecto en la entrega (solo supervisión).
    • p=quarantine: El mensaje se envía a la carpeta de correo no deseado (si la opción Respetar la directiva DMARC está activada).
    • p=reject: se rechaza el mensaje (si Respetar la directiva DMARC está activada). Si se rechaza el correo legítimo, use ARC, una lista de direcciones permitidas o corrija la autenticación en la fuente.

Comandos útiles de PowerShell para la solución de problemas de DMARC

Conéctese a Exchange Online PowerShell y use los siguientes comandos para comprobar la configuración de DMARC de la directiva contra suplantación de identidad (DMARC), comprobar los registros DNS de DMARC y DKIM, revisar los errores recientes de DMARC e inspeccionar la configuración de ARC:

# Check your organization's anti-phishing policy DMARC settings
Get-AntiPhishPolicy | Format-List Name, HonorDmarcPolicy, DmarcQuarantineAction, DmarcRejectAction

# Verify DMARC record for a domain
Resolve-DnsName -Name "_dmarc.contoso.com" -Type TXT | Select-Object -ExpandProperty Strings

# Check DKIM configuration (alignment prerequisite)
Get-DkimSigningConfig | Format-List Domain, Enabled, Selector1CNAME, Selector2CNAME

# Review messages that failed DMARC in the last 24 hours
Get-MailDetailSpamReport -StartDate (Get-Date).AddDays(-1) -EndDate (Get-Date) |
  Where-Object { $_.MessageTraceId } |
  Select-Object Date, SenderAddress, RecipientAddress, Subject, SpamScore

# Check ARC configuration (for forwarding scenarios)
Get-ArcConfig | Format-List ArcTrustedSealers

# View anti-phishing policy DMARC override actions
Get-AntiPhishPolicy -Identity "Office365 AntiPhish Default" |
  Select-Object HonorDmarcPolicy, DmarcQuarantineAction, DmarcRejectAction

Sugerencia

Al solucionar errores de DMARC para un remitente específico:

  1. Comience con el encabezado Authentication-Results para identificar el tipo de error.
  2. Contrasta con tus informes agregados de DMARC para consultar el volumen y las direcciones IP de origen.
  3. Use Get-MessageTrace para buscar mensajes específicos y Get-MessageTraceDetail para examinar los eventos de entrega.
  4. Si el remitente es legítimo, trabaje con el remitente para corregir la alineación de SPF/DKIM antes de crear excepciones.

Pasos siguientes

Para el correo que llega a Microsoft 365, es posible que también tengas que configurar selladores ARC de confianza si utilizas servicios que modifican los mensajes en tránsito antes de su entrega a tu organización. Para obtener más información, consulta Configurar selladores ARC de confianza.

Para diagnosticar y corregir errores de autenticación por correo electrónico, consulte Solución de problemas de autenticación de correo electrónico en Microsoft 365.

  • Last updated on