Configuración de DMARC para validar el dominio De dirección para remitentes en Microsoft 365

• Se aplica a:

  ✅ Exchange Online Protection, ✅ Microsoft Defender for Office 365 Plan 1 and Plan 2, ✅ Microsoft Defender XDR

Sugerencia

¿Sabía que puede probar las características de Microsoft Defender para Office 365 Plan 2 de forma gratuita? Use la prueba de Defender para Office 365 de 90 días en el centro de pruebas del portal de Microsoft Defender. Obtenga información sobre quién puede registrarse y los términos de prueba 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 que ayuda a validar el correo enviado desde su organización de Microsoft 365 para evitar remitentes suplantados que se usan en el riesgo de correo electrónico empresarial (BEC), ransomware y otros ataques de suplantación de identidad (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 que se usa en la transmisión del mensaje entre los servidores de correo electrónico SMTP. Esta dirección también se conoce como dirección 5321.MailFrom , remitente P1 o remitente de 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 remitente de dirección 5322.From o 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 que se usa 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 de forma eficaz que los orígenes válidos para el mensaje estén en el dominio De dirección.

  • 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 de SPF o 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 agregados (un resumen periódico de resultados positivos y negativos de DMARC) e 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 Email (MOERA) de Microsoft Online para 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 esta sección más adelante en este artículo. 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 debe configurar la firma DKIM mediante el dominio o subdominio personalizados para que el dominio que se usa para firmar el mensaje se alinee con el dominio en la dirección Desde. Para obtener instrucciones, consulte los artículos siguientes:

  • Configurar SPF para ayudar a evitar la suplantación de identidad
  • Uso de DKIM para validar el correo saliente desde el dominio personalizado

  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), se recomienda usar 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 empleados 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 provenir 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, puede identificar el servicio como un sellador de ARC de confianza para que los mensajes modificados no generen errores automáticamente en las comprobaciones de DMARC. Para obtener más información, consulte la sección Pasos siguientes al final de este artículo.

En el resto de este artículo se describe el registro TXT de DMARC que debe crear para los dominios de Microsoft 365, la mejor manera de configurar de forma gradual y segura DMARC para dominios personalizados en Microsoft 365 y cómo Microsoft 365 usa DMARC en el correo entrante .

Sugerencia

Para crear el registro TXT de DMARC para el dominio *.onmicrosoft.com en el Centro de administración de Microsoft 365, consulte esta sección más adelante en este artículo.

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).

Proporcionamos 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>

O bien,

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 un error en DMARC, como se describió anteriormente en este artículo:

  • 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 se deben aceptar pero marcar. 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. Este valor se usa para probar y ajustar la directiva DMARC , como se describe más adelante en este artículo.

  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 invalidación para este comportamiento.

• Porcentaje de correo DMARC con errores sujeto a la directiva DMARC: indica al sistema de correo electrónico de destino cuántos mensajes que no son dmarc (porcentaje) reciben la directiva DMARC aplicada a ellos. 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 ajustar la directiva DMARC , como se describe más adelante en este artículo. 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 realiza en el correo que produce un error en la autenticación dmarc (basada en la directiva 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 Microsoft Intelligent Security Association (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:

• La serie de entrenamiento DMARC de M³AAWG (mensajería, malware, grupo de trabajo contra el abuso móvil).
• Información en DMARC.org.

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

1. En el Centro de administración de Microsoft 365 en https://admin.microsoft.com, seleccione Mostrar todos los>dominiosde configuración>. 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 control flotante Agregar un registro DNS personalizado que se abre, configure los siguientes valores:

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

   • Nombre TXT: escriba _dmarc.

   • Valor TXT: escriba 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 haya terminado en el control flotante Agregar un registro DNS personalizado , seleccione Guardar.

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

Sugerencia

Como se mencionó anteriormente en este artículo, 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 antes de configurar DMARC para dominios personalizados o subdominios.

Se recomienda un enfoque gradual para configurar DMARC para los dominios de Microsoft 365. El objetivo es llegar a una p=reject directiva DMARC para todos los dominios y subdominios personalizados, pero debe probar y comprobar a lo largo del camino para evitar que los sistemas de correo electrónico de destino rechacen el correo correcto debido a errores de DMARC no intencionados.

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 forenses dmarc y agregados de DMARC proporcionan los números y orígenes de mensajes que pasan y conmutan por error 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 desplazarse en los incrementos siguientes:

   • 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 el correo electrónico legítimo en cualquier volumen significativo es inaceptable para los usuarios, pero es casi inevitable que vaya a obtener 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. Como se describió anteriormente, los subdominios heredan la configuración del registro TXT de DMARC del dominio primario, que puede invalidarse 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 personalizados en Microsoft 365. Como se describe en Configuración de DKIM para firmar correo desde el dominio de Microsoft 365, no se recomiendan registros DKIM CNAME para dominios estacionados.

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

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

   • El pct= valor no se incluye, porque el valor predeterminado es pct=100.
   • Es rua=mailto: posible que los valores y ruf=mailto: no sean necesarios en este escenario, ya que ningún correo válido debe provenir 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 comprobaciones de DMARC en el correo que llegan a Microsoft 365 se ven afectadas por las siguientes características de Exchange Online Protection (EOP):

  • Si la inteligencia de suplantación de identidad está habilitada o deshabilitada en la directiva contra suplantación de identidad (phishing) que ha comprobado el mensaje. Deshabilitar la inteligencia de suplantación de identidad deshabilita la protección de suplantación implícita solo contra comprobaciones de autenticación compuesta .
  • Si la directiva de registro de Honor DMARC cuando se detecta el mensaje como configuración de suplantación de identidad está habilitada o deshabilitada en la directiva contra suplantación de identidad (phishing) que ha comprobado el mensaje y las acciones especificadas basadas en la directiva DMARC del dominio de origen (p=quarantineo 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 de anti-phishing de EOP.

• 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 el correo de Internet se enruta a través de un servicio o dispositivo de terceros antes de su entrega a Microsoft 365 (los puntos de registro MX en algún lugar distinto de Microsoft 365), no se envían los informes agregados de DMARC. Esta limitación incluye escenarios de EOP híbridos o independientes en los que el correo se entrega al entorno local antes de enrutarse a Microsoft 365 mediante un conector.

  Sugerencia

  Cuando un dispositivo o servicio de terceros se encuentra delante del correo que fluye a Microsoft 365, el filtrado mejorado para conectores (también conocido como omisión de lista) 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

Puede usar el siguiente gráfico para ayudar a solucionar problemas de autenticación de DMARC.

Pasos siguientes

Para el correo que entra en Microsoft 365, es posible que también tenga que configurar selladores de ARC de confianza si usa servicios que modifican los mensajes en tránsito antes de la entrega a su organización. Para obtener más información, consulte Configuración de selladores arc de confianza.