Como funciona a Autenticação de Entidades Nomeadas (DANE) baseada em DNS do SMTP

Artigo
08/11/2023

O protocolo SMTP é o protocolo main 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 pelo SMTP. É comumente usado oportunistamente em vez de como um requisito, deixando muito tráfego de email em texto claro, 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 falsificação e ataques do MITM (Homem no Meio). Essa vulnerabilidade levou a que muitos novos padrões fossem criados para aumentar a segurança para enviar e receber email, um desses padrões é a Autenticação de Entidades Nomeadas (DANE) baseada em DNS.

O DANE para SMTP RFC 7672 usa a presença de um registro TLSA (Autenticação de Segurança de Camada de Transporte) no registro DNS de um domínio definido para sinalizar um domínio e seus servidores de email dão suporte a DANE. Se não houver nenhum registro TLSA presente, a resolução DNS para o fluxo de email funcionará normalmente sem que nenhuma verificação DANE seja tentada. O registro TLSA sinaliza com segurança o suporte do TLS e publica a política DANE para o domínio. Portanto, o envio de servidores de email pode autenticar com êxito servidores de email de recebimento legítimos usando o DANE SMTP. Essa autenticação torna-a resistente a ataques de downgrade e MITM. O DANE tem dependências diretas no DNSSEC, que funciona assinando digitalmente registros para pesquisas DNS usando criptografia de chave pública. As verificações 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 autênticos.

Depois que os registros de recursos relacionados a MX, A/AAAA e DNSSEC para um domínio forem retornados ao resolvedor recursivo DNS como autentica DNSSEC, o servidor de email de envio pedirá o registro TLSA correspondente à entrada ou entradas do host MX. Se o registro TLSA estiver presente e se provar autenticado usando outro marcar DNSSEC, o resolvedor recursivo DNS retornará o registro TLSA para o servidor de email de envio.

Depois que o registro TLSA autêntico é recebido, o servidor de email de envio estabelece uma conexão SMTP com o host MX associado ao registro TLSA autêntico. 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 que 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 tiver suporte pelo servidor de destino, 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 e, em seguida, 15 minutos depois disso, 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 NDR com detalhes de erro será gerada e enviada ao remetente.

Dica

Se você não for um cliente E5, use a avaliação de soluções do Microsoft Purview de 90 dias para explorar como recursos adicionais do Purview podem ajudar sua organização a gerenciar as necessidades de segurança e conformidade de dados. Comece agora no hub de avaliações portal de conformidade do Microsoft Purview. Saiba mais sobre os termos de inscrição e avaliação.

Quais são os componentes do DANE?

Registro de recursos TLSA

O registro TLSA (Autenticação TLSA) é 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, o DNSSEC poderá ser uma configuração oferecida ao configurar um domínio com eles. Para saber mais sobre a assinatura da zona DNSSEC, visite este link: Visão geral do DNSSEC | Microsoft Docs.

Exemplo de registro TLSA:

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

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

Valor	Acrônimo	Descrição
0¹	PKIX-TA	O certificado usado é a AC pública de âncora de confiança da cadeia de confiança X.509.
11	PKIX-EE	Certificado verificado é o servidor de destino; As verificações 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 somente ao certificado do servidor de destino.

¹ Exchange Online segue as diretrizes de implementação do 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 o 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 não executará as etapas de validação DANE para 0 ou 1 ao enviar o email. Em vez disso, devido à presença de um registro TLSA, 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 descartando o email e gerando um NDR se o servidor de email de destino não der suporte ao TLS.

No registro TLSA de exemplo, o Campo de Uso de Certificado é definido como '3', portanto, os Dados de Associação de Certificados ('abc123... xyz789') seria correspondido somente ao 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 do assunto)	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 Certificados 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 tipo correspondente: indica o formato em que o certificado será representado no registro TLSA.

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

No registro TLSA de exemplo, o Campo de Tipo Correspondente é definido como '1' para que os Dados de Associação de Certificados sejam um hash SHA-256 das Informações de Chave Pública do Assunto do certificado do servidor de destino

Dados da Associação de Certificados: especifica os dados de certificado usados para correspondência com o certificado do servidor de destino. Esses dados dependem do valor campo seletor e do valor de tipo correspondente.

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

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

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

Como Exchange Online clientes podem usar a entrada do SMTP DANE?

Atualmente, o DANE SMTP de entrada não tem suporte para Exchange Online. O suporte para DANE SMTP de entrada estará disponível em um futuro próximo.

Qual é a configuração de registro TLSA recomendada?

De acordo com as diretrizes de implementação do RFC para O DANE do SMTP, um registro TLSA composto pelo campo Uso de 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 O DANE do SMTP

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

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

O domínio de destino sinalizou suporte a DNSSEC, mas um ou mais registros foram retornados como inautênticos.
Todos os registros MX para o domínio de destino têm registros TLSA e nenhum dos certificados do servidor de destino corresponde ao esperado pelos dados de registro TSLA ou uma conexão TLS não tem suporte pelo servidor de destino.

Tecnologia	Informações Adicionais
O Agente de Transferência de Email – MTA-STS (Strict Transport Security) ajuda a impedir o downgrade e os 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 ao TLS e o que fazer quando o TLS não pode ser negociado, por exemplo, interromper a transmissão.	Mais informações sobre o próximo suporte da Exchange Online para o MTA-STS de entrada e saída serão publicadas ainda este 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 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 de Mensagens, Relatórios e Conformidade) 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 de seu domínio.	Use DMARC para validar o email, etapas de configuração

Solução de problemas ao enviar emails com o DANE do SMTP

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 ficarão visíveis em:

O portal do Exchange Administração Center por meio da exibição Detalhes do Rastreamento de Mensagens.
NDRs gerados quando uma mensagem não é enviada devido a uma falha DANE ou DNSSEC.
Ferramenta analisador de conectividade remota Microsoft Remote Connectivity Analyzer.

Código NDR	Descrição
4/5.7.321	starttls sem suporte: 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: a validação DANE com falha de domínio.
4/5.7.324	dnssec-invalid: o domínio de destino retornou registros DNSSEC inválidos.

Observação

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

4/5.4.312 DNS query failed

Estamos trabalhando ativamente para remediar 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 DNSSEC ou um problema DNS diferente.

Solução de problemas 4/5.7.321 starttls sem suporte

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

Verifique se o endereço de email de destino foi inserido corretamente.
Alerte o administrador de email de destino 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 o TLS.
Tente novamente enviar o email e examine os Detalhes do Rastreamento de Mensagens para a mensagem no portal do Exchange Administração Center.

Solução de problemas 4/5.7.322 certificado 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:

Alerte o administrador de email de destino que você recebeu esse código de erro e forneça a cadeia de caracteres de código de erro.
Permitir tempo para 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 novamente enviar o email e examinar os Detalhes do Rastreamento de Mensagens para a mensagem no portal do Exchange Administração Center.

Solução de problemas 4/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 DNSSEC tiver sido retornado. Há muitos cenários durante a validação DANE que ocorrem após o retorno do registro que podem resultar na geração do código. A Microsoft está trabalhando ativamente nos cenários abordados por esse código de erro, de modo 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:

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

Depois de receber a mensagem:

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.
Permitir tempo para que o administrador de email de destino examine sua configuração DANE e a validade do certificado do servidor de email. Em seguida, tente novamente enviar o email e examinar os Detalhes do Rastreamento de Mensagens para a mensagem no portal do Exchange Administração Center.

Solução de problemas 4/5.7.324 dnssec-invalid

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

Depois de receber a mensagem:

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.
Permitir tempo para que o administrador de email de destino examine a configuração DNSSEC de seu domínio. Em seguida, tente novamente enviar o email e examinar os Detalhes do Rastreamento de Mensagens para a mensagem no portal do Exchange Administração Center.

Solução de problemas ao receber emails com o DANE SMTP

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

Adotar o SMTP TLS-RPT (Relatório de Segurança da Camada de Transporte) introduzido no RFC8460
Usar a ferramenta Analisador de Conectividade Remota Microsoft Remote Connectivity Analyzer

O TLS-RPT https://datatracker.ietf.org/doc/html/rfc8460 é um mecanismo de relatório para que os remetentes forneçam detalhes aos administradores de domínio de destino sobre sucessos 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ê gostaria que os relatórios fossem enviados. Exchange Online enviará relatórios TLS-RPT no formato JSON.

Registro de exemplo:

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

Quando os erros estão sendo solucionados, os códigos de erro abaixo podem ser gerados:

Código NDR	Descrição
4/5.7.321	starttls sem suporte: 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: a validação DANE com falha de domínio.
4/5.7.324	dnssec-invalid: o domínio de destino retornou registros DNSSEC inválidos.

Observação

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

4/5.4.312 DNS query failed

Solução de problemas 4/5.7.321 starttls sem suporte

Observação

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

Esse erro 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:

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

Depois de receber a mensagem:

Verifique o endereço de email.
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.
Verifique a configuração do servidor de email para verificar se ele está configurado para ouvir o tráfego SMTP (geralmente portas 25 e 587).
Aguarde alguns minutos e tente novamente o teste com a ferramenta Analisador de Conectividade Remota.
Se ele ainda falhar, tente remover o registro TLSA e executar o teste com a ferramenta Analisador de Conectividade Remota novamente.
Se não houver falhas, essa mensagem 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 para usar o DANE.

Solução de problemas 4/5.7.322 certificado expirado

Observação

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

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.
Entre no site do provedor de certificados.
Selecione o certificado expirado e siga as instruções para renovar e pagar pela renovação.
Depois que o provedor tiver verificado a compra, você poderá baixar um novo certificado.
Instale o certificado renovado em seu servidor de email associado.
Atualize o registro TLSA associado do servidor de email com os dados do novo certificado.
Depois de aguardar um tempo apropriado, tente novamente o teste com a ferramenta Analisador de Conectividade Remota.

Solução de problemas 4/5.7.323 tlsa-invalid

Observação

Essas etapas são para administradores de email que solucionam problemas ao receber emails de 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 DNSSEC tiver sido retornado. Mas, há muitos cenários durante a validação DANE que ocorrem após o retorno do registro que podem resultar na geração do código. A Microsoft está trabalhando ativamente nos cenários abordados por esse código de erro, de modo 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:

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

Depois de receber a mensagem:

Verifique o IP associado à instrução de erro para identificar o servidor de email ao qual ele está associado.
Identifique o registro TLSA associado ao servidor de email identificado.
Verifique a configuração do registro TLSA para garantir que ele sinalize o remetente para executar as verificações DANE preferidas e que os dados de certificado corretos foram incluídos no registro TLSA.
1. Se você precisar fazer atualizações no registro de discrepâncias, aguarde alguns minutos e execute novamente o teste com a ferramenta Analisador de Conectividade Remota.
Localize o certificado no servidor de email identificado.
Verifique a janela de tempo para a qual o certificado é válido. Se ele estiver definido para iniciar a validade em uma data futura, ele precisará ser renovado para a data atual.
1. Entre 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 4/5.7.324 dnssec-invalid

Observação

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

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

Depois de receber a mensagem:

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

Observação

Esse código de erro também será gerado se Exchange Online receber a resposta SERVFAIL do servidor DNS na consulta TLSA para o domínio de destino.

Quando um email de saída está sendo enviado, se o domínio de recebimento tiver DNSSEC habilitado, consultaremos registros TLSA associados a entradas MX no domínio. Se nenhum registro TLSA for publicado, a resposta à pesquisa TLSA deverá ser NOERROR (nenhum registro de tipo solicitado para esse domínio) ou NXDOMAIN (não existe esse domínio). O DNSSEC exigirá essa resposta se nenhum registro TLSA for publicado; caso contrário, Exchange Online interpreta a falta de resposta como um erro SERVFAIL. De acordo com o RFC 7672, uma resposta SERVFAIL não é confiável; portanto, o domínio de destino falha na validação DNSSEC. Esse email é então adiado com o seguinte erro:

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

Se o remetente de email relatar o recebimento da mensagem

Se você estiver usando um provedor DNS, por exemplo, GoDaddy, alerte seu provedor DNS sobre o erro para que eles possam solucionar problemas da resposta DNS. Se você estiver gerenciando sua própria infraestrutura DNSSEC, pode ser um problema com o próprio servidor DNS ou com a rede.

Perguntas frequentes

Como um cliente Exchange Online, posso optar por não usar 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 com diligência ao longo do último ano para reduzir o risco e a gravidade do potencial impacto que essa implantação pode ter para os clientes do Microsoft 365. Estaremos monitorando e acompanhando a implantação ativamente para garantir que o impacto negativo seja minimizado à medida que ela for implementada. Por causa disso, exceções no nível do locatário ou opt-out não estarão disponíveis. Se você tiver problemas relacionados à habilitação do DNSSEC e/ou DANE, os diferentes métodos para investigar falhas anotadas 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 de Exchange Online usando esses padrões.

Como o DNSSEC se relaciona com o DANE?

O DNSSEC adiciona uma camada de confiança à resolução DNS aplicando a infraestrutura de chave pública para garantir que os registros retornados em resposta a uma consulta DNS sejam autênticos. O DANE garante que o servidor de email receptor é o servidor de email legítimo e esperado para o registro MX autêntico.

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

DANE e MTA-STS servem para o mesmo propósito, mas o DANE requer DNSSEC para autenticação DNS, enquanto o MTA-STS depende das autoridades de certificado.

Por que o TLS oportunista não é suficiente?

O TLS oportunista criptografará 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 aponte para o ponto de extremidade de um ator mal-intencionado em vez do ponto de extremidade real para o domínio. Essa falsificação é uma lacuna na segurança de email que é endereçada implementando MTA-STS e/ou SMTP DANE com DNSSEC.

Por que o DNSSEC não é suficiente?

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

Links adicionais

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

Visão geral do DNSSEC | Microsoft Docs

Use o DMARC para validar o email, as etapas de instalaçã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)

Como funciona a Autenticação de Entidades Nomeadas (DANE) baseada em DNS do SMTP