Como funciona a autenticação baseada em DNS SMTP de entidades nomeadas (DANE)

O protocolo SMTP é o principal protocolo usado para transferir mensagens entre servidores de email e, por padrão, não é seguro. O protocolo TLS (Transport Layer Security) foi introduzido anos atrás para dar suporte à transmissão criptografada de mensagens por SMTP. Normalmente, ele é usado oportunistamente em vez de como um requisito, deixando muito tráfego de email em texto não criptografado, vulnerável à interceptação por atores nefastos. Além disso, o SMTP determina os endereços IP dos servidores de destino por meio da infraestrutura dns pública, que é suscetível a ataques de FALSIFICAÇÃO e MITM (Man-in-the-Middle). Isso levou a muitos novos padrões que estão sendo criados para aumentar a segurança de envio e recebimento de emails, um deles é a Autenticação baseada em DNS de Entidades Nomeadas (DANE).

O DANE para SMTP RFC 7672 usa a presença de um registro TLSA (Autenticação de Segurança de Camada de Transporte) no conjunto de registros DNS de um domínio para sinalizar um domínio e seus servidores de email dão suporte ao DANE. Se não houver nenhum registro TLSA presente, a resolução DNS para o fluxo de email funcionará como de costume sem nenhuma tentativa de verificações de DANE. O registro TLSA sinaliza com segurança o suporte ao TLS e publica a política DANE para o domínio. Portanto, o envio de servidores de email pode autenticar com êxito os servidores de recebimento legítimos de email usando o SMTP DANE. Isso o torna resistente a ataques de downgrade e MITM. O DANE tem dependências diretas no DNSSEC, que funciona assinando digitalmente registros para pesquisas de DNS usando criptografia de chave pública. As verificações de DNSSEC ocorrem em resolvedores DNS recursivos, os servidores DNS que fazem consultas DNS para clientes. O DNSSEC garante que os registros DNS não sejam adulterados e sejam autenticados.

Depois que os registros de recursos relacionados a MX, A/AAAA e DNSSEC para um domínio forem retornados ao resolvedor recursivo DNS como DNSSEC autenticado, o servidor de email de envio solicitará o registro TLSA correspondente à entrada ou às entradas do host MX. Se o registro TLSA estiver presente e autenticado comprovadamente usando outra verificação DNSSEC, o resolvedor recursivo dns retornará o registro TLSA para o servidor de email de envio.

Depois de receber o registro TLSA autenticado, o servidor de email de envio estabelece uma conexão SMTP com o host MX associado ao registro TLSA autenticado. O servidor de email de envio tentará configurar o TLS e comparar o certificado TLS do servidor com os dados no registro TLSA para validar se o servidor de email de destino conectado ao remetente é o servidor de email de recebimento legítimo. A mensagem será transmitida (usando TLS) se a autenticação for bem-sucedida. Quando a autenticação falhar ou se o TLS não for compatível com o servidor de destino, o Exchange Online repetirá todo o processo de validação começando com uma consulta DNS para o mesmo domínio de destino novamente após 15 minutos, depois 15 minutos depois disso e, em seguida, a cada hora pelas próximas 24 horas. Se a autenticação continuar falhando após 24 horas de repetição, a mensagem expirará e uma notificação de falha com detalhes de erro será gerada e enviada ao remetente.

Quais são os componentes do DANE?

Registro de recurso TLSA

O registro TLSA (Autenticação TLS) é usado para associar o certificado X.509 de um servidor ou o valor da chave pública ao nome de domínio que contém o registro. Os registros TLSA só poderão ser confiáveis se o DNSSEC estiver habilitado em seu domínio. Se você estiver usando um provedor DNS para hospedar seu domínio, essa pode ser uma configuração oferecida ao configurar um domínio com eles. Para saber mais sobre a assinatura de zona DNSSEC, visite este link: Visão geral do dnssec | Microsoft Docs.

Exemplo de registro TLSA:

Exemplo de registro TLSA

Há quatro campos configuráveis exclusivos para o tipo de registro TLSA:

Campo uso do certificado: especifica como o servidor de email de envio deve verificar o certificado do servidor de email de destino.

Valor Acrônimo Descrição
01 PKIX-TA O certificado usado é a AC pública de âncora de confiança da cadeia de confiança X.509.
11 PKIX-EE O certificado verificado é o servidor de destino; As verificações de DNSSEC devem verificar sua autenticidade.
2 DANE-TA Use a chave privada do servidor da árvore X.509 que deve ser validada por uma âncora de confiança na cadeia de confiança. O registro TLSA especifica a âncora de confiança a ser usada para validar os certificados TLS para o domínio.
3 DANE-EE Corresponde apenas ao certificado do servidor de destino.

1 Exchange Online seguir as diretrizes de implementação RFC de que os valores de Campo de Uso de Certificado de 0 ou 1 não devem ser usados quando o DANE é implementado com SMTP. Quando um registro TLSA que tem um valor de campo uso de certificado de 0 ou 1 é retornado ao Exchange Online, Exchange Online o tratará como não utilizável. Se todos os registros TLSA forem considerados inutilizáveis, Exchange Online executará as etapas de validação do DANE para 0 ou 1 ao enviar o email. Em vez disso, devido à presença de um registro TLSA, o Exchange Online imporá o uso do TLS para enviar o email, enviando o email se o servidor de email de destino der suporte a TLS ou descartar o email e gerar uma notificação de falha na entrega se o servidor de email de destino não oferecer suporte a TLS.

No registro TLSA de exemplo, o Campo de Uso do Certificado é definido como '3', portanto, os Dados de Associação de Certificado ('abc123... xyz789') seria correspondido somente com o certificado do servidor de destino.

Campo seletor: indica quais partes do certificado do servidor de destino devem ser verificadas.

Valor Acrônimo Descrição
0 Cert Use o certificado completo.
1 SPKI (Informações de Chave Pública da Entidade) Use a chave pública do certificado e o algoritmo com o qual a chave pública é identificada para usar.

No registro TLSA de exemplo, o campo seletor é definido como '1' para que os dados de associação de certificado sejam correspondidos usando a chave pública do certificado do servidor de destino e o algoritmo com o qual a chave pública é identificada para usar.

Campo de Tipo correspondente: indica o formato em que o certificado será representado no registro TLSA.

Valor Acrônimo Descrição
0 Completo Os dados no registro TSLA são o certificado completo ou a SPKI.
1 SHA-256 Os dados no registro TSLA são um hash SHA-256 do certificado ou da SPKI.
2 SHA-512 Os dados no registro TSLA são um hash SHA-512 do certificado ou da SPKI.

No registro TLSA de exemplo, o Campo de Tipo correspondente é definido como '1', portanto, os Dados de Associação de Certificado são um hash SHA-256 das Informações de Chave Pública da Entidade do certificado do servidor de destino

Dados de associação de certificado: especifica os dados de certificado usados para correspondência com o certificado do servidor de destino. Esses dados dependem do valor do Campo do Seletor e do Valor do Tipo correspondente.

No registro TLSA de exemplo, os dados da Associação de Certificados são definidos como 'abc123.. xyz789'. Como o valor do Campo do Seletor no exemplo é definido como '1', ele referenciaria a chave pública do certificado do servidor de destino e o algoritmo identificado para ser usado com ele. E como o valor do campo Tipo de Correspondência no exemplo é definido como '1', ele referenciaria o hash SHA-256 das Informações de Chave Pública da Entidade do certificado do servidor de destino.

Como os Exchange Online podem usar a saída SMTP DANE?

Como um Exchange Online cliente, não há nada que você precise fazer para configurar essa segurança de email aprimorada para seu email de saída. Isso é algo que criamos para você e está ativado por padrão para todos os clientes Exchange Online e é usado quando o domínio de destino anuncia suporte para DANE. Para aproveitar os benefícios de enviar emails com verificações DNSSEC e DANE, comunique-se com seus parceiros de negócios com os quais você troca emails de que eles precisam para implementar DNSSEC e DANE para que eles possam receber emails usando esses padrões.

Como os Exchange Online podem usar a entrada SMTP DANE?

Atualmente, não há suporte para o DANE de SMTP de entrada para Exchange Online. O suporte está previsto para ser lançado no final de 2022.

De acordo com as diretrizes de implementação de RFC para SMTP DANE, um registro TLSA composto pelo campo Uso do Certificado definido como 3, o campo Seletor definido como 1 e o campo Tipo correspondente definido como 1 é recomendado.

Exchange Online fluxo de email com SMTP DANE

O processo de fluxo de email para Exchange Online com sMTP DANE, mostrado no fluxograma abaixo, valida a segurança de registro de domínio e recurso por meio de DNSSEC, suporte TLS no servidor de email de destino e que o certificado do servidor de email de destino corresponde ao esperado com base em seu registro TLSA associado.

Há apenas dois cenários em que uma falha de SMTP DANE resultará no bloqueio do email:

  • O domínio de destino sinalou suporte a DNSSEC, mas um ou mais registros foram retornados como não autenticados.

  • Todos os registros MX para o domínio de destino têm registros TLSA e nenhum dos certificados do servidor de destino corresponde ao que era esperado de acordo com os dados de registro TSLA ou uma conexão TLS não é compatível com o servidor de destino.

Fluxo de email online do Exchange com o SMTP DANE

Tecnologia Informações Adicionais
O Agente de Transferência de Email – Segurança de Transporte Estrita (MTA-STS) ajuda a impedir o downgrade e ataques man-in-the-middle, fornecendo um mecanismo para definir políticas de domínio que especificam se o servidor de email de destino dá suporte a TLS e o que fazer quando o TLS não pode ser negociado, por exemplo, interromper a transmissão. Mais informações sobre Exchange Online suporte futuro da Exchange Online para MTA-STS de entrada e saída serão publicadas posteriormente neste ano.

Exchange Online notícias de transporte do Microsoft Ignite 2020 – Microsoft Tech Community

rfc8461 (ietf.org)
O SPF (Sender Policy Framework) usa informações de IP para garantir que os sistemas de email de destino confiem em mensagens enviadas de seu domínio personalizado. Como o SPF (Sender Policy Framework) impede a falsificação
O DKIM (DomainKeys Identified Mail) usa informações de certificado X.509 para garantir que os sistemas de email de destino confiem em mensagens enviadas de saída de seu domínio personalizado. Use o DKIM para e-mails em seu domínio personalizado
A DMARC ( Autenticação, Relatório e Conformidade de Mensagens) baseada em domínio funciona com o Sender Policy Framework e o DomainKeys Identified Mail para autenticar remetentes de email e garantir que os sistemas de email de destino confiem em mensagens enviadas do seu domínio. Use DMARC para validar o email, etapas de configuração

Solução de problemas de envio de emails com SMTP DANE

Atualmente, há quatro códigos de erro para DANE ao enviar emails com Exchange Online. A Microsoft está atualizando ativamente essa lista de códigos de erro. Os erros estarão visíveis em:

  1. O portal do Exchange Administração Center por meio da exibição Detalhes do Rastreamento de Mensagens.
  2. NDRs gerados quando uma mensagem não é enviada devido a uma falha DANE ou DNSSEC.
  3. Ferramenta Analisador de Conectividade Remota do Microsoft Remote Connectivity Analyzer.
Código NDR Descrição
5.7.321 starttls-not-supported: o servidor de email de destino deve dar suporte ao TLS para receber emails.
5.7.322 certificado expirado: o certificado do servidor de email de destino expirou.
5.7.323 tlsa-invalid: falha na validação do DANE no domínio.
5.7.324 dnssec inválido: o domínio de destino retornou registros DNSSEC inválidos.

Observação

Atualmente, quando um domínio sinaliza que ele dá suporte a DNSSEC, mas falha nas verificações de DNSSEC, o Exchange Online não gera o erro 4/5.7.324 dnssec inválido. Ele gera um erro DNS genérico:

4/5.4.312 DNS query failed

Estamos trabalhando ativamente para corrigir essa limitação conhecida. Se você receber essa instrução de erro, navegue até o Analisador de Conectividade Remota da Microsoft e execute o teste de validação dane no domínio que gerou o erro 4/5.4.312. Os resultados mostrarão se é um problema de DNSSEC ou um problema de DNS diferente.

Solução de problemas 5.7.321 starttls sem suporte

Isso geralmente indica um problema com o servidor de email de destino. Depois de receber a mensagem:

  1. Verifique se o endereço de email de destino foi inserido corretamente.
  2. Alerte o administrador de email de destino de que você recebeu esse código de erro para que ele possa determinar se o servidor de destino está configurado corretamente para receber mensagens usando TLS.
  3. Tente enviar novamente o email e examine os Detalhes do Rastreamento de Mensagem para a mensagem no portal do Exchange Administração Center.

Solução de problemas de certificado 5.7.322 expirado

Um certificado X.509 válido que não expirou deve ser apresentado ao servidor de email de envio. Os certificados X.509 devem ser renovados após a expiração, normalmente anualmente. Depois de receber a mensagem:

  1. Alerte o administrador de email de destino de que você recebeu esse código de erro e forneça a cadeia de caracteres de código de erro.
  2. Permita que o certificado do servidor de destino seja renovado e o registro TLSA seja atualizado para fazer referência ao novo certificado. Em seguida, tente enviar novamente o email e examine os Detalhes do Rastreamento de Mensagens para a mensagem no portal do Exchange Administração Center.

Solução de problemas 5.7.323 tlsa-invalid

Esse código de erro está relacionado a uma configuração incorreta de registro TLSA e só pode ser gerado depois que um registro TLSA de autenticação DNSSEC tiver sido retornado. Há muitos cenários durante a validação do DANE que ocorrem depois que o registro é retornado que pode resultar na geração do código. A Microsoft está trabalhando ativamente nos cenários cobertos por esse código de erro, para que cada cenário tenha um código específico. Atualmente, um ou mais desses cenários podem causar a geração do código de erro:

  1. O certificado do servidor de email de destino não corresponde ao que é esperado de acordo com o registro TLSA autêntico.
  2. O registro TLSA autêntico é configurado de forma incorreta.
  3. O domínio de destino está sendo atacado.
  4. Qualquer outra falha DANE.

Depois de receber a mensagem:

  1. Alerte o administrador de email de destino de que você recebeu esse código de erro e forneça a cadeia de caracteres de código de erro.
  2. Aguarde até que o administrador de email de destino examine a configuração do DANE e a validade do certificado do servidor de email. Em seguida, tente enviar novamente o email e examine os Detalhes do Rastreamento de Mensagens para a mensagem no portal do Exchange Administração Center.

Solução de problemas 5.7.324 dnssec-invalid

Esse código de erro é gerado quando o domínio de destino indicou que ele era autenticado por DNSSEC, mas Exchange Online não foi capaz de confirmá-lo como DNSSEC-authentic.

Depois de receber a mensagem:

  1. Alerte o administrador de email de destino de que você recebeu esse código de erro e forneça a cadeia de caracteres de código de erro.
  2. Permita que o administrador de email de destino examine a configuração de DNSSEC de seu domínio. Em seguida, tente enviar novamente o email e examine os Detalhes do Rastreamento de Mensagens para a mensagem no portal do Exchange Administração Center.

Solução de problemas de recebimento de emails com o SMTP DANE

Atualmente, há dois métodos que um administrador de um domínio de recebimento pode usar para validar e solucionar problemas de configuração de DNSSEC e DANE para receber emails de Exchange Online usando esses padrões.

  1. Adotar O SMTP TLS-RPT (Transport Layer Security Reporting) introduzido no RFC8460
  2. Usar a ferramenta Analisador de Conectividade Remota do Microsoft Remote Connectivity Analyzer

O TLS-RPT https://datatracker.ietf.org/doc/html/rfc8460 é um mecanismo de relatório para os remetentes fornecerem detalhes aos administradores de domínio de destino sobre êxitos e falhas do DANE e do MTA-STS com esses respectivos domínios de destino. Para receber relatórios TLS-RPT, você só precisa adicionar um registro TXT nos registros DNS do seu domínio que inclua o endereço de email ou o URI para o qual você deseja que os relatórios sejam enviados. Exchange Online enviará relatórios TLS-RPT no formato JSON.

Registro de exemplo:

Registro de exemplo

O segundo método é usar o Analisador de Conectividade Remota da Microsoft Remote Connectivity Analyzer, que pode fazer as mesmas verificações DNSSEC e DANE em relação à configuração de DNS que o Exchange Online fará ao enviar emails para fora do serviço. Essa é a maneira mais direta de solucionar erros em sua configuração para receber emails de Exchange Online usando esses padrões.

Ao solucionar problemas, os códigos de erro abaixo podem ser gerados:

Código NDR Descrição
4/5.7.321 starttls-not-supported: o servidor de email de destino deve dar suporte ao TLS para receber emails.
4/5.7.322 certificado expirado: o certificado do servidor de email de destino expirou.
4/5.7.323 tlsa-invalid: falha na validação do DANE no domínio.
4/5.7.324 dnssec inválido: o domínio de destino retornou registros DNSSEC inválidos.

Observação

Atualmente, quando um domínio sinaliza que ele dá suporte a DNSSEC, mas falha nas verificações de DNSSEC, o Exchange Online não gera o erro 4/5.7.324 dnssec inválido. Ele gera um erro DNS genérico:

4/5.4.312 DNS query failed

Estamos trabalhando ativamente para corrigir essa limitação conhecida. Se você receber essa instrução de erro, navegue até o Analisador de Conectividade Remota da Microsoft e execute o teste de validação dane no domínio que gerou o erro 4/5.4.312. Os resultados mostrarão se é um problema de DNSSEC ou um problema de DNS diferente.

Solução de problemas 5.7.321 starttls sem suporte

Observação

Essas etapas são para administradores de email que solucionam problemas de recebimento de emails Exchange Online usando o SMTP DANE.

Isso geralmente indica um problema com o servidor de email de destino. O servidor de email com o qual o Analisador de Conectividade Remota está testando a conexão. Geralmente, há dois cenários que geram esse código:

  1. O servidor de email de destino não dá suporte à comunicação segura, e a comunicação simples e não criptografada deve ser usada.
  2. O servidor de destino está configurado incorretamente e ignora o comando STARTTLS.

Depois de receber a mensagem:

  1. Verifique o endereço de email.
  2. Localize o endereço IP associado à instrução de erro para que você possa identificar o servidor de email ao qual a instrução está associada.
  3. Verifique a configuração do servidor de email para verificar se ele está configurado para escutar o tráfego SMTP (normalmente, as portas 25 e 587).
  4. Aguarde alguns minutos e repita o teste com a ferramenta Analisador de Conectividade Remota.
  5. Se ele ainda falhar, tente remover o registro TLSA e execute o teste com a ferramenta Analisador de Conectividade Remota novamente.
  6. Se não houver falhas, isso poderá indicar que o servidor de email que você está usando para receber emails não dá suporte a STARTTLS e talvez seja necessário atualizar para um que faça isso para usar o DANE.

Solução de problemas de certificado 5.7.322 expirado

Observação

Essas etapas são para administradores de email que solucionam problemas de recebimento de emails Exchange Online usando o SMTP DANE.

Um certificado X.509 válido que não expirou deve ser apresentado ao servidor de email de envio. Os certificados X.509 devem ser renovados após a expiração, normalmente anualmente. Depois de receber a mensagem:

  1. Verifique o IP associado à instrução de erro para que você possa identificar o servidor de email ao qual ele está associado. Localize o certificado expirado no servidor de email que você identificou.
  2. Faça logon no site do provedor de certificados.
  3. Selecione o certificado expirado e siga as instruções para renovar e pagar pela renovação.
  4. Depois que o provedor tiver verificado a compra, você poderá baixar um novo certificado.
  5. Instale o certificado renovado em seu servidor de email associado.
  6. Atualize o registro TLSA associado do servidor de email com os dados do novo certificado.
  7. Depois de aguardar um período apropriado, repita o teste com a ferramenta Analisador de Conectividade Remota.

Solução de problemas 5.7.323 tlsa-invalid

Observação

Essas etapas são para administradores de email que solucionam problemas de recebimento de emails Exchange Online usando o SMTP DANE.

Esse código de erro está relacionado a uma configuração incorreta de registro TLSA e só pode ser gerado depois que um registro TSLA de autenticação DNSSEC tiver sido retornado. No entanto, há muitos cenários durante a validação do DANE que ocorrem depois que o registro é retornado que pode resultar na geração do código. A Microsoft está trabalhando ativamente nos cenários cobertos por esse código de erro, para que cada cenário tenha um código específico. Atualmente, um ou mais desses cenários podem causar a geração do código de erro:

  1. O registro TLSA autêntico é configurado de forma incorreta.
  2. O certificado ainda não é válido/configurado para uma janela de tempo futura.
  3. O domínio de destino está sendo atacado.
  4. Qualquer outra falha DANE.

Depois de receber a mensagem:

  1. Verifique o IP associado à instrução de erro para identificar o servidor de email ao qual ele está associado.
  2. Identifique o registro TLSA associado ao servidor de email identificado.
  3. Verifique a configuração do registro TLSA para garantir que ele sinalize o remetente para executar as verificações de DANE preferenciais e se os dados corretos do certificado foram incluídos no registro TLSA.
    1. Se você precisar fazer atualizações no registro em caso de discrepâncias, aguarde alguns minutos e execute novamente o teste com a ferramenta Analisador de Conectividade Remota.
  4. Localize o certificado no servidor de email identificado.
  5. Verifique a janela de tempo para a qual o certificado é válido. Se estiver definido para iniciar a validade em uma data futura, ele precisará ser renovado para a data atual.
    1. Faça logon no site do provedor de certificados.
    2. Selecione o certificado expirado e siga as instruções para renovar e pagar pela renovação.
    3. Depois que o provedor tiver verificado a compra, você poderá baixar um novo certificado.
    4. Instale o certificado renovado em seu servidor de email associado.

Solução de problemas 5.7.324 dnssec-invalid

Observação

Essas etapas são para administradores de email que solucionam problemas de recebimento de emails Exchange Online usando o SMTP DANE.

Esse código de erro é gerado quando o domínio de destino indicou que ele é autenticado por DNSSEC, mas Exchange Online não é capaz de confirmá-lo como DNSSEC-authentic. Esta seção não será abrangente para solucionar problemas de DNSSEC e se concentra em cenários em que os domínios anteriormente passaram pela autenticação DNSSEC, mas não agora.

Depois de receber a mensagem:

  1. Se você estiver usando um provedor DNS, por exemplo, o GoDaddy, alerte o provedor DNS sobre o erro para que ele possa trabalhar na solução de problemas e na alteração de configuração.
  2. Se você estiver gerenciando sua própria infraestrutura DNSSEC, há muitas configurações incorretas de DNSSEC que podem gerar essa mensagem de erro. Alguns problemas comuns a serem verificados se a zona estava passando anteriormente a autenticação DNSSEC:
    1. Cadeia de confiança quebrada, quando a zona pai mantém um conjunto de registros DS que apontam para algo que não existe na zona filho. Isso faz com que a zona filho seja marcada como falsa validando resolvedores.
      • Resolva examinando as IDs de chave RRSIG de domínios filho e garantindo que elas correspondam às IDs de chave nos registros DS publicados na zona pai.
    2. O registro de recurso RRSIG para o domínio não é válido, expirou ou seu período de validade não começou.
      • Resolva gerando novas assinaturas para o domínio usando intervalos de tempo válidos.

Perguntas frequentes

Como um Exchange Online cliente, posso recusar o uso de DNSSEC e/ou DANE?

Acreditamos fortemente que o DNSSEC e o DANE aumentarão significativamente a posição de segurança do nosso serviço e beneficiarão todos os nossos clientes. Trabalhamos cuidadosamente no último ano para reduzir o risco e a gravidade do impacto potencial que essa implantação pode ter para os clientes do M365. Vamos monitorar ativamente e acompanhar a implantação para garantir que o impacto negativo seja minimizado à medida que ela for distribuída. Por isso, as exceções no nível do locatário ou a recusa não estarão disponíveis. Se você tiver problemas relacionados à habilitação de DNSSEC e/ou DANE, os diferentes métodos para investigar falhas detectadas neste documento ajudarão você a identificar a origem do erro. Na maioria dos casos, o problema será com a parte de destino externa e você precisará comunicar a esses parceiros de negócios que eles precisam configurar corretamente DNSSEC e DANE para receber emails do Exchange Online usando esses padrões.

Como o DNSSEC está relacionado ao DANE?

O DNSSEC adiciona uma camada de confiança à resolução DNS aproveitando a infraestrutura de chave pública para garantir que os registros retornados em resposta a uma consulta DNS sejam autenticados. O DANE garante que o servidor de email de recebimento seja o servidor de email legítimo e esperado para o registro MX autenticado.

Qual é a diferença entre MTA-STS e DANE para SMTP?

DANE e MTA-STS atendem à mesma finalidade, mas o DANE requer DNSSEC para autenticação DNS, enquanto o MTA-STS depende de autoridades de certificação.

Por que o TLS oportunista não é suficiente?

O TLS oportunista criptografa a comunicação entre dois pontos de extremidade se ambos concordarem em dar suporte a ela. No entanto, mesmo que o TLS criptografe a transmissão, um domínio pode ser falsificado durante a resolução dns, de modo que ele aponte para o ponto de extremidade de um ator mal-intencionado em vez do ponto de extremidade real para o domínio. Essa é uma lacuna na segurança de email que é resolvida pela implementação de MTA-STS e/ou SMTP DANE com DNSSEC.

Por que o DNSSEC não é suficiente?

O DNSSEC não é totalmente resistente a ataques man-in-the-middle e ataques de downgrade (do TLS para texto não criptografado) para cenários de fluxo de email. A adição de MTA-STS e DANE juntamente com DNSSEC fornece um método de segurança abrangente para impedir ataques de MITM e downgrade.

Localizar e corrigir problemas após a adição do seu domínio ou de registros DNS

Visão geral do | DNSSEC Microsoft Docs

Usar o DMARC para validar emails, etapas de configuração – Office 365 | Microsoft Docs

Como usar o DKIM para email em seu domínio personalizado – Office 365 | Microsoft Docs

Como o SPF (Sender Policy Framework) impede a falsificação – Office 365 | Microsoft Docs

Exchange Online notícias de transporte do Microsoft Ignite 2020 – Microsoft Tech Community

rfc8461 (ietf.org)