Guía de operaciones de seguridad para la autenticación por correo electrónico en Microsoft 365

Email autenticación es un componente fundamental para proteger la comunicación en la organización. Cuando se recibe un correo electrónico en Microsoft 365, el servicio agrega un encabezado Authentication-Results . Este encabezado muestra los resultados de varias comprobaciones de autenticación de correo electrónico, como SPF, DKIM, DMARC y autenticación compuesta (compauth).

En esta guía se explican los escenarios comunes que podría encontrar con estos resultados:

• Por qué se ha pasado un mensaje o se ha producido un error en la autenticación por correo electrónico.
• Si el origen del correo electrónico o el destino del correo electrónico son responsables del resultado.
• Qué acciones (si las hay) se recomiendan para mejorar los resultados de la autenticación por correo electrónico.

Pero en primer lugar, algunas definiciones como se describe en la tabla siguiente:

escenarios de paso de autenticación de Email

En estos escenarios se describen los mensajes que pasaron comprobaciones de autenticación de correo electrónico o que se aceptaron (a veces debido a configuraciones específicas). En general, cuando se supera la autenticación por correo electrónico, no se necesita ninguna acción correctiva. Sin embargo, algunos escenarios incluyen notas de precaución en las que se recomiendan mejoras de configuración para mejorar la seguridad.

El remitente hace referencia a los administradores de la organización de origen. El destinatario hace referencia a los administradores de la organización de destino.

Todas las comprobaciones de autenticación pasadas

• Ejemplo de encabezado: dmarc=pass (y normalmente spf=pass y dkim=pass).
• Lo que significa: todas las comprobaciones de autenticación de correo electrónico (SPF, DKIM y DMARC) se realizaron correctamente. Este resultado indica que el mensaje está totalmente autenticado según los protocolos de autenticación de correo electrónico estándar.
• Quién es responsable: el remitente.
• Acción recomendada: ninguna. la autenticación Email está configurada correctamente y funciona según lo previsto. El destinatario puede confiar en el dominio remitente autenticado correctamente este mensaje.

Autenticación compuesta pasada

• Ejemplo de encabezado: compauth=pass (paso de autenticación compuesta).

• Lo que significa: el mensaje pasó la autenticación compuesta de Microsoft 365:

  • Se cumplieron los requisitos de DMARC: SPF o DKIM pasados y las direcciones MAIL FROM y From están alineadas.

    O bien

  • La lógica de confianza implícita de Microsoft identificó el mensaje como legítimo. Por ejemplo, un mensaje podría pasar la autenticación compuesta en función del historial de remitentes seguros de Microsoft o la inteligencia de suplantación de identidad que indica que el remitente es de confianza.

• Quién es responsable: el remitente.

• Acción recomendada: Ninguna. Las comprobaciones de autenticación se realizaron correctamente y el sistema no detectó ningún problema. No se necesitan cambios en SPF o DKIM en este escenario.

Pase DMARC sin directiva DMARC (sin registro DMARC)

• Ejemplo de encabezado: dmarc=bestguesspass action=none
• Qué significa: el mensaje pasado DMARC de forma predeterminada porque el dominio del remitente no tiene ningún registro DMARC publicado. Cuando un dominio no tiene ninguna directiva DMARC, los servidores de correo electrónico de destino no pueden producir un error en el mensaje en DMARC. Efectivamente, la comprobación de DMARC no se aplica. DMARC=bestguesspass action=none significa que si el dominio tuviera un registro DMARC válido, se pasaría la comprobación de DMARC para el mensaje.
• Quién es responsable: el remitente.
• Acción recomendada: el remitente debe publicar un registro DMARC para su dominio. Aunque se aceptó el mensaje, la ausencia de una directiva DMARC no es una buena señal. Se recomienda que el propietario del dominio configure un registro TXT de DMARC para aplicar una directiva DMARC (p=quarantine o p=reject) para los mensajes que no superan la validación de DMARC. Para obtener más información, vea Sintaxis para registros TXT de DMARC.

Validado por ARC (escenarios de enrutamiento complejos)

• Ejemplo de encabezado: compauth=pass reason=130 (autenticación compuesta pasada debido a ARC).
• Lo que significa: el mensaje pasó la autenticación debido a una invalidación de la cadena recibida autenticada (ARC ). Este resultado suele producirse en escenarios complejos de enrutamiento de correo o reenvío de correo electrónico. Si un servidor de correo intermedio modifica el mensaje y hace que se produzca un error en SPF o DKIM, una firma de ARC de confianza informa a Microsoft 365 de que la autenticación original es válida. En este caso, el sistema aceptó el mensaje en función de la cadena arc válida, aunque podrían producirse errores en las comprobaciones directas de SPF o DKIM.
• Quién es responsable: el remitente (remitente original o intermediario). No hay ninguna configuración incorrecta. Un intermediario que usa ARC procesó el mensaje.
• Acción recomendada: no se requiere ninguna acción directa si se espera este escenario (por ejemplo, un servicio conocido que implementa ARC procesó el mensaje). Si opera un servicio intermedio que no es de Microsoft, agregue encabezados arc y compruebe que los servidores receptores (como Microsoft 365) confían en las firmas de ARC. Esta configuración permite que los mensajes entrantes pasen compauth a través de ARC.

Mensaje entregado para permitir entradas para remitentes suplantados en la lista de permitidos o bloqueados de inquilinos

• Lo que significa: el mensaje omitió las acciones normales de error de autenticación porque las entradas de permitidos para remitentes suplantados existen en la lista de permitidos o bloqueados de inquilinos. En Microsoft 365, una entrada allow para remitentes suplantados puede invalidar los errores. Incluso cuando se produce un error en las comprobaciones de autenticación por correo electrónico, el mensaje se permite debido a esta configuración de confianza explícita.

• Ejemplo de encabezado: compauth=fail reason=000 (pero una directiva de organización permitió el mensaje: Se permite la suplantación de lista de inquilinos o de lista de bloques).

• Quién es responsable: el destinatario. Los administradores de la organización del destinatario configuraron una entrada de permiso para la suplantación en la lista Permitir o bloquear inquilinos para este par de dominio específico. El remitente debe resolver los problemas de autenticación para evitar problemas de entrega con otros destinatarios.

• Acción recomendada: los administradores de destinatarios pueden comprobar la sección Todas las invalidaciones de la página de entidad Email para confirmar si hay una invalidación de lista de permitidos o bloqueados de inquilinos implicada. Estos mensajes contienen directivas permitidas por la organización: se permite la suplantación de lista de inquilinos o de lista de bloques.

  Por lo general, no hay ninguna acción inmediata para estos mensajes, ya que se permiten intencionadamente. Sin embargo, es recomendable que los administradores revisen periódicamente permitir entradas para remitentes suplantados para asegurarse de que solo se permiten los remitentes necesarios. El uso excesivo de la lista de permitidos o bloqueados de inquilinos permite la entrega de mensajes (posiblemente malintencionados) que normalmente producirían errores en las comprobaciones de autenticación.

Autenticado a través de la alineación de PTR (DNS inverso)

• Ejemplo de encabezado: compauth=pass con códigos como reason=116 o reason=111 para indicar el uso de registros PTR.
• Lo que significa: el mensaje pasó la autenticación basada en la validación de PTR (DNS inverso) como reserva. En algunos casos, cuando las comprobaciones de SPF y DKIM no producen un pase concluyente, Microsoft 365 puede examinar el registro PTR del remitente. Si la dirección IP del servidor de envío tiene un registro PTR (DNS inverso) que coincide con el dominio de la dirección From del mensaje, el sistema podría tratar el mensaje como autenticado.
• Quién es responsable: el remitente. El servidor de correo electrónico del remitente se comprobó a través del registro PTR en DNS. Este resultado normalmente significa que SPF y DKIM no se configuraron correctamente y el sistema recurrió a la búsqueda PTR.
• Acción recomendada: el remitente debe asegurarse de que SPF y DKIM están configurados correctamente para su dominio. Un registro DNS inverso (PTR) correcto que asigna el dominio de envío a la dirección IP de envío es bueno, pero no sustituye la alineación de DMARC. Los remitentes deben tratar el pase PTR como un indicador para mejorar su configuración de SPF y DKIM. No hay ninguna acción para el destinatario, aparte de notificar a los remitentes cuando observen este resultado.

escenarios de error de autenticación de Email

En estos escenarios se tratan las comprobaciones de autenticación erróneas u otras condiciones en las que el mensaje está marcado como no autenticado. Si se produce un error en una comprobación de autenticación, no siempre se rechaza el mensaje. Algunos errores provocan que el mensaje se ponga en cuarentena o se entregue con advertencias. En los escenarios siguientes se describe por qué se produjo el error, quién debe solucionarlo y cómo corregir el problema subyacente.

El remitente hace referencia a los administradores de la organización de origen. El destinatario hace referencia a los administradores de la organización de destino.

Error de DMARC (mensaje rechazado o en cuarentena)

• Ejemplo de encabezado: dmarc=fail action=quarantine (o action=reject); a menudo acompañado de compauth=fail un código (por ejemplo, reason=000, reason=001o reason=601).

• Lo que significa: error de validación de DMARC para el mensaje. Este resultado significa:

  • SPF o DKIM no pasaron con alineación para el dominio De dirección.

    And

  • El registro DMARC del dominio De dirección contiene una p=quarantine directiva o p=reject .

  Como resultado, Microsoft 365 marcó el mensaje para la acción de directiva especificada: entregar a la carpeta de Email no deseado, poner en cuarentena o rechazar.

• Quién es responsable: el remitente o el destinatario. El error se debe a que el dominio del remitente no pasa DMARC o la configuración de enrutamiento de correo compleja del destinatario que provocó un error en DMARC.

  Aunque los remitentes son responsables de configurar correctamente SPF, DKIM y DMARC para su dominio, los errores de autenticación a veces pueden deberse a problemas en la organización del destinatario. Por ejemplo:

  • La organización del destinatario usa un servicio de filtrado que no es de Microsoft entre Internet Microsoft 365 sin configurar el filtrado mejorado para conectores. La validación SPF puede producir un error cuando Microsoft 365 recibe el mensaje.
  • Si el servicio de filtrado que no es de Microsoft modifica el mensaje antes de la entrega, DKIM podría producir un error, aunque el registro DKIM del remitente esté configurado correctamente.

  Por lo tanto, es importante distinguir entre el veredicto en el punto de recepción inicial (registro MX) y el veredicto cuando el mensaje llega al buzón del destinatario.

• Acción recomendada:

  • El remitente debe corregir su configuración de autenticación de correo electrónico. En concreto, el remitente debe realizar los pasos siguientes:

    • Asegúrese de que su registro SPF incluye todas las direcciones IP de origen legítimas para el correo electrónico del dominio.
    • Configure DKIM para el dominio y compruebe que las firmas se aplican correctamente al correo saliente.
    • Compruebe que SPF o DKIM (o ambos) pasen y también estén alineados con el dominio De dirección según lo requiera DMARC.
    • Compruebe la sintaxis del registro DMARC y la directiva DMARC. Por ejemplo, p=quarantine o p=reject.

  • El destinatario debe corregir su configuración compleja de enrutamiento de correo. En concreto, el destinatario debe realizar los pasos siguientes:

    • Configuración del filtrado mejorado para conectores
    • Si está disponible, configure selladores arc de confianza para invalidar los errores causados por la modificación del mensaje en tránsito.
    • Considere la posibilidad de usar Microsoft 365 para aplicar modificaciones de mensajes (pies de página, declinaciones de responsabilidades, asunto, etc.) en lugar de servicios que no sean de Microsoft.

Error en la comprobación de SPF

• Ejemplo de encabezado: spf=fail o spf=softfail. Observe si spf=temperror indica problemas de DNS transitorios o spf=permerror indica problemas de configuración de SPF.

• Lo que significa: Una de las siguientes posibilidades:

  • La dirección IP del servidor de envío no está autorizada por el registro SPF del dominio, por lo que se produce un error en la devolución de SPF.
  • La comprobación de SPF no se pudo completar correctamente. Por ejemplo, un problema de búsqueda dns (spf=temperror) o demasiadas redirecciones (spf=permerror).

  Un error de SPF sin un pase DMARC también produce un error de DMARC.

• Quién es responsable: el remitente. El problema radica en la configuración del registro SPF del dominio remitente o en la configuración del servidor de envío.

• Acción recomendada: el remitente debe actualizar y corregir el registro SPF del dominio:

  • Compruebe que todas las direcciones IP de origen legítimas del dominio se incluyen en el registro SPF.
  • Si DMARC produce un error debido a un desalineamiento del dominio (el dominio de dirección MAIL FROM difiere del dominio de dirección De), puede corregirlo realizando uno o ambos de los pasos siguientes:
    • Alinee los dominios usados en las direcciones MAIL FROM y From.
    • Configure la firma DKIM de mensajes salientes mediante un dominio que coincida con el dominio De dirección. DMARC requiere validación SPF o DKIM, no ambas.
  • spf=temperror generalmente indica que el destinatario tenía un problema al resolver el registro SPF (por ejemplo, problemas de DNS transitorios). El remitente debe comprobar que los servidores DNS de su dominio son correctos y accesibles. Si el valor de tiempo de vida (TTL) es demasiado bajo y provoca tiempos de espera frecuentes, considere la posibilidad de aumentar el TTL a al menos una hora.
  • spf=permerror normalmente indica un problema con el propio registro SPF, incluida la necesidad de más de 10 búsquedas DNS. Simplifique el registro SPF quitando instrucciones innecesarias include: y corrigiendo los errores de sintaxis.

La resolución de problemas de SPF significa que es más probable que los mensajes pasen la autenticación DMARC. Los destinatarios deben notificar a los remitentes sobre los errores de SPF y las acciones recomendadas para corregir los problemas.

Error en la comprobación DKIM (sin clave para la firma)

• Ejemplo de encabezado: dkim=fail (no hay ninguna clave para la firma) si falta la clave pública.

• Lo que significa: Una de las siguientes posibilidades:

  • Había una firma DKIM, pero el destinatario no pudo encontrar una clave pública coincidente en DNS (sin clave).

    O bien

  • La clave no coincidía con la firma (no se pudo comprobar la firma).

• Quién es responsable: el remitente. El dominio del remitente tiene una configuración DKIM interrumpida:

  • Una clave pública no está presente en el registro CNAME o TXT de DKIM en DNS.

    O bien

  • Hay un problema de DNS en el lado del remitente o del receptor.

• Acción recomendada: el remitente debe corregir la configuración de DKIM para su dominio mediante los pasos siguientes:

  • Publique la clave pública DKIM en DNS. Compruebe que el registro DKIM CNAME o TXT contiene un selector válido (por ejemplo, selector._domainkey.contoso.com) que coincide con la clave privada usada para firmar los mensajes.
  • Si se publica la clave, es probable que se haya agotado el tiempo de espera cuando Microsoft 365 intentó consultar el registro. Compruebe que el valor de tiempo de vida (TTL) esté establecido en al menos una hora.

Una vez que DKIM está configurado y alineado correctamente, los destinatarios ven dkim=pass los mensajes, lo que también ayuda a los mensajes a pasar DMARC.

Error de DKIM después de la modificación (la firma no se ha comprobado)

• Ejemplo de encabezado: dkim=fail (La firma no se ha comprobado).
• Lo que significa: El mensaje contenía una firma DKIM válida, pero el mensaje no pudo comprobar DKIM porque un encabezado incluido en la firma DKIM se modificó en tránsito después de firmarse. Esta modificación suele producirse cuando un intermediario (por ejemplo, una lista de correo, un servicio de reenvío o un dispositivo de seguridad) modifica un encabezado firmado (por ejemplo, Subject:, From:o To:) después de aplicar originalmente la firma DKIM. El h= valor de DKIM-Signature identifica los encabezados incluidos en el hash original. La modificación de cualquiera de estos encabezados produce un error DKIM.
• Quién es responsable: el remitente o el intermediario que modificó los encabezados del mensaje. El remitente original firmó correctamente el mensaje, pero un intermediario podría ser responsable de la firma DKIM rota.
• Acción recomendada: no realice cambios en los encabezados después de firmar dkim un mensaje:
  • Remitentes: compruebe que los encabezados firmados permanecen sin cambios desde el momento en que el mensaje está firmado con DKIM hasta que sale del entorno.
  • Intermediarios: permite a los clientes configurar el servicio como sellador de ARC de confianza para invalidar los errores DKIM causados por la modificación del mensaje en tránsito.

Error de DKIM después de la modificación (error en el hash del cuerpo)

• Ejemplo de encabezado: dkim=fail (error de hash del cuerpo).
• Lo que significa: El mensaje contenía una firma DKIM válida, pero el mensaje no pudo comprobar DKIM porque el cuerpo del mensaje se modificó en tránsito después de firmarse. Esta modificación suele producirse cuando un intermediario (por ejemplo, una lista de correo, un servicio de reenvío o un dispositivo de seguridad) modifica el contenido del cuerpo del mensaje después de aplicar originalmente la firma DKIM. El resultado es que el hash calculado por el sistema de correo electrónico receptor no coincide con el hash de la firma DKIM, por lo que se produce un error en la comprobación de DKIM.
• Quién es responsable: el remitente o el intermediario que modificó el mensaje. El remitente original firmó correctamente el mensaje, pero un intermediario podría ser responsable de la firma DKIM rota.
• Acción recomendada: asegúrese de que no se realicen cambios imprevistos en el contenido del correo electrónico después de la firma:
  • Remitentes: siga estos pasos:
    • Compruebe que los encabezados firmados permanecen sin cambios desde el momento en que el mensaje está firmado con DKIM hasta que sale del entorno.
    • Considere la posibilidad de usar Microsoft 365 para aplicar modificaciones de mensajes (pies de página, declinaciones de responsabilidades, asunto, etc.) en lugar de servicios que no sean de Microsoft.
  • Intermediarios: permite a los clientes configurar el servicio como sellador de ARC de confianza para invalidar los errores DKIM causados por la modificación del mensaje en tránsito.

Tabla de referencia rápida

Esta sección contiene una tabla simplificada que resume los escenarios, las soluciones recomendadas y vínculos a artículos pertinentes para su posterior lectura.

El remitente hace referencia a los administradores del dominio de envío. El destinatario hace referencia a los administradores de la organización receptora.

Procedimientos recomendados y sugerencias

• Implementación de SPF, DKIM y DMARC: estas tecnologías se complementan entre sí y proporcionan defensa en profundidad. Cualquier cosa menos deja brechas en la protección.

• Mantener registros DNS: mantenga los registros SPF actualizados con todos los orígenes de correo electrónico. Rote y administre las claves DKIM según sea necesario y supervise los informes de DMARC para identificar errores de autenticación.

• Supervisar los resultados de autenticación: compruebe periódicamente los encabezados Authentication-Results o use herramientas o informes (por ejemplo, la información de inteligencia de suplantación de identidad de Microsoft 365) para ver cómo están funcionando los mensajes entrantes. Esta actividad puede revelar los asociados que no configuraron SPF/DKIM o si su propio mensaje está fallando en la autenticación.

• Usar ARC para escenarios de retransmisión: si su organización realiza el reenvío de correo o usa servicios que no son de Microsoft que modifican mensajes, considere la posibilidad de configurar selladores arc de confianza en Microsoft 365. ARC puede ayudar a conservar la autenticación y evitar errores falsos cuando los mensajes transitan a través de intermediarios.

• Tenga cuidado con las listas de permitidos: confíe en los resultados de autenticación estándar siempre que sea posible en lugar de permitir entradas de la organización. Las entradas permitidas deben ser excepciones y deben comprobarse periódicamente para quitar entradas innecesarias.

• Mantenerse informado: siga estos recursos:

  • Blog de Microsoft Defender para Office 365
  • Blog del equipo de Exchange
  • Novedades de Microsoft Defender para Office 365
  • Centro de mensajes de Microsoft 365.