Compartir a través de

Funcionamiento de la autenticación basada en DNS SMTP de entidades con nombre (DANE)

El protocolo SMTP es el protocolo principal que se usa para transferir mensajes entre servidores de correo. De forma predeterminada, no es seguro. El protocolo seguridad de la capa de transporte (TLS) se introdujo hace años para admitir la transmisión cifrada de mensajes a través de SMTP. Normalmente se usa de forma oportunista en lugar de como requisito, dejando mucho tráfico de correo electrónico en texto no cifrado y vulnerable a la interceptación por parte de actores incorrectos. Además, SMTP determina las direcciones IP de los servidores de destino a través de la infraestructura de DNS pública, que es susceptible a ataques de suplantación de identidad y ataques de tipo "man in the middle" (MITM). Esta vulnerabilidad llevó a la creación de muchos estándares nuevos para aumentar la seguridad para enviar y recibir correo electrónico. Uno de esos estándares es la autenticación basada en DNS de entidades con nombre (DANE).

DANE para RFC 7672 smtp usa la presencia de un registro de autenticación de seguridad de la capa de transporte (TLSA) en el conjunto de registros DNS de un dominio para indicar que un dominio y sus servidores de correo admiten DANE. Si no hay ningún registro TLSA presente, la resolución DNS para el flujo de correo funciona como de costumbre sin ninguna comprobación DANE. El registro TLSA indica de forma segura la compatibilidad con TLS y publica la directiva DANE para el dominio. Por lo tanto, el envío de servidores de correo puede autenticar correctamente servidores de correo receptor legítimos mediante SMTP DANE. Esta autenticación hace que sea resistente a los ataques de degradación y MITM. DANE tiene dependencias directas en DNSSEC, que funciona firmando digitalmente registros para búsquedas DNS mediante criptografía de clave pública. Las comprobaciones de DNSSEC se producen en los solucionadores DNS recursivos, los servidores DNS que realizan consultas DNS para los clientes. DNSSEC garantiza que los registros DNS no se manipulen y sean auténticos.

Una vez que los registros de recursos relacionados con MX, A/AAAA y DNSSEC de un dominio se devuelven al solucionador recursivo DNS como DNSSEC auténtico, el servidor de correo de envío solicita el registro TLSA correspondiente a las entradas del host MX. Si el registro TLSA está presente y se ha comprobado que es auténtico mediante otra comprobación DE DNSSEC, el solucionador recursivo de DNS devuelve el registro TLSA al servidor de correo de envío.

Una vez recibido el registro TLSA auténtico, el servidor de correo de envío establece una conexión SMTP al host MX asociado al registro TLSA auténtico. El servidor de correo de envío intenta configurar TLS y comparar el certificado TLS del servidor con los datos del registro TLSA para validar que el servidor de correo de destino conectado al remitente es el servidor de correo receptor legítimo. El mensaje se transmite (mediante TLS) si la autenticación se realiza correctamente. Cuando se produce un error en la autenticación o si el servidor de destino no admite TLS, Exchange Online reintenta todo el proceso de validación. Comienza con una consulta DNS para el mismo dominio de destino de nuevo después de 15 minutos, luego 15 minutos después de eso y, a continuación, cada hora durante las siguientes 24 horas. Si la autenticación continúa con errores después de 24 horas de reintento, el mensaje expira y se genera un NDR con detalles de error y se envía al remitente.

¿Cuáles son los componentes de DANE?

Registro de recursos TLSA

Use el registro tls authentication (TLSA) para asociar el certificado X.509 de un servidor o el valor de clave pública con el nombre de dominio que contiene el registro. Solo puede confiar en los registros TLSA si habilita DNSSEC en su dominio. Si usa un proveedor de DNS para hospedar el dominio, es posible que ofrezcan DNSSEC como una configuración al configurar el dominio. Para obtener más información sobre la firma de zona DNSSEC, consulte Información general sobre DNSSEC.

Registro TLSA de ejemplo:

Captura de pantalla que muestra un ejemplo de un registro TLSA.

El tipo de registro TLSA tiene cuatro campos configurables:

Campo de uso de certificado: especifica cómo el servidor de correo electrónico de envío debe comprobar el certificado del servidor de correo electrónico de destino.

Valor Acrónimo Descripción
01 PKIX-TA El certificado usado es la entidad de certificación pública de anclaje de confianza de la cadena de confianza X.509.
11 PKIX-EE El certificado comprobado es el servidor de destino; Las comprobaciones de DNSSEC deben comprobar su autenticidad.
2 DANE-TA Use la clave privada del servidor del árbol X.509 que debe validar un delimitador de confianza en la cadena de confianza. El registro TLSA especifica el delimitador de confianza que se usará para validar los certificados TLS para el dominio.
3 DANE-EE Solo coincide con el certificado del servidor de destino.

1 Exchange Online sigue las instrucciones de implementación de RFC que indican que los valores del campo de uso de certificado de 0 o 1 no deben usarse cuando dane se implementa con SMTP. Cuando un registro TLSA que tiene un valor de campo Uso de certificado de 0 o 1 se devuelve a Exchange Online, Exchange Online lo considera no utilizable. Si se encuentran inutilizables todos los registros TLSA, Exchange Online no realiza los pasos de validación dane para 0 o 1 al enviar el correo electrónico. En su lugar, debido a la presencia de un registro TLSA, Exchange Online exige el uso de TLS para enviar el correo electrónico, enviar el correo electrónico si el servidor de correo electrónico de destino admite TLS o quitar el correo electrónico y generar un NDR si el servidor de correo electrónico de destino no admite TLS.

En el registro TLSA de ejemplo, el campo Uso del certificado se establece en "3", por lo que los datos de asociación de certificados ('abc123... xyz789') solo coincide con el certificado del servidor de destino.

Campo selector: indica qué partes del certificado del servidor de destino se deben comprobar.

Valor Acrónimo Descripción
0 Cert Use el certificado completo.
1 SPKI (información de clave pública del asunto) Use la clave pública del certificado y el algoritmo con el que se identifica la clave pública que se va a usar.

En el registro TLSA de ejemplo, el campo selector se establece en "1", por lo que los datos de asociación de certificados coinciden mediante la clave pública del certificado de servidor de destino y el algoritmo con el que se identifica la clave pública.

Campo de tipo coincidente: indica el formato en el que se representa el certificado en el registro TLSA.

Valor Acrónimo Descripción
0 Full Los datos del registro TSLA son el certificado completo o SPKI.
1 SHA-256 Los datos del registro TSLA son un hash SHA-256 del certificado o spki.
2 SHA-512 Los datos del registro TSLA son un hash SHA-512 del certificado o spki.

En el registro TLSA de ejemplo, el campo De tipo coincidente se establece en "1", por lo que los datos de asociación de certificados son un hash SHA-256 de la información de clave pública del firmante del certificado de servidor de destino.

Datos de asociación de certificados: especifica los datos de certificado que se usan para la coincidencia con el certificado de servidor de destino. Estos datos dependen del valor del campo selector y del valor de tipo coincidente.

En el registro TLSA de ejemplo, los datos de la asociación de certificados se establecen en 'abc123.. xyz789'. Dado que el valor campo selector del ejemplo se establece en "1", hace referencia a la clave pública del certificado de servidor de destino y al algoritmo que se identifica para usarlo con él. Y dado que el valor del campo Tipo de coincidencia del ejemplo se establece en "1", hace referencia al hash SHA-256 de la información de clave pública del firmante desde el certificado de servidor de destino.

Según las instrucciones de implementación de RFC para SMTP DANE, use un registro TLSA con el campo Uso de certificado establecido en 3, el campo Selector establecido en 1 y el campo Tipo de coincidencia establecido en 1.

Exchange Online flujo de correo con SMTP DANE

El proceso de flujo de correo para Exchange Online con SMTP DANE, que se muestra en el siguiente gráfico de flujo, valida la seguridad del registro de dominio y recursos a través de DNSSEC, la compatibilidad con TLS en el servidor de correo de destino y que el certificado del servidor de correo de destino coincide con lo que se espera en función de su registro TLSA asociado.

Solo hay dos escenarios en los que un error SMTP DANE provoca que el correo electrónico se bloquee:

  • El dominio de destino indica la compatibilidad con DNSSEC, pero uno o varios registros se devuelven como no autenticados.

  • Todos los registros MX del dominio de destino tienen registros TLSA y ninguno de los certificados del servidor de destino coincide con lo esperado según los datos de registro de TSLA, o bien el servidor de destino no admite una conexión TLS.

    Captura de pantalla que muestra el flujo de correo en línea de Exchange con SMTP DANE.

Tecnología Información adicional
Agente de transferencia de correo: la seguridad de transporte estricta (MTA-STS) ayuda a frustrar los ataques de degradación y man-in-the-middle proporcionando un mecanismo para establecer directivas de dominio que especifican si el servidor de correo electrónico de destino admite TLS y qué hacer cuando no se puede negociar TLS, por ejemplo, detener la transmisión. Más información sobre la próxima compatibilidad de Exchange Online con MTA-STS entrante y saliente se publicará a finales de este año.

noticias de transporte de Exchange Online de Microsoft Ignite 2020: Microsoft Tech Community

rfc8461 (ietf.org)
Sender Policy Framework (SPF) usa información de IP para asegurarse de que los sistemas de correo electrónico de destino confían en los mensajes enviados desde el dominio personalizado. Cómo el marco de directivas de remitente (SPF) evita la suplantación de identidad
DomainKeys Identified Mail (DKIM) usa información de certificado X.509 para garantizar que los sistemas de correo electrónico de destino confíen en los mensajes enviados salientes desde el dominio personalizado. Cómo usar DKIM para el correo electrónico en su dominio personalizado
La autenticación de mensajes basada en dominio, informes y conformidad (DMARC) funciona con el marco de directivas de remitente y el correo identificado DomainKeys para autenticar a los remitentes de correo y asegurarse de que los sistemas de correo electrónico de destino confían en los mensajes enviados desde el dominio. Pasos de configuración para usar DMARC para validar el correo electrónico

DANE SMTP entrante con DNSSEC

Requisitos previos

Antes de empezar, asegúrese de cumplir los siguientes requisitos previos:

  1. Agregue el dominio como dominio aceptado y asegúrese de que el estado del dominio es Correcto en el Centro de Administración de Microsoft 365. En esta documentación se da por supuesto que el registro MX del dominio está establecido en la prioridad 0 o 10 y que no hay ninguna "reserva" o registro MX secundario. Si tiene un registro MX de reserva, trabaje estrechamente con el administrador de Exchange Online para asegurarse de que los cambios se realicen correctamente.
  2. Para recibir todas las ventajas de seguridad de la característica, habilite DNSSEC para su dominio.
  3. Acceso a Exchange Online PowerShell y los permisos para ejecutar los cmdlets descritos en Exchange Online PowerShell.

Nota:

Para habilitar DNSSEC para un dominio que usa una puerta de enlace de terceros, siga los pasos del 1 al 3, siguiendo la nota al final del paso 3 en puertas de enlace de terceros.

Configuración de SMTP DANE de entrada con DNSSEC

Nota:

El aprovisionamiento y las actualizaciones de registros DNS pueden tardar algún tiempo en completarse. Los cambios de DNS pueden tardar más de lo esperado en ser visibles debido a varias capas de almacenamiento en caché.

Para configurar SMTP DANE de entrada con DNSSEC, realice los pasos siguientes:

  1. Actualice el TTL del registro MX existente al TTL más bajo posible (pero no inferior a 30 segundos). A continuación, espere a que el TTL anterior expire antes de continuar. Por ejemplo, si el TTL del registro MX existente era de 3.600 segundos (1 hora) antes de cambiarlo, debe esperar 1 hora antes de continuar con el paso 2.

  2. Conéctese a Exchange Online PowerShell.

    Advertencia

    Si usa MTA-STS, debe establecer el modo de directiva en "testing" y actualizar el identificador en el registro txt de MTA-STS. (Puede usar la hora actual en UTC como el nuevo identificador de directiva). A continuación, espere a que el "max_age" de la directiva expire antes de continuar. Por ejemplo, si el "max_age" de la directiva STS existente era de 3.600 segundos (1 hora) antes de cambiarla, debe esperar 1 hora antes de continuar.

  3. Para el dominio que desea habilitar SMTP DANE con DNSSEC, habilite DNSSEC en el dominio mediante la ejecución del siguiente comando (reemplace "domain" por el nombre del dominio elegido, por ejemplo, contosotest.com):

    Enable-DnssecForVerifiedDomain -DomainName <DomainName>

    Nota:

    Este comando puede tardar unos minutos en ejecutarse.

    Salida de ejemplo de ejecución correcta

    Resultado DnssecMxValue ErrorData
    Correcto contosotest-com.o-v1.mx.microsoft

    La respuesta correcta proporciona el valor MX para el dominio. Este valor es el nombre al que apunta el nuevo registro MX para el dominio que está habilitando con DNSSEC. Por ejemplo, contosotest-com.o-v1.mx.microsoft.

  4. Tome el valor "DnssecMxValue", vaya al registrador DNS que hospeda el dominio, agregue un nuevo registro MX con el valor devuelto en el paso 3, establezca el TTL en el valor más bajo posible (pero no inferior a 30 segundos) y establezca la prioridad del nuevo registro MX en 20.

    Nota:

    Si usa una puerta de enlace de correo electrónico de terceros y desea usar este valor como el nuevo host de destino Exchange Online al que la puerta de enlace de correo electrónico de terceros envía el correo entrante, vaya al portal de administración del tercero, actualice el host inteligente de destino que el tercero usa para enviar a Exchange Online y, a continuación, valide que "flujo de correo funciona a través de la prueba DNSSEC (asegúrese de seleccionar "Validación DNSSEC" durante la entrada de prueba, no "Dane Validation [including DNSSEC])" en el Analizador de conectividad remota de Microsoft: Entrada de prueba". Si el correo fluye según lo previsto, no es necesario seguir estos pasos. Si desea habilitar SMTP DANE para este dominio, vaya al paso 7.

    Advertencia

    Si usa MTA-STS, asegúrese de que el modo de directiva está establecido en "testing". A continuación, elimine la fila mx actual que contiene la información de registro MX heredada y agregue el nuevo FQDN al archivo de directiva MTA-STS como una nueva fila mx. A continuación, actualice el identificador de directiva en la directiva y el registro TXT MTA-STS (puede usar la hora actual en UTC como el nuevo identificador de directiva).

  5. Compruebe que el nuevo MX funciona a través de la prueba de Email SMTP entrante (https://testconnectivity.microsoft.com/tests/O365InboundSmtp/input) expandiendo los pasos de prueba y comprobando que el exchanger de correo que termina en mx.microsoft se ha probado correctamente. Es posible que tenga que volver a intentar esta prueba, en función del almacenamiento en caché de DNS.

    Salida correcta de ejemplo

    Captura de pantalla que muestra el ejemplo de una salida que notifica un éxito del proceso implementado.

  6. Cambie la prioridad del MX heredado que apunta a mail.protection.outlook.com de prioridad actual a 30; cambie la prioridad del registro MX creado en el paso 3 para que se establezca en la prioridad 0 (prioridad más alta).

  7. Elimine el registro MX heredado que termina con "mail.protection.outlook.com", "mail.eo.outlook.com" o "mail.protection.outlook.de". A continuación, actualice el TTL del registro MX que termina en mx.microsoft a 3600 segundos. Opcionalmente, puede confirmar que todo funciona según lo esperado mediante la prueba DNSSEC (asegúrese de seleccionar "Validación DNSSEC" durante la entrada de prueba, no "Dane Validation [including DNSSEC])" en el Analizador de conectividad remota. Es posible que tenga que volver a intentar esta prueba, en función del almacenamiento en caché de DNS y las TTL.

    Una vez que expiren los TTL en el registro MX heredado, una salida correcta tendrá el siguiente aspecto:

    Captura de pantalla que muestra el ejemplo de una salida que notifica que los dominios han superado correctamente la prueba de validación de DNSSEC.

  8. Ejecute el siguiente comando [replace (DomainName) con el nombre del dominio elegido, por ejemplo, contosotest.com] si desea habilitar SMTP DANE para ese mismo dominio una vez completada la habilitación de DNSSEC:

    Enable-SmtpDaneInbound -DomainName <DomainName>
    Resultado ErrorData
    Correcto

  9. Compruebe que el registro TLSA se ha propagado (lo que puede tardar entre 15 y 30 minutos) mediante una herramienta en línea de su elección y el Analizador de conectividad remota de Microsoft: Entrada de prueba.

    Una vez que haya completado la habilitación de DNSSEC y Exchange Online aprovisione el registro SMTP DANE (TLSA), se muestra una salida correcta como se muestra en la captura de pantalla siguiente:

    Captura de pantalla que muestra el ejemplo de una salida que notifica que los dominios han superado correctamente la prueba de validación de Dane.

    Exchange Online hospeda varios registros TLSA para aumentar la confiabilidad de un éxito de las validaciones DE DANE SMTP. Se espera que algunos de los registros TLSA no superen la validación. Siempre que un registro TLSA pase la validación, SMTP DANE se configura correctamente y el correo electrónico se protege con SMTP DANE.

    Advertencia

    Si usa MTA-STS, después de validar que la directiva funciona y que el correo fluye según lo esperado, vuelva a establecer el modo de directiva en "aplicar" y actualice el identificador en el registro txt de MTA-STS. (Puede usar la hora actual en UTC como el nuevo identificador de directiva).

Limitaciones

  1. Dominios de registro virales o de autoservicio: los dominios que configuró como "autoservicio" no se admiten actualmente con EL DANE SMTP entrante con DNSSEC.

  2. onmicrosoft.com dominios: el dominio "onmicrosoft.com" para el inquilino no se admite actualmente con EL DANE SMTP entrante con DNSSEC. Estamos investigando la compatibilidad con EL DANE SMTP entrante con DNSSEC para los dominios de onmicrosoft.com; sin embargo, la ETA es desconocida.

  3. Puertas de enlace de terceros: si usa una puerta de enlace de correo electrónico de terceros en la ruta de acceso de entrada que acepta correo para el inquilino, realiza algún procesamiento y, a continuación, la retransmite a Exchange Online, solo puede usar esta característica para proteger los correos electrónicos retransmitidos desde la puerta de enlace de terceros a Exchange Online si la puerta de enlace de terceros admite SMTP DANE con validación DNSSEC. Si está en esta configuración, debe configurar EL DANE SMTP entrante con DNSSEC mediante Exchange PowerShell.

  4. Otra integración de terceros con el flujo de correo: algunos clientes usan puertas de enlace de terceros en la ruta de acceso de salida, donde el correo electrónico se envía a terceros a través de un conector, el tercero realiza algún procesamiento y, a continuación, vuelve a enviar a Exchange Online y, a continuación, Exchange Online finalmente envía el correo electrónico. Es posible que estos clientes necesiten trabajar con su proveedor de terceros al habilitar la característica para que no haya interrupciones. La retransmisión de terceros debe usar una búsqueda DNS al enviar el correo electrónico a Exchange Online y usar el nuevo nombre de host del registro MX:> contoso-com.( subdominio).mx.microsoft creado durante la habilitación de características.

  5. Dominios totalmente delegados: los dominios que Microsoft hospeda y usan la delegación de NS para que los servidores de nombres de Microsoft sean autoritativos para el dominio se admiten con SMTP DANE entrante con DNSSEC. Tenemos la intención de admitir EL DANE SMTP entrante con DNSSEC para estos dominios; sin embargo, la ETA es desconocida.

Problemas de depuración que surgen al habilitar EL DANE SMTP entrante con DNSSEC

Problemas con Enable/Disable-DnssecForVerifiedDomain y Enable/Disable-SmtpDane Inbound

  1. DomainNotFound

    Mensaje (DNSSEC): "Error al habilitar o deshabilitar DNSSEC debido a que el dominio contoso.com no existe en AAD".
    Mensajes (SMTP DANE)::

    • "Error al habilitar o deshabilitar SMTP DANE debido a que el dominio contoso.com no existe en AAD".
    • "Error al habilitar o deshabilitar SMTP DANE debido a que el dominio no contoso.com encuentra en la lista de dominios aceptados".
      Causa: el dominio proporcionado no se encontró en la lista de dominios aceptados.
      Acciones que realizar: vaya al Centro de Administración de Microsoft 365 y asegúrese de que el dominio se comprueba con el inquilino. Si el dominio está en buen estado en el Centro de Administración de Microsoft 365, vaya al Centro de Administración de Exchange y asegúrese de que el dominio se agrega como un "Dominio aceptado".

    DNSSEC

    Resultado DnssecMxValue ErrorData
    Error ErrorCode: "DomainNotFound" ErrorDetails "Error al habilitar DNSSEC...

    SMTP DANE

    Resultado ErrorData
    Error ErrorCode: "DomainNotFound" ErrorDetails "SMTP DANE enabling...

  2. DnsSecOperationFailed

    Mensaje (DNSSEC): "Error al habilitar o deshabilitar DNSSEC debido a AdditionalErrorDetails. Vuelva a intentar la operación más adelante.
    Mensajes (SMTP DANE): error de habilitación o deshabilitación de SMTP DANE debido a AdditionalErrorDetails. Vuelva a intentar la operación más adelante.
    Causa: error al intentar crear la zona DNS o los registros adecuados.
    Acciones que realizar: intente volver a ejecutar el cmdlet.

    DNSSEC

    Resultado DnssecMxValue ErrorData
    Error ErrorCode: "DnssecOperationFailed" ErrorDetails "Error al habilitar DNSSEC...

    SMTP DANE

    Resultado ErrorData
    Error ErrorCode: "DnssecOperationFailed" ErrorDetails "SMTP DANE enabling ...

  3. PartitionNotFound

    Mensajes (SMTP DANE): "Error al habilitar o deshabilitar SMTP DANE debido a que el dominio contoso.com no tiene una partición".
    Causa: DNSSEC no está habilitado para el dominio.
    Acciones que se deben realizar: asegúrese de usar un dominio habilitado para DNSSEC.

    Resultado ErrorData
    Error ErrorCode: ErrorDetails 'PartitionNotFound' 'SMTP DANE enabling

  4. DomainNotSupported

    Mensaje (DNSSEC): "El dominio especificado es un dominio de onmicrosoft: contoso-com.onmicrosoft.com".
    Mensajes (SMTP DANE): "El dominio especificado es un dominio onmicrosoft: contoso-com.onmicrosoft.com".
    Causa: el dominio es un dominio inicial o MOERA. Esos dominios no se admiten actualmente.
    Acciones que se deben realizar: asegúrese de usar un dominio que no termine con "onmicrosoft.com".

    DNSSEC

    Resultado DnssecMxValue ErrorData
    Error ErrorCode: "DomainNotSupported" ErrorDetails "El dominio especificado...

    SMTP DANE

    Resultado ErrorData
    Error ErrorCode: "DomainNotSupported" ErrorDetails "El dominio especificado...
Problemas con Get-DnssecStatusForVerifiedDomain

  1. Mensaje: "EG001: No se puede recuperar el estado de la característica DNSSEC para el dominio [{domain}]."
    Causa: Al validar la configuración del dominio en Exchange Online, el dominio no se agregó a Exchange Online. Si cree que ya ha agregado este dominio a Exchange Online, vuelva a intentar ejecutar el cmdlet, ya que este problema podría ser temporal.
    Acciones que realizar: vuelva a intentar el cmdlet. Si se sigue produciendo un error, vaya al Centro de Administración de Microsoft 365 y complete el proceso de instalación de este dominio.

  2. Mensaje: "EG002: El dominio [{domain}] no es un dominio comprobado de la organización".
    Causa: al validar la configuración del dominio en Exchange Online, el dominio se agregó a Exchange Online pero no se comprobó.
    Acciones que realizar: vaya al Centro de Administración de Microsoft 365 y complete el proceso de configuración y verificación de este dominio.

  3. Mensaje: "Se produce un error de consulta DNS al obtener registros MX para el dominio [{domain}]".
    Causa: durante la validación de DNS, se produjo un error de DNS genérico al consultar el dominio.
    Acciones que realizar: vuelva a intentar ejecutar el cmdlet. Es posible que tenga que revisar la configuración del dominio que está intentando habilitar con SMTP DANE con DNSSEC.

  4. Mensaje: "No se encontró el dominio [{dominio}]".
    Causa: durante la validación de DNS, se produjo un error NXDOMAIN al consultar el dominio.
    Acciones que realizar: vuelva a intentar ejecutar el cmdlet después de comprobar la configuración del registro MX para el dominio. La propagación de DNS puede tardar hasta 48 horas en algunos proveedores DNS.

  5. Mensaje: 'ED003: Se encontró el dominio [{dominio}]. No se encontraron registros MX auténticos.'
    Causa: Durante la validación de DNSSEC, no se encontró un registro MX que se resolvió en un registro A protegido por DNSSEC (el registro A para el valor "hostname" del registro MX).
    Acciones que realizar: vuelva a intentar ejecutar el cmdlet después de comprobar la configuración del registro MX para el dominio. La propagación de DNS puede tardar hasta 48 horas en algunos proveedores DNS.

  6. Mensaje: "EX002: El valor del registro MX no coincidía con el esperado".
    Causa: durante la validación MX, no se encontró un registro MX que coincida con el esperado.
    Acciones que realizar: revise los registros MX en su dominio. Asegúrese de que un registro MX coincide con el registro esperado que se genera después de ejecutar Enable-DnssecForVerifiedDomain o Get-DnssecStatusForVerifiedDomain.

  7. Mensaje: "EX003: La prioridad del registro MX no coincidió con la esperada".
    Causa: durante la validación MX, se encontró el registro MX esperado, pero su prioridad no se estableció en 0.
    Acciones que se deben realizar: establezca el registro MX (que contiene el valor devuelto al ejecutar Enable-DnssecForVerifiedDomaino Get-DnssecStatusForVerifiedDomain) como prioridad 0.

  8. Mensaje: "EX004: Hay un registro MX diferente con la misma preferencia que la esperada".
    Causa: Durante la validación MX, el registro MX de prioridad más alta no era el registro MX esperado.
    Acciones que realizar: si completó los pasos 1 a 4 de Configuración de SMTP DANE entrante con DNSSEC, complete los pasos 5 y 6 cambiando las prioridades de los registros MX para que el MX esperado sea 0 (prioridad máxima), validando la configuración y, a continuación, eliminando el registro MX heredado.

  9. Mensaje: "EX005: Hay un registro MX diferente con una preferencia inferior a la esperada".
    Causa: Durante la validación MX, un registro MX para el dominio no coincidió con el registro MX esperado.
    Acciones que realizar: si completó los pasos del 1 al 5 de Configuración del DANE SMTP entrante con DNSSEC, complete el paso 6 eliminando el registro MX heredado.

  10. Mensaje: "EX006: Hay un registro MX diferente con mayor preferencia que la esperada".
    Causa: durante la validación MX, un registro MX diferente tenía una preferencia mayor que la esperada.
    Acciones que realizar: establezca el registro MX heredado (que termina en mail.protection.outlook.com, mail.eo.outlook.com o mail.protection.outlook.de) en la prioridad 20.

  11. Mensaje: "EX007: No se encontró el registro MX".
    Causa: durante la validación MX, no se encontró un registro MX que coincida con el esperado.
    Acciones que realizar: revise los registros MX en su dominio. Asegúrese de que un registro MX coincide con el registro esperado que se genera después de ejecutar Enable-DnssecForVerifiedDomain o Get-DnssecStatusForVerifiedDomain.

  12. Mensaje: "EX008: se encontró el registro MX correcto, pero con una preferencia menor de la esperada".
    Causa: Durante la validación MX, el registro MX esperado tenía una prioridad incorrecta.
    Acciones que se deben realizar: establezca el registro MX (que contiene el valor devuelto al ejecutar Enable-DnssecForVerifiedDomain o Get-DnssecStatusForVerifiedDomain) en la prioridad 0.

  13. Mensaje: "EX009: Se encontró el registro MX correcto, pero con mayor preferencia de la esperada".
    Causa: Durante la validación MX, el registro MX esperado tenía una prioridad incorrecta.
    Acciones que se deben realizar: establezca el registro MX (que contiene el valor devuelto al ejecutar Enable-DnssecForVerifiedDomain o Get-DnssecStatusForVerifiedDomain) en la prioridad 0.

  14. Mensaje: "EX010: Error desconocido al buscar registros MX en el dominio [{dominio}]."
    Causa: durante la validación MX, se produjo un error DE DNS genérico.
    Acciones que realizar: vuelva a intentar ejecutar el cmdlet después de comprobar la configuración del registro MX para el dominio. La propagación de DNS puede tardar hasta 48 horas en algunos proveedores DNS.

  15. Mensaje: "EX012: No se encontraron registros MX para el dominio [{domain}]."
    Causa: durante la validación MX, no se encontró un registro MX que coincida con el esperado.
    Acciones que realizar: revise los registros MX en su dominio. Asegúrese de que un registro MX coincide con el registro esperado que se genera después de ejecutar Enable-DnssecForVerifiedDomain o Get-DnssecStatusForVerifiedDomain.

  16. Mensaje: "EX013: Registro MX esperado desconocido para el dominio [{dominio}]."
    Causa: durante la validación MX, no se encontró un registro MX que coincida con el esperado.
    Acciones que realizar: revise los registros MX en su dominio. Asegúrese de que un registro MX coincide con el registro esperado que se genera después de ejecutar Enable-DnssecForVerifiedDomain o Get-DnssecStatusForVerifiedDomain.

  17. Mensaje: 'ES001: Falta el registro MX esperado en la directiva mientras el modo es ''aplicado''.'
    Causa: Durante la validación de MTA-STS, no se encontró el valor mx que coincide con el registro esperado.
    Acciones que se van a realizar: establezca el modo de la directiva MTA-STS que se va a probar; a continuación, agregue el valor mxhostname (devuelto al ejecutar Enable-DnssecForVerifiedDomain o Get-DnssecStatusForVerifiedDomain) como fila en la directiva MTA-STS.

  18. Mensaje: 'ES002: No se encontró ningún registro MX esperado con el que comparar la directiva. Habilite primero la característica DNSSEC para el dominio [{domain}].
    Causa: Se encontró MTA-STS, pero el estado DNSSEC del dominio no se pudo intentar.
    Acciones que realizar: complete los pasos descritos en Configuración de SMTP DANE entrante con DNSSEC.

Mitigación de problemas de flujo de correo con EL DANE SMTP de entrada con DNSSEC

Hay tres escenarios clave para los problemas de flujo de correo una vez que se habilita el DANE SMTP de entrada con DNSSEC:

  1. Problema con errores en las validaciones SMTP DANE: para obtener información sobre cómo mitigar este problema, vea Mitigación de errores de validaciones DE DANE SMTP.
  2. Error en las validaciones DNSSEC: para obtener información sobre cómo mitigar este problema, consulte Mitigación de errores en las validaciones DNSSEC.
  3. Problema con el valor MX: para obtener información sobre cómo mitigar este problema, consulte Mitigación de problemas con el valor MX.
Mitigación de errores en las validaciones de SMTP DANE

Para mitigar el impacto de las validaciones de SMTP DANE, ejecute el siguiente comando:

Disable-SmtpDaneInbound -DomainName <DomainName>
Error en la mitigación de las validaciones de DNSSEC

  1. Para mitigar cualquier impacto de errores en las validaciones DNSSEC, debe deshabilitar DNSSEC en el dominio (contoso.com) a través del proveedor dns.

    Nota:

    Si deshabilitar DNSSEC no resuelve el problema, el problema podría estar con el valor MX.

  2. Deshabilite DNSSEC en el dominio a través del proveedor dns. A continuación, abra una incidencia de soporte técnico con su proveedor de DNS para averiguar cómo volver a habilitar DNSSEC para su dominio de forma segura.

Mitigación de problemas con el valor MX

  1. Asegúrese de que el valor MX coincide con el valor del Centro de Administración de Microsoft 365 -> Configuración -> Dominios.

  2. Seleccione el dominio, seleccione Registros DNS y, a continuación, ejecute Comprobar estado.

  3. Asegúrese de que el registro MX se muestra como Correcto; Si no es así, actualice el valor a lo que se proporciona en el centro de administración.

  4. Vaya al registrador DNS y busque el registro MX del dominio. El valor del nombre de host es:

    <MX token>.<subdomain>.mx.microsoft

  5. Cree un segundo registro MX con el siguiente valor de nombre de host y establezca la prioridad en 20:

    <MX token>.mail.protection.outlook.com

    Nota:

    Reemplace el valor "MX Token" por el token MX del registro MX actual del dominio que se encuentra en el paso 4. Por ejemplo, el token MX para contosotest.com es contosotest-com.

  6. Asegúrese de que el registro MX que creó en el paso 5 está funcionando.

    Importante

    Una manera de asegurarse de que el segundo registro MX funciona es usar el Analizador de conectividad remota de Microsoft.

    1. Escriba el dominio (por ejemplo, contoso.com) en la prueba; a continuación, seleccione Realizar prueba.
    2. Abra Pasos de prueba.
    3. Abra Pasos de prueba para probar el flujo de correo SMTP entrante para el dominio "admin@(domain)".
    4. Abra Detalles adicionales en Intento de recuperar registros DNS MX para el dominio "(domain)".
    5. Confirme que el registro MX (token MX).mail.protection.outlook.com está en buen estado.

  7. Si el flujo de correo funciona con el registro MX token.mail.protection.outlook.com MX, ejecute el siguiente comando:

    Disable-DnssecForVerifiedDomain -DomainName <DomainName>

  8. Elimine el registro DNSSEC MX que coincida con los valores siguientes:

    <MX token>.<subdomain>.mx.microsoft

  9. Asegúrese de que el registro MX que creó en el paso 5 es el único registro MX y que está establecido en la prioridad 0 (prioridad más alta).

¿Cómo pueden Exchange Online clientes usar EL DANE SMTP saliente con DNSSEC?

Como cliente Exchange Online, no es necesario hacer nada para configurar esta seguridad de correo electrónico mejorada para el correo electrónico saliente. Hemos creado esta seguridad de correo electrónico mejorada para usted y está activada de forma predeterminada para todos los clientes Exchange Online. Exchange Online usa esta seguridad cuando el dominio de destino anuncia la compatibilidad con DANE. Para aprovechar las ventajas del envío de correo electrónico con comprobaciones DNSSEC y DANE, póngase en contacto con sus socios empresariales con los que intercambia correo electrónico que necesitan para implementar DNSSEC y DANE para que puedan recibir correo electrónico con estos estándares.

Solución de problemas de envío de correos electrónicos con SMTP DANE

Actualmente, hay cuatro códigos de error para DANE al enviar correos electrónicos con Exchange Online. Microsoft está actualizando activamente esta lista de códigos de error. Puede ver los errores en:

  1. El portal del Centro de Administración exchange a través de la vista Detalles del seguimiento de mensajes.

  2. NDR generados cuando no se envía un mensaje debido a un error DANE o DNSSEC.

  3. Herramienta Analizador de conectividad remota Analizador de conectividad remota de Microsoft.

    Código NDR Descripción
    4/5.7.321 starttls-not-supported: el servidor de correo de destino debe admitir TLS para recibir correo.
    4/5.7.322 certificado expirado: el certificado del servidor de correo de destino ha expirado.
    4/5.7.323 tlsa-invalid: error de validación dane del dominio.
    4/5.7.324 dnssec-invalid: el dominio de destino devolvió registros DNSSEC no válidos.

    Nota:

    Actualmente, cuando un dominio indica que admite DNSSEC pero produce un error en las comprobaciones DNSSEC, Exchange Online no genera el error 4/5.7.324 dnssec-invalid. Genera un error DNS genérico:

    4/5.4.312 DNS query failed

    Estamos trabajando activamente para solucionar esta limitación conocida. Si recibe esta instrucción de error, vaya al Analizador de conectividad remota de Microsoft y realice la prueba de validación dane en el dominio que generó el error 4/5.4.312. Los resultados muestran si se trata de un problema DNSSEC o de otro problema de DNS.

Solución de problemas 4/5.7.321 starttls-not-supported

Este error suele indicar un problema con el servidor de correo de destino. Después de recibir el mensaje:

  1. Compruebe que ha escrito correctamente la dirección de correo electrónico de destino.
  2. Alerte al administrador de correo electrónico de destino de que ha recibido este código de error para que pueda determinar si el servidor de destino está configurado correctamente para recibir mensajes mediante TLS.
  3. Vuelva a intentar enviar el correo electrónico y revise los detalles del seguimiento de mensajes del mensaje en el portal del Centro de Administración Exchange.

Solución de problemas del certificado 5.7.322 4/5.322 expirado

El servidor de correo electrónico de envío debe presentar un certificado X.509 válido que no haya expirado. Los certificados X.509 deben renovarse después de su expiración, normalmente anualmente. Después de recibir el mensaje:

  1. Alerte al administrador de correo electrónico de destino de que ha recibido este código de error y proporcione la cadena de código de error.
  2. Permita que se renueve el certificado de servidor de destino y que el registro TLSA se actualice para hacer referencia al nuevo certificado. A continuación, vuelva a intentar enviar el correo electrónico y revise los detalles del seguimiento del mensaje en el portal del Centro de Administración Exchange.

Solución de problemas 4/5.7.323 tlsa-invalid

Este código de error está relacionado con una configuración incorrecta del registro TLSA y solo se puede generar después de que se devuelva un registro TLSA auténtico de DNSSEC. Muchos escenarios durante la validación dane se producen después de que se devuelve el registro que puede dar lugar a que se genere el código. Microsoft está trabajando activamente en los escenarios que abarca este código de error, para que cada escenario tenga un código específico. Actualmente, uno o varios de estos escenarios podrían provocar la generación del código de error:

  1. El certificado del servidor de correo de destino no coincide con lo que espera el registro TLSA auténtico.
  2. El registro TLSA auténtico está mal configurado.
  3. El dominio de destino está bajo ataque.
  4. Cualquier otro error de DANE.

Después de recibir el mensaje:

  1. Alerte al administrador de correo electrónico de destino de que ha recibido este código de error y proporcione la cadena de código de error.
  2. Espere tiempo para que el administrador de correo electrónico de destino revise la configuración dane y la validez del certificado de servidor de correo electrónico. A continuación, vuelva a intentar enviar el correo electrónico y revise los detalles del seguimiento del mensaje en el portal del Centro de Administración Exchange.

Solución de problemas 4/5.7.324 dnssec-invalid

Exchange Online genera este código de error cuando el dominio de destino indica que es DNSSEC-authentic, pero Exchange Online no puede comprobarlo como DNSSEC-authentic.

Después de recibir el mensaje:

  1. Alerte al administrador de correo electrónico de destino de que ha recibido este código de error y proporcione la cadena de código de error.
  2. Espere tiempo para que el administrador de correo electrónico de destino revise la configuración de DNSSEC de su dominio. A continuación, vuelva a intentar enviar el correo electrónico y revise los detalles del seguimiento del mensaje en el portal del Centro de Administración Exchange.

Solución de problemas de recepción de correos electrónicos con SMTP DANE

Actualmente, los administradores de dominios receptores pueden usar dos métodos para validar y solucionar problemas de su configuración de DNSSEC y DANE para recibir correo electrónico de Exchange Online mediante los siguientes estándares:

  1. Adopción de TLS-RPT SMTP (informes de seguridad de la capa de transporte) introducidos en RFC8460
  2. Uso de la herramienta Analizador de conectividad remota Del Analizador de conectividad remota de Microsoft

TLS-RPT https://datatracker.ietf.org/doc/html/rfc8460 es un mecanismo de informes para que los remitentes proporcionen detalles a los administradores de dominio de destino sobre los éxitos y errores de DANE y MTA-STS con esos dominios de destino respectivos. Para recibir informes TLS-RPT, solo tiene que agregar un registro TXT en los registros DNS del dominio que incluya la dirección de correo electrónico o el URI al que desea que se envíen los informes. Exchange Online envía informes TLS-RPT en formato JSON.

En la tabla siguiente se muestra un ejemplo de un registro:

Tipo Nombre de dominio TTL Record
TXT _smtp._tls.microsoft.com 3600 v=TLSRPTv1; rua=https://tlsrpt.azurewebsites.net/report

El segundo método consiste en usar el Analizador de conectividad remota Analizador de conectividad remota de Microsoft Remote Connectivity Analyzer, que puede realizar las mismas comprobaciones DNSSEC y DANE en la configuración de DNS que Exchange Online realiza al enviar correo electrónico fuera del servicio. Este método es la forma más directa de solucionar errores en la configuración para recibir correo electrónico de Exchange Online mediante estos estándares.

Al solucionar errores, es posible que se generen los siguientes códigos de error:

Código NDR Descripción
4/5.7.321 starttls-not-supported: el servidor de correo de destino debe admitir TLS para recibir correo.
4/5.7.322 certificado expirado: el certificado del servidor de correo de destino ha expirado.
4/5.7.323 tlsa-invalid: error de validación dane del dominio.
4/5.7.324 dnssec-invalid: el dominio de destino devolvió registros DNSSEC no válidos.

Nota:

Actualmente, cuando un dominio indica que admite DNSSEC pero produce un error en las comprobaciones DNSSEC, Exchange Online no genera el error 4/5.7.324 dnssec-invalid. Genera un error DNS genérico:

4/5.4.312 DNS query failed

Estamos trabajando activamente para solucionar esta limitación conocida. Si recibe esta instrucción de error, vaya al Analizador de conectividad remota de Microsoft y realice la prueba de validación dane en el dominio que generó el error 4/5.4.312. Los resultados muestran si se trata de un problema DNSSEC o de otro problema de DNS.

Solución de problemas 4/5.7.321 starttls-not-supported

Nota:

Estos pasos son para los administradores de correo electrónico que solucionan problemas al recibir correo electrónico de Exchange Online mediante SMTP DANE.

Este error suele indicar un problema con el servidor de correo de destino. El Analizador de conectividad remota prueba la conexión con el servidor de correo. Por lo general, este código se genera en dos escenarios:

  1. El servidor de correo de destino no admite la comunicación segura en absoluto y se debe usar la comunicación no cifrada sin formato.
  2. El servidor de destino está configurado incorrectamente y omite el comando STARTTLS.

Después de recibir el mensaje:

  1. Compruebe la dirección de correo electrónico.
  2. Busque la dirección IP asociada a la instrucción de error para que pueda identificar el servidor de correo al que está asociada la instrucción.
  3. Compruebe la configuración del servidor de correo para asegurarse de que está configurado para escuchar el tráfico SMTP (normalmente los puertos 25 y 587).
  4. Espere unos minutos y vuelva a intentar la prueba con la herramienta Analizador de conectividad remota.
  5. Si todavía se produce un error, intente quitar el registro TLSA y vuelva a ejecutar la prueba con la herramienta Analizador de conectividad remota.
  6. Si no hay errores, este mensaje podría indicar que el servidor de correo que usa para recibir correo no admite STARTTLS. Es posible que tenga que actualizar a uno que admita STARTTLS para usar DANE.

Solución de problemas del certificado 5.7.322 4/5.322 expirado

Nota:

Estos pasos son para los administradores de correo electrónico que solucionan problemas al recibir correo electrónico de Exchange Online mediante SMTP DANE.

El servidor de correo electrónico de envío debe presentar un certificado X.509 válido que no haya expirado. Los certificados X.509 deben renovarse después de su expiración, normalmente anualmente. Después de recibir el mensaje:

  1. Compruebe la dirección IP asociada a la instrucción de error para que pueda identificar el servidor de correo al que está asociado. Busque el certificado expirado en el servidor de correo electrónico que identificó.
  2. Inicie sesión en el sitio web del proveedor de certificados.
  3. Seleccione el certificado expirado y siga las instrucciones para renovar y pagar por la renovación.
  4. Una vez que el proveedor compruebe la compra, descargue un nuevo certificado.
  5. Instale el certificado renovado en su servidor de correo asociado.
  6. Actualice el registro TLSA asociado del servidor de correo con los datos del nuevo certificado.
  7. Después de esperar una cantidad de tiempo adecuada, vuelva a intentar la prueba con la herramienta Analizador de conectividad remota.

Solución de problemas 4/5.7.323 tlsa-invalid

Nota:

Estos pasos son para los administradores de correo electrónico que solucionan problemas al recibir correo electrónico de Exchange Online mediante SMTP DANE.

Este código de error está relacionado con una configuración incorrecta del registro TLSA. El código de error solo se puede generar después de que se devuelva un registro TLSA auténtico de DNSSEC. Sin embargo, muchos escenarios durante la validación dane se producen después de que se devuelva el registro que puede dar lugar a que se genere el código. Microsoft está trabajando activamente en los escenarios que abarca este código de error, para que cada escenario tenga un código específico. Actualmente, uno o varios de estos escenarios pueden provocar la generación del código de error:

  1. El registro TLSA auténtico está mal configurado.
  2. El certificado aún no es válido o está configurado para un período de tiempo futuro.
  3. El dominio de destino está bajo ataque.
  4. Cualquier otro error de DANE.

Después de recibir el mensaje:

  1. Compruebe la dirección IP asociada a la instrucción de error para identificar el servidor de correo.
  2. Identifique el registro TLSA asociado al servidor de correo.
  3. Compruebe la configuración del registro TLSA para asegurarse de que indica al remitente que realice las comprobaciones DANE preferidas y que los datos de certificado correctos se incluyen en el registro TLSA.
    1. Si necesita actualizar el registro en busca de discrepancias, espere unos minutos y vuelva a ejecutar la prueba con la herramienta Analizador de conectividad remota.
  4. Busque el certificado en el servidor de correo.
  5. Compruebe la ventana de tiempo para la que el certificado es válido. Si se establece para iniciar la validez en una fecha futura, debe renovarse para la fecha actual.
    1. Inicie sesión en el sitio web del proveedor de certificados.
    2. Seleccione el certificado expirado y siga las instrucciones para renovar y pagar por la renovación.
    3. Una vez que el proveedor compruebe la compra, puede descargar un nuevo certificado.
    4. Instale el certificado renovado en su servidor de correo asociado.

Solución de problemas 4/5.7.324 dnssec-invalid

Nota:

Estos pasos son para los administradores de correo electrónico que solucionan problemas al recibir correo electrónico de Exchange Online mediante SMTP DANE.

Exchange Online genera este código de error cuando el dominio de destino indica su DNSSEC-authentic, pero Exchange Online no puede comprobarlo como DNSSEC-authentic. Esta sección no es completa para solucionar problemas de DNSSEC y se centra en escenarios en los que los dominios pasaron anteriormente la autenticación DNSSEC, pero no ahora.

Nota:

Exchange Online también genera este código de error si recibe una respuesta SERVFAIL de un servidor DNS en una consulta TLSA para el dominio de destino.

Después de recibir el mensaje:

  1. Si usa un proveedor dns, como GoDaddy, alerte al proveedor de DNS del error para que puedan trabajar en la solución de problemas y el cambio de configuración.
  2. Si va a administrar su propia infraestructura DNSSEC, muchas configuraciones incorrectas de DNSSEC pueden generar este mensaje de error. Compruebe si hay estos problemas comunes si la zona ha pasado previamente la autenticación DNSSEC:
    1. Cadena de confianza rota, cuando la zona primaria contiene un conjunto de registros DS que apuntan a algo que no existe en la zona secundaria. Estos punteros por registros DS pueden dar lugar a que la zona secundaria se marque como falsa mediante la validación de solucionadores.
      • Para resolverlo, revise los identificadores de clave de RRSIG del dominio secundario y asegúrese de que coinciden con los identificadores de clave de los registros DS publicados en la zona primaria.
    2. El registro de recursos de RRSIG para el dominio no es válido, ha expirado o su período de validez no ha comenzado.
      • Para resolverlo, genere nuevas firmas para el dominio mediante intervalos de tiempo válidos.

Al enviar un correo electrónico saliente, si el dominio receptor tiene DNSSEC habilitado, Exchange Online consultas de registros TLSA asociados a entradas MX en el dominio. Si no se publica ningún registro TLSA, la respuesta a la búsqueda TLSA debe ser NOERROR (no hay registros de tipo solicitado para este dominio) o NXDOMAIN (no hay ningún dominio de este tipo). DNSSEC requiere esta respuesta si no se publica ningún registro TLSA; de lo contrario, Exchange Online interpreta la falta de respuesta como un error SERVFAIL. Según RFC 7672, una respuesta de SERVFAIL no es confiable; Por lo tanto, el dominio de destino produce un error en la validación de DNSSEC. Exchange Online aplaza este correo electrónico con el siguiente error:

450 4.7.324 dnssec-invalid: Destination domain returned invalid DNSSEC records

Si el remitente del correo electrónico informa de la recepción del mensaje

Si usa un proveedor dns, como GoDaddy, alerte al proveedor de DNS del error para que pueda solucionar la respuesta DNS. Si va a administrar su propia infraestructura DNSSEC, el problema podría ser con el propio servidor DNS o con la red.

preguntas más frecuentes

Como cliente Exchange Online, ¿puedo dejar de usar DNSSEC y DANE?

Creemos firmemente que DNSSEC y DANE aumentan significativamente la seguridad de nuestro servicio y benefician a todos nuestros clientes. Durante el último año, hemos trabajado diligentemente para reducir el riesgo y la gravedad del posible impacto que esta implementación podría tener para los clientes de Microsoft 365. Supervisamos y realizamos un seguimiento activo de la implementación para garantizar que el impacto negativo se minimice a medida que se implementa. Por este motivo, las excepciones de nivel de inquilino o la exclusión no están disponibles. Si experimenta algún problema relacionado con la habilitación de DNSSEC y DANE, los diferentes métodos para investigar los errores anotados en este documento le ayudan a identificar el origen del error. En la mayoría de los casos, el problema es con la parte de destino externa y debe comunicar a estos asociados empresariales que necesitan configurar correctamente DNSSEC y DANE para recibir correo electrónico de Exchange Online mediante estos estándares.

¿Cómo se relaciona DNSSEC con DANE?

DNSSEC agrega una capa de confianza a la resolución DNS mediante la aplicación de la infraestructura de clave pública para garantizar que los registros devueltos en respuesta a una consulta DNS sean auténticos. DANE garantiza que el servidor de correo receptor sea el servidor de correo legítimo y esperado para el registro MX auténtico.

¿Cuál es la diferencia entre MTA-STS y DANE para SMTP?

DANE y MTA-STS cumplen el mismo propósito, pero DANE requiere DNSSEC para la autenticación DNS, mientras que MTA-STS se basa en entidades de certificación.

¿Por qué tls oportunista no es suficiente?

TLS oportunista cifra la comunicación entre dos puntos de conexión si ambos aceptan admitirla. Sin embargo, incluso si TLS cifra la transmisión, un dominio se puede suplantar durante la resolución DNS de modo que apunte al punto de conexión de un actor malintencionado en lugar del punto de conexión real para el dominio. Esta suplantación es una brecha en la seguridad del correo electrónico que MTA-STS y SMTP DANE con dirección DNSSEC.

¿Por qué DNSSEC no es suficiente?

DNSSEC no es totalmente resistente a los ataques man-in-the-middle y a los ataques de degradación (de TLS a texto no cifrado) para escenarios de flujo de correo. La adición de MTA-STS y DANE junto con DNSSEC proporciona un método de seguridad completo para frustrar los ataques MITM y de degradación.

Recursos adicionales

  • Last updated on