Compartir a través de

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

  • Artículo

El protocolo SMTP es el protocolo principal que se usa para transferir mensajes entre servidores de correo y, 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. Se usa normalmente de forma oportunista en lugar de como requisito, dejando mucho tráfico de correo electrónico en texto no cifrado, vulnerable a la interceptación por parte de actores nefastos. Además, SMTP determina las direcciones IP de los servidores de destino a través de la infraestructura dns pública, que es susceptible a ataques de suplantación de identidad y ataques de tipo "Man in the Middle" (MITM). Esta vulnerabilidad ha llevado a crear 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 SMTP RFC 7672 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 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 que se intente realizar 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 para 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 la entrada o 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 volverá a intentar todo el proceso de validación a partir de una consulta DNS para el mismo dominio de destino de nuevo después de 15 minutos y, después, 15 minutos después, cada hora durante las siguientes 24 horas. Si la autenticación sigue generando un error después de 24 horas de reintento, el mensaje expirará y se generará un NDR con detalles de error y se enviará al remitente.

¿Cuáles son los componentes de DANE?

Registro de recursos TLSA

El registro de autenticación TLS (TLSA) se usa para asociar el certificado X.509 o el valor de clave pública de un servidor con el nombre de dominio que contiene el registro. Los registros TLSA solo pueden ser de confianza si DNSSEC está habilitado en el dominio. Si usa un proveedor de DNS para hospedar el dominio, dnssec puede ser una configuración que se ofrece al configurar un dominio con ellos. Para obtener más información sobre la firma de zona DNSSEC, visite este vínculo: Información general de DNSSEC | Microsoft Docs.

Registro TLSA de ejemplo:

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

Hay cuatro campos configurables únicos para el tipo de registro TLSA:

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 realizará 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 coincidiría 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 se coincidirían con la clave pública del certificado de servidor de destino y el algoritmo con el que se identifica la clave pública que se va a usar.

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 está establecido en "1", haría 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", haría 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, se recomienda un registro TLSA compuesto por 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 diagrama de flujo siguiente, 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 señaló compatibilidad con DNSSEC, pero uno o más registros se devolvieron como 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. Debe haber agregado el dominio como "Dominio aceptado" y el estado del dominio debe ser "Correcto" en el Centro de Administración de Microsoft 365. En la 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, debe trabajar estrechamente con el administrador de Exchange Online para asegurarse de que los cambios se llevan a cabo correctamente.
  2. Para recibir todas las ventajas de seguridad de la característica, asegúrese de que ha habilitado DNSSEC para su dominio.
  3. Debe tener acceso a Exchange Online PowerShell y a los permisos para ejecutar los cmdlets descritos en Exchange Online PowerShell.
  4. Si se hace referencia al dominio que desea proteger con EL DANE SMTP de entrada con DNSSEC en cualquier configuración de smarthost o en cualquier conector, debe cambiar el nombre de smarthost a tenantname.mail.protection.outlook.com antes de seguir los pasos.

Nota:

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

Advertencia

Si desea configurar SMTP DANE de entrada con DNSSEC para el "Dominio aceptado" contoso.comy sus asociados empresariales usan conectores para el contoso-com.mail.protection.outlook.com punto de conexión, debe trabajar con sus asociados para que actualicen sus conectores para hacer referencia al tenantname.onmicrosoft.com punto de conexión o al tenantname.mail.protection.outlook.com punto de conexión, antes de configurar SMTP DANE entrante con DNSSEC. De lo contrario, se produce un error en el correo de los conectores de los asociados empresariales después de completar la habilitación. Después de completar la habilitación, los asociados pueden usar el nuevo contoso-com.<random>.mx.microsoft punto de conexión para volver a establecer el conector original.

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 "3600 segundos" o "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 3600 segundos o 1 hora antes de cambiarla, debe esperar "1 hora" antes de continuar.

  3. Para el dominio para el que desea habilitar SMTP DANE con DNSSEC, primero debe habilitar 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 enviará 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 que 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 esperado, no es necesario continuar siguiendo los pasos siguientes. 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 las TTL en el registro MX heredado han expirado, una salida correcta tendría 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 haya aprovisionado 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 puedan validarse. Siempre que 1 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 se configuraron 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: los clientes que usan 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 podrán 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. Los clientes de esta configuración tendrían que configurar SMTP DANE entrante con DNSSEC mediante Exchange PowerShell.
  4. Otra integración de terceros con el flujo de correo: hay clientes para 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. El tercero NO DEBE usar el nombre de host del registro MX anterior:> contoso-com.mail.protection.outlook.com como Exchange Online eliminará el registro A aproximadamente en un plazo de 2 días (48 horas) después de la habilitación de la característica una vez que lleguemos a disponibilidad general.
  5. Dominios totalmente delegados: los dominios hospedados por Microsoft y que usan la delegación de NS para que los servidores de nombres de Microsoft sean autoritativos para el dominio se admiten con EL DANE SMTP 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 ha comprobado 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 ha agregado 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. Actualmente no se admiten.
    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, hemos detectado que el dominio no se ha agregado a Exchange Online. Si cree que ya ha agregado este dominio a Exchange Online, vuelva a intentar ejecutar el cmdlet, ya que podría tratarse de un problema transitorio.
    Acciones que realizar: vuelva a intentar el cmdlet. Si continúa con errores, 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, hemos detectado que el dominio se ha agregado a Exchange Online pero no se ha comprobado.
    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, recibimos 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, recibimos 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 pudimos encontrar un registro MX que se resolviera 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 coincidió con el esperado".
    Causa: Durante la validación MX, no hemos encontrado 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, encontramos 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, hemos detectado que el registro MX de prioridad más alta no era el registro MX esperado.
    Acciones que debe realizar: si ya ha completado 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, hemos encontrado un registro MX para el dominio que no coincide con el registro MX esperado.
    Acciones que realizar: si ya ha completado los pasos del 1 al 5 de Configuración de SMTP DANE entrante con DNSSEC, complete el paso 6 mediante la eliminación del registro MX heredado.

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

  11. Mensaje: "EX007: No se encontró el registro MX".
    Causa: Durante la validación MX, no hemos encontrado 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, hemos detectado que el registro MX esperado tiene la prioridad incorrecta.
    Acciones que se deben realizar: establezca el registro MX (que contiene el valor devuelto al ejecutar Enable-DnssecForVerifiedDomain o Get-DnssecStatusForVerifiedDomain) como prioridad 0.

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

  14. Mensaje: "EX010: Error desconocido al buscar registros MX en el dominio [{dominio}]."
    Causa: durante la validación MX, se ha producido 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 hemos encontrado 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 hemos encontrado 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 pudimos encontrar el valor mx que coincida 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 3 escenarios clave para los problemas de flujo de correo una vez que se ha habilitado 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, error en la mitigación de las 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 la deshabilitación de DNSSEC no resuelve el problema, puede ser un problema con el valor MX.

  2. Una vez que haya deshabilitado DNSSEC en el dominio a través del proveedor DNS, abra una incidencia de soporte técnico con el proveedor dns para determinar cómo volver a habilitar DNSSEC de forma segura para su dominio.

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 será:

    <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 MX creado en el paso 5 funciona.

    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. Esta seguridad de correo electrónico mejorada es algo que hemos creado para usted y está activado de forma predeterminada para todos los clientes Exchange Online y se usa cuando el dominio de destino anuncia 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. Los errores serán visibles 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 de 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 mostrarán 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 la dirección de correo electrónico de destino se especificó correctamente.
  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

Se debe presentar un certificado X.509 válido que no haya expirado al servidor de correo electrónico de envío. 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 haya devuelto un registro TLSA auténtico de DNSSEC. Hay muchos escenarios durante la validación dane que se producen después de que se haya devuelto el registro que puede dar lugar a que se genere el código. Microsoft está trabajando activamente en los escenarios cubiertos por este código de error, de modo 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 se espera según el registro TLSA auténtico.
  2. El registro TLSA auténtico está mal configurado.
  3. Se está atacando el dominio de destino.
  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

Este código de error se genera cuando el dominio de destino indicaba que era DNSSEC-authentic, pero Exchange Online no pudo 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, hay dos métodos que un administrador de un dominio receptor puede usar 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 necesita agregar un registro TXT en los registros DNS de su dominio que incluya la dirección de correo electrónico o el URI al que desea que se envíen los informes. Exchange Online enviará informes TLS-RPT en formato JSON.

Los datos de la tabla siguiente son 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 hará 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.

Cuando se solucionan errores, se pueden generar 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 de 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 mostrarán 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. Servidor de correo con el que el Analizador de conectividad remota está probando la conexión. Por lo general, hay dos escenarios que generan este código:

  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 puede indicar que el servidor de correo que usa para recibir correo no admite STARTTLS y es posible que tenga que actualizar a uno que lo haga 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.

Se debe presentar un certificado X.509 válido que no haya expirado al servidor de correo electrónico de envío. 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 haya comprobado la compra, puede descargar 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 y solo se puede generar después de que se haya devuelto un registro TSLA auténtico de DNSSEC. Sin embargo, hay muchos escenarios durante la validación dane que se producen después de que se haya devuelto el registro que puede dar lugar a que se genere el código. Microsoft está trabajando activamente en los escenarios cubiertos por este código de error, de modo 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 registro TLSA auténtico está mal configurado.
  2. El certificado aún no es válido o configurado para un período de tiempo futuro.
  3. El dominio de destino está siendo atacado.
  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 al que está asociado.
  2. Identifique el registro TLSA asociado al servidor de correo identificado.
  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 han incluido en el registro TLSA.
    1. Si tiene que realizar actualizaciones en 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 identificado.
  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 haya comprobado 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.

Este código de error se genera cuando el dominio de destino indica que es DNSSEC-authentic, pero Exchange Online no puede comprobarlo como DNSSEC-authentic. Esta sección no será 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:

Este código de error también se genera si Exchange Online recibe la respuesta SERVFAIL del servidor DNS en la consulta TLSA para el dominio de destino.

Después de recibir el mensaje:

  1. Si usa un proveedor dns, por ejemplo 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, hay muchas configuraciones incorrectas de DNSSEC que pueden generar este mensaje de error. Algunos problemas comunes para comprobar si la zona estaba pasando 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 de los dominios secundarios 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.

Cuando se envía un correo electrónico saliente, si el dominio receptor tiene DNSSEC habilitado, se consultan los registros TLSA asociados a las 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. A continuación, este correo electrónico se aplaza 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, por ejemplo, GoDaddy, alerte al proveedor dns del error para que pueda solucionar la respuesta DNS. Si va a administrar su propia infraestructura DNSSEC, podría tratarse de un problema con el propio servidor DNS o con la red.

preguntas más frecuentes

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

Creemos firmemente que DNSSEC y DANE aumentarán significativamente la posición de seguridad de nuestro servicio y beneficiarán a todos nuestros clientes. Hemos trabajado diligentemente durante el último año para reducir el riesgo y la gravedad del posible impacto que esta implementación podría tener para los clientes de Microsoft 365. Supervisaremos y realizaremos un seguimiento activo de la implementación para garantizar que el impacto negativo se minimice a medida que se implemente. Por este motivo, las excepciones de nivel de inquilino o la exclusión no estarán disponibles. Si experimenta algún problema relacionado con la habilitación de DNSSEC o DANE, los diferentes métodos para investigar los errores anotados en este documento le ayudarán a identificar el origen del error. En la mayoría de los casos, el problema será con la parte de destino externa y deberá comunicarse con 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 cifrará la comunicación entre dos puntos de conexión si ambos aceptan admitirla. Sin embargo, incluso si TLS cifra la transmisión, un dominio podría suplantarse 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 se soluciona mediante la implementación de MTA-STS o SMTP DANE con 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.

Buscar y corregir problemas después de agregar el dominio o los registros DNS

Introducción a DNSSEC | Microsoft Docs

Uso de DMARC para validar el correo electrónico y los pasos de instalación: Office 365 | Microsoft Docs

Cómo usar DKIM para el correo electrónico en el dominio personalizado: Office 365 | Microsoft Docs

Cómo el marco de directivas de remitente (SPF) evita la suplantación de identidad: Office 365 | Microsoft Docs

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

rfc8461 (ietf.org)