Compartir a través de

Autenticación de correo electrónico en Microsoft 365

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.

Como una organización de Microsoft 365 con buzones de correo en Exchange Online o una organización independiente de Exchange Online Protection (EOP) sin Exchange Online buzones, es importante proteger la integridad de los mensajes de correo electrónico de los remitentes de los dominios. Los destinatarios deben sentirse seguros de que los mensajes de los remitentes de su dominio provienen realmente de remitentes del dominio.

Email autenticación (también conocida como validación de correo electrónico) es un grupo de estándares para identificar e impedir la entrega de mensajes de correo electrónico de remitentes falsificados (también conocidos como suplantación de identidad). Los remitentes suplantados se usan habitualmente en los ataques de correo electrónico empresarial (BEC), suplantación de identidad (phishing) y otros ataques de correo electrónico. Estos estándares incluyen:

  • Marco de directivas de remitente (SPF): especifica los servidores de correo electrónico de origen autorizados para enviar correo para el dominio.
  • Correo identificado por DomainKeys (DKIM): usa un dominio para firmar digitalmente elementos importantes del mensaje para asegurarse de que el mensaje no se ha modificado en tránsito.
  • Autenticación de mensajes basada en dominio, informes y conformidad (DMARC): especifica la acción para los mensajes que producen un error en las comprobaciones SPF o DKIM de los remitentes del dominio y especifica dónde enviar los resultados de DMARC (informes).
  • Cadena recibida autenticada (ARC): conserva la información de autenticación de correo electrónico original de los servicios conocidos que modifican los mensajes en tránsito. El servidor de correo electrónico de destino puede usar esta información para autenticar mensajes que, de lo contrario, producirían un error en DMARC.

Es importante tener en cuenta que estos estándares son bloques de creación interdependientes que funcionan juntos para proporcionar la mejor protección de correo electrónico posible contra ataques de suplantación de identidad y suplantación de identidad (phishing). Cualquier cosa menor que todos los métodos de autenticación de correo electrónico da como resultado una protección poco estándar.

Para configurar la autenticación por correo electrónico para el correo enviado desde organizaciones de Microsoft 365 con buzones en Exchange Online o organizaciones independientes de Exchange Online Protection (EOP) sin buzones de correo Exchange Online, consulte los artículos siguientes:

Para evitar errores de autenticación por correo electrónico debidos a servicios que modifican el correo entrante enviado a su organización de Microsoft 365, consulte Configuración de selladores de ARC de confianza.

En el resto de este artículo se explica lo siguiente:

Sugerencia

Como complemento a este artículo, consulte nuestra guía de configuración de Microsoft Defender para Office 365 para revisar los procedimientos recomendados y protegerse frente a amenazas de correo electrónico, vínculos y colaboración. Las características incluyen vínculos seguros, datos adjuntos seguros y mucho más. Para obtener una experiencia personalizada basada en su entorno, puede acceder a la guía de configuración automatizada de Microsoft Defender para Office 365 en el Centro de administración de Microsoft 365.

Por qué el correo electrónico de Internet necesita autenticación

Por diseño, el correo electrónico del Protocolo simple de transferencia de correo (SMTP) en Internet no hace ningún esfuerzo para validar que el remitente del mensaje es quien dice ser.

Un mensaje de correo electrónico SMTP estándar consta de un sobre de mensaje y contenido de mensaje:

  • El sobre del mensaje contiene información para transmitir y recibir el mensaje entre servidores SMTP. El sobre del mensaje se describe en RFC 5321. Los destinatarios nunca ven el sobre del mensaje porque se genera durante el proceso de transmisión de mensajes.
  • El contenido del mensaje contiene el cuerpo del mensaje y campos de encabezado de mensaje, que se denominan de forma colectiva encabezado del mensaje. El encabezado del mensaje se describe en RFC 5322.

Debido a este diseño, un mensaje tiene varios valores de remitente:

  • La dirección MAIL FROM (también conocida como dirección 5321.MailFrom , remitente P1 o remitente de sobre) es la dirección de correo electrónico que se usa en la transmisión del mensaje entre servidores de correo electrónico SMTP. Esta dirección se registra normalmente en el campo encabezado Return-Path del encabezado del mensaje (aunque el servidor de correo electrónico de origen puede designar una dirección de correo electrónico return-path diferente). Esta dirección de correo electrónico se usa en informes de no entrega (también conocidos como NDR o mensajes de devolución).
  • La dirección De (también conocida como dirección 5322.From o remitente P2) es la dirección de correo electrónico en el campo De encabezado y es la dirección de correo electrónico del remitente que se muestra en los clientes de correo electrónico.

En el ejemplo siguiente se muestra la transcripción simplificada de una transmisión de mensajes válida entre dos servidores de correo electrónico SMTP:

S: HELO woodgrovebank.com
S: MAIL FROM: dubious@proseware.com
S: RCPT TO: astobes@tailspintoys.com
S: DATA
S: To: "Andrew Stobes" <astobes@tailspintoys.com>
S: From: "Woodgrove Bank Security" <security@woodgrovebank.com>
S: Subject: Woodgrove Bank - Action required
S:
S: Greetings,
S:
S: We need to verify your banking details.
S: Please click the following link to verify that we have the right information for your account.
S:
S: https://short.url/woodgrovebank/updateaccount/12-121.aspx
S:
S: Thank you,
S: Woodgrove Bank
S: .

En este ejemplo:

  • El servidor de correo electrónico de origen se identifica como woodgrovebank.com al servidor de correo electrónico de destino tailspintoys.com en el comando HELO.
  • El destinatario del mensaje es astobes@tailspintoys.com.
  • La dirección MAIL FROM del sobre del mensaje (que se usa para transmitir el mensaje entre los servidores de correo electrónico SMTP) es dubious@proseware.com.
  • La dirección From que se muestra en el cliente de correo electrónico del destinatario es security@woodgrovebank.com.

Aunque este mensaje es válido según SMTP, el dominio de la dirección MAIL FROM (proseware.com) no coincide con el dominio de la dirección De (woodgrovebank.com). Este mensaje es un ejemplo clásico de suplantación de identidad, donde es probable que la intención encuente al destinatario enmascarando el verdadero origen del mensaje que se usará en un ataque de suplantación de identidad (phishing).

Claramente, el correo electrónico SMTP necesita ayuda para comprobar que los remitentes de mensajes son quienes afirman ser.

Cómo funcionan conjuntamente SPF, DKIM y DMARC para autenticar remitentes de mensajes de correo electrónico

En esta sección se describe por qué necesita SPF, DKIM y DMARC para dominios en Internet.

  • SPF: como se explica en Configurar SPF para identificar orígenes de correo electrónico válidos para su dominio de Microsoft 365, SPF usa un registro TXT en DNS para identificar orígenes de correo válidos del dominio MAIL FROM y qué hacer si el servidor de correo electrónico de destino recibe correo de un origen no definido ("error difícil" para rechazar el mensaje; "error temporal" para aceptar y marcar el mensaje).

    Problemas de SPF:

    • SPF valida los orígenes de los remitentes solo en el dominio MAIL FROM. SPF no tiene en cuenta el dominio en la dirección De o la alineación entre los dominios MAIL FROM y From:

      • Un atacante puede enviar correo electrónico que pasa la autenticación SPF (un falso negativo) siguiendo estos pasos:
        • Registre un dominio (por ejemplo, proseware.com) y configure SPF para el dominio.
        • Envíe un correo electrónico desde un origen válido para el dominio registrado, con las direcciones de correo electrónico desde en un dominio diferente (por ejemplo, woodgrovebank.com).
      • Un servicio de correo electrónico legítimo que envía correo en nombre de otros dominios podría controlar la dirección MAIL FROM. Los demás dominios y el dominio MAIL FROM no coinciden, por lo que los mensajes no pueden pasar la autenticación SPF (un falso positivo).

    • SPF se interrumpe después de que los mensajes encuentren el reenvío de correo electrónico basado en servidor que redirige o retransmite mensajes .

      • El reenvío de correo electrónico basado en servidor cambia el origen del mensaje del servidor original al servidor de reenvío.
      • El servidor de reenvío no está autorizado para enviar correo desde el dominio MAIL FROM original, por lo que el mensaje no puede pasar la autenticación SPF (un falso positivo).

    • Cada dominio y cualquier subdominio requieren sus propios registros SPF individuales. Los subdominios no heredan el registro SPF del dominio primario. Este comportamiento se vuelve problemático si desea permitir que el correo electrónico de subdominios definidos y usados, pero evitar que el correo electrónico no esté definido y no se use subdominios.

  • DKIM: como se explica en Configuración de DKIM para firmar correo desde el dominio de Microsoft 365, DKIM usa un dominio para firmar digitalmente elementos importantes del mensaje (incluida la dirección From) y almacena la firma en el encabezado del mensaje. El servidor de destino comprueba que no se modificaron los elementos firmados del mensaje.

    Cómo DKIM ayuda a SPF: DKIM puede validar los mensajes que producen un error en SPF. Por ejemplo:

    • Mensajes de un servicio de hospedaje de correo electrónico donde se usa la misma dirección MAIL FROM para el correo de otros dominios.
    • Mensajes que encuentran el reenvío de correo electrónico basado en servidor.

    Dado que la firma DKIM del encabezado del mensaje no se ve afectada ni modificada en estos escenarios, estos mensajes pueden pasar DKIM.

    Problemas de DKIM: el dominio que DKIM usa para firmar un mensaje no necesita coincidir con el dominio de la dirección Desde que se muestra en los clientes de correo electrónico.

    Al igual que SPF, un atacante puede enviar correo electrónico que pasa la autenticación DKIM (un falso negativo) siguiendo estos pasos:

    • Registre un dominio (por ejemplo, proseware.com) y configure DKIM para el dominio.
    • Enviar correo electrónico con las direcciones de correo electrónico desde en un dominio diferente (por ejemplo, woodgrovebank.com).

  • DMARC: como se explica en Configuración de DMARC para validar el dominio De dirección para remitentes en Microsoft 365, DMARC usa SPF y DKIM para comprobar la alineación entre los dominios en las direcciones MAIL FROM y From. DMARC también especifica la acción que el sistema de correo electrónico de destino debe realizar en los mensajes que producen un error en DMARC e identifica dónde enviar los resultados de DMARC (se pasan y se producen errores).

    Cómo DMARC ayuda a SPF y DKIM: como se describió anteriormente, SPF no intenta hacer coincidir el dominio en el dominio MAIL FROM y las direcciones From. A DKIM no le importa si el dominio que firmó el mensaje coincide con el dominio de la dirección Desde.

    DMARC soluciona estas deficiencias mediante SPF y DKIM para confirmar que los dominios de las direcciones MAIL FROM y From coinciden.

    Problemas de DMARC: servicios legítimos que modifican los mensajes en tránsito antes de que la entrega interrumpa SPF, DKIM y, por tanto, las comprobaciones de DMARC.

  • ARC: como se explica en Configurar selladores de ARC de confianza, los servicios legítimos que modifican los mensajes en tránsito pueden usar ARC para conservar la información de autenticación de correo electrónico original de los mensajes modificados.

    Cómo ARC ayuda a DMARC: el sistema de correo electrónico de destino puede identificar el servicio como un sellador de ARC de confianza. ARC puede usar la información de autenticación de correo electrónico conservada para validar el mensaje.

Autenticación de correo electrónico entrante para el correo enviado a Microsoft 365

Debido a problemas de suplantación de identidad (phishing) y a la adopción menos que completa de directivas de autenticación de correo electrónico seguras por parte de remitentes de correo electrónico en Internet, Microsoft 365 usa la autenticación implícita de correo electrónico para comprobar el correo electrónico entrante. La autenticación de correo electrónico implícita amplía las comprobaciones regulares de SPF, DKIM y DMARC mediante señales de otros orígenes para evaluar el correo electrónico entrante. Estos orígenes incluyen:

  • Reputación del remitente.
  • Historial del remitente.
  • Historial de destinatarios.
  • Análisis de comportamiento.
  • Otras técnicas avanzadas.

Para ver el anuncio original de Microsoft sobre la autenticación implícita, consulte A Sea of Phish Part 2 - Enhanced Anti-spoofing in Microsoft 365 (A Sea of Phish Part 2 - Enhanced Anti-spoofing in Microsoft 365).

Al usar estas otras señales, los mensajes que, de lo contrario, producirían un error en las comprobaciones de autenticación de correo electrónico tradicionales, pueden pasar la autenticación implícita y permitirse en Microsoft 365.

Autenticación compuesta

Los resultados de las comprobaciones implícitas de autenticación de Microsoft 365 se combinan y almacenan en un único valor denominado autenticación compuesta o compauth en resumen. El valor de compauth se marca en el encabezado Authentication-Results en los encabezados de mensaje. El encabezado Authentication-Results usa la sintaxis siguiente:

Authentication-Results:
   compauth=<fail | pass | softpass | none> reason=<yyy>

Estos valores se explican en Encabezado de mensaje Authentication-results.

Los administradores y los usuarios pueden examinar los encabezados de mensaje para descubrir cómo Microsoft 365 identificó al remitente como un remitente suplantado sospechoso o legítimo.

Sugerencia

Es importante comprender que un error de autenticación compuesta no da lugar directamente a que se bloquee un mensaje. Nuestro sistema usa una estrategia de evaluación holística que considera la naturaleza sospechosa general de un mensaje junto con los resultados de autenticación compuesta. Este método está diseñado para mitigar el riesgo de bloquear incorrectamente el correo electrónico legítimo de dominios que podrían no cumplir estrictamente los protocolos de autenticación de correo electrónico. Este enfoque equilibrado ayuda a distinguir el correo electrónico genuinamente malintencionado de los remitentes de mensajes que simplemente no cumplen con los procedimientos de autenticación de correo electrónico estándar.

Los ejemplos siguientes se centran solo en los resultados de la autenticación por correo electrónico (el valor y el compauth motivo). Otras tecnologías de protección de Microsoft 365 pueden identificar los mensajes que pasan la autenticación de correo electrónico como suplantados o identificar los mensajes que no superan la autenticación de correo electrónico como legítimos.

  • Escenario: el dominio del registro SPF o la firma DKIM no coincide con el dominio de la dirección Desde.

  • Resultado: el mensaje puede producir un error en la autenticación compuesta. A pesar del error de autenticación compuesta, es posible que el mensaje todavía se permita si otras evaluaciones no indican una naturaleza sospechosa:

    Authentication-Results: spf=none (sender IP is 192.168.1.8)
  smtp.mailfrom=maliciousdomain.com; contoso.com; dkim=pass
  (signature was verified) header.d=maliciousdomain.com;
  contoso.com; dmarc=none action=none header.from=contoso.com;
  compauth=fail reason=001
From: chris@contoso.com
To: michelle@fabrikam.com

  • Escenario: el dominio fabrikam.com no tiene registros SPF, DKIM o DMARC.

  • Resultado: los mensajes de los remitentes del dominio fabrikam.com pueden producir errores de autenticación compuesta:

    Authentication-Results: spf=none (sender IP is 10.2.3.4)
  smtp.mailfrom=fabrikam.com; contoso.com; dkim=none
  (message not signed) header.d=none; contoso.com; dmarc=none
  action=none header.from=fabrikam.com; compauth=fail reason=001
From: chris@fabrikam.com
To: michelle@contoso.com

  • Escenario: el dominio fabrikam.com tiene un registro SPF y ningún registro DKIM. Los dominios de las direcciones MAIL FROM y From coinciden.

  • Resultado: El mensaje puede pasar la autenticación compuesta, ya que el dominio que ha pasado SPF coincide con el dominio en la dirección From:

    Authentication-Results: spf=pass (sender IP is 10.2.3.4)
  smtp.mailfrom=fabrikam.com; contoso.com; dkim=none
  (message not signed) header.d=none; contoso.com; dmarc=bestguesspass
  action=none header.from=fabrikam.com; compauth=pass reason=109
From: chris@fabrikam.com
To: michelle@contoso.com

  • Escenario: el dominio fabrikam.com tiene un registro DKIM sin un registro SPF. El dominio en el que DKIM firmó el mensaje coincide con el dominio de la dirección Desde.

  • Resultado: El mensaje puede pasar la autenticación compuesta, ya que el dominio de la firma DKIM coincide con el dominio de la dirección From:

    Authentication-Results: spf=none (sender IP is 10.2.3.4)
  smtp.mailfrom=fabrikam.com; contoso.com; dkim=pass
  (signature was verified) header.d=outbound.fabrikam.com;
  contoso.com; dmarc=bestguesspass action=none
  header.from=fabrikam.com; compauth=pass reason=109
From: chris@fabrikam.com
To: michelle@contoso.com

  • Escenario: el dominio del registro SPF o la firma DKIM no coincide con el dominio de la dirección Desde.

  • Resultado: El mensaje puede producir un error en la autenticación compuesta:

    Authentication-Results: spf=none (sender IP is 192.168.1.8)
  smtp.mailfrom=maliciousdomain.com; contoso.com; dkim=pass
  (signature was verified) header.d=maliciousdomain.com;
  contoso.com; dmarc=none action=none header.from=contoso.com;
  compauth=fail reason=001
From: chris@contoso.com
To: michelle@fabrikam.com

Cómo evitar errores de autenticación por correo electrónico al enviar correo a Microsoft 365

Sugerencia

Los clientes de Microsoft 365 pueden usar los métodos siguientes para permitir mensajes de remitentes identificados como errores de suplantación de identidad o autenticación:

  • Configurar registros SPF, DKIM y DMARC para los dominios: use la información de configuración proporcionada por el registrador de dominios o el servicio de hospedaje DNS. También hay empresas de terceros dedicadas a ayudar a configurar registros de autenticación por correo electrónico.

    Muchas empresas no publican registros SPF porque no conocen todos los orígenes de correo electrónico de los mensajes de su dominio.

    1. Empiece publicando un registro SPF que contenga todos los orígenes de correo electrónico que conozca (especialmente dónde se encuentra el tráfico corporativo) y use el valor de regla de cumplimiento "error temporal" (~all). Por ejemplo:

      fabrikam.com IN TXT "v=spf1 include:spf.fabrikam.com ~all"

      Si crea este registro SPF, Microsoft 365 trata el correo electrónico entrante de la infraestructura corporativa como autenticado, pero es posible que el correo electrónico de orígenes no identificados siga marcado como suplantación si se produce un error en la autenticación compuesta. Sin embargo, este comportamiento sigue siendo una mejora de todos los mensajes de correo electrónico de los remitentes del dominio marcados como suplantados por Microsoft 365. Normalmente, el sistema de correo electrónico de destino acepta mensajes de remitentes del dominio de orígenes no identificados cuando SPF está configurado con una regla de cumplimiento de errores temporales.

    2. Descubra e incluya más orígenes de correo electrónico para los mensajes. Por ejemplo:

      • Servidores de correo electrónico locales.
      • Correo electrónico enviado desde un proveedor de software como servicio (SaaS).
      • Correo electrónico enviado desde un servicio de hospedaje en la nube (Microsoft Azure, GoDaddy, Rackspace, Amazon Web Services, etc.).

      Después de identificar todos los orígenes de correo electrónico de su dominio, puede actualizar el registro SPF para usar el valor de regla de cumplimiento "error duro" (-all).

    3. Configure DKIM para firmar digitalmente los mensajes.

    4. Configure DMARC para validar que los dominios de las direcciones MAIL FROM y From coinciden, para especificar qué hacer con los mensajes que no cumplen las comprobaciones de DMARC (rechazar o poner en cuarentena) e identificar los servicios de informes para supervisar los resultados de DMARC.

    5. Si usa remitentes masivos para enviar correo electrónico en su nombre, compruebe que el dominio de la dirección De coincide con el dominio que pasa SPF o DMARC.

  • Hospede el correo electrónico de un dominio o proporcione una infraestructura de hospedaje que pueda enviar correo electrónico:

    • Asegúrese de que los clientes tienen documentación que explica cómo configurar SPF para sus dominios.
    • Considere la posibilidad de firmar dkim correo saliente DKIM, incluso si el cliente no configura explícitamente DKIM en su dominio (inicie sesión con un dominio predeterminado). Incluso puede firmar el correo electrónico con firmas DKIM (con el dominio de la empresa y el dominio del cliente si está disponible).

    La entrega a Microsoft no está garantizada, aunque autentique el correo electrónico que se origina en la plataforma. Sin embargo, la autenticación por correo electrónico garantiza que Microsoft no envíe automáticamente correo no deseado de los dominios de cliente simplemente porque no se autentica.