Como funciona a Autenticação baseada em DNS SMTP de Entidades Nomeadas (DANE)
O protocolo SMTP é o protocolo main utilizado para transferir mensagens entre servidores de correio e não é, por predefinição, seguro. O protocolo TLS (Transport Layer Security) foi introduzido há anos para suportar a transmissão encriptada de mensagens através de SMTP. É geralmente usado oportunisticamente em vez de como um requisito, deixando muito tráfego de e-mail em texto claro, vulnerável à intercepção por actores nefastos. Além disso, o SMTP determina os endereços IP dos servidores de destino através da infraestrutura DNS pública, que é suscetível a spoofing e ataques Man-in-the-Middle (MITM). Esta vulnerabilidade levou à criação de muitas novas normas para aumentar a segurança no envio e receção de e-mails, sendo uma dessas normas a Autenticação baseada em DNS de Entidades Nomeadas (DANE).
O DANE para SMTP RFC 7672 utiliza a presença de um registo TLSA (Transport Layer Security Authentication) no conjunto de registos DNS de um domínio para sinalizar um domínio e os respetivos servidores de correio suportam DANE. Se não houver nenhum registo TLSA presente, a resolução de DNS para o fluxo de correio funciona como de costume sem que sejam tentadas quaisquer verificações DANE. O registo TLSA assinala de forma segura o suporte do TLS e publica a política DANE para o domínio. Assim, o envio de servidores de correio pode autenticar com êxito servidores de e-mail de receção legítimos com o SMTP DANE. Esta autenticação torna-a resistente a ataques de mudança para uma versão anterior e do MITM. O DANE tem dependências diretas no DNSSEC, que funciona ao assinar digitalmente registos para pesquisas de DNS através da criptografia de chaves públicas. As verificações DNSSEC ocorrem em resoluções de DNS recursivas, os servidores DNS que fazem consultas DNS para clientes. DNSSEC garante que os registos DNS não são adulterados e são autênticos.
Assim que os registos de recursos relacionados com MX, A/AAAA e DNSSEC de um domínio forem devolvidos à resolução recursiva do DNS como autenticação DNSSEC, o servidor de e-mail de envio pede o registo TLSA correspondente à entrada ou entradas do anfitrião MX. Se o registo TLSA estiver presente e a autenticação comprovada utilizar outro marcar DNSSEC, a resolução recursiva de DNS devolve o registo TLSA ao servidor de e-mail de envio.
Depois de receber o registo TLSA autêntico, o servidor de e-mail de envio estabelece uma ligação SMTP ao anfitrião MX associado ao registo TLSA autêntico. O servidor de e-mail de envio tenta configurar o TLS e comparar o certificado TLS do servidor com os dados no registo TLSA para validar que o servidor de correio de destino ligado ao remetente é o servidor de correio de receção legítimo. A mensagem é transmitida (utilizando o TLS) se a autenticação for bem-sucedida. Quando a autenticação falha ou se o TLS não for suportado pelo servidor de destino, Exchange Online repetirá todo o processo de validação que começa com uma consulta DNS para o mesmo domínio de destino novamente após 15 minutos e, em seguida, 15 minutos depois, a cada hora durante as próximas 24 horas. Se a autenticação continuar a falhar após 24 horas de repetição, a mensagem expirará e um NDR com detalhes de erro será gerado e enviado para o remetente.
O registo TLS Authentication (TLSA) é utilizado 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 registo. Os registos TLSA só podem ser considerados fidedignos se o DNSSEC estiver ativado no seu domínio. Se estiver a utilizar um fornecedor de DNS para alojar o seu domínio, a DNSSEC poderá ser uma definição oferecida ao configurar um domínio com eles. Para saber mais sobre a assinatura da zona DNSSEC, visite esta ligação: Descrição geral do DNSSEC | Microsoft Docs.
Registo TLSA de exemplo:
Existem quatro campos configuráveis exclusivos para o tipo de registo TLSA:
Campo utilização do certificado: especifica como o servidor de e-mail de envio deve verificar o certificado do servidor de e-mail de destino.
Valor | Acrônimo | Descrição |
---|---|---|
01 | PKIX-TA | O certificado utilizado é 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 têm de verificar a autenticidade. |
2 | DANE-TA | Utilize a chave privada do servidor da árvore X.509 que tem de ser validada por uma âncora de confiança na cadeia de fidedignidade. O registo TLSA especifica a âncora de fidedignidade a utilizar para validar os certificados TLS para o domínio. |
3 | DANE-EE | Corresponder apenas ao certificado do servidor de destino. |
1 Exchange Online segue a documentação de orientação de implementação rfc de que os valores do Campo de Utilização de Certificados de 0 ou 1 não devem ser utilizados quando o DANE é implementado com SMTP. Quando um registo TLSA com um valor de campo Utilização do Certificado de 0 ou 1 é devolvido ao Exchange Online, Exchange Online trata-o como não utilizável. Se todos os registos TLSA forem considerados inutilizáveis, Exchange Online não executará os passos de validação dane para 0 ou 1 ao enviar o e-mail. Em vez disso, devido à presença de um registo TLSA, Exchange Online impõe a utilização do TLS para enviar o e-mail, enviando o e-mail se o servidor de e-mail de destino suportar TLS ou largando o e-mail e gerando um NDR se o servidor de e-mail de destino não suportar TLS.
No registo TLSA de exemplo, o Campo de Utilização do Certificado está definido como "3", pelo que os Dados da Associação de Certificados ("abc123... xyz789') seria correspondido apenas ao certificado do servidor de destino.
Campo seletor: indica que partes do certificado do servidor de destino devem ser verificadas.
Valor | Acrônimo | Descrição |
---|---|---|
0 | Certificado | Utilize o certificado completo. |
1 | SPKI (Informações da Chave Pública do Requerente) | Utilize a chave pública do certificado e o algoritmo com o qual a chave pública é identificada para utilizar. |
No registo TLSA de exemplo, o Campo do Seletor está definido como "1", pelo que os Dados da Associação de Certificados seriam correspondidos com a chave pública do certificado do servidor de destino e o algoritmo com o qual a chave pública é identificada para utilização.
Campo de Tipo Correspondente: indica o formato em que o certificado está representado no registo TLSA.
Valor | Acrônimo | Descrição |
---|---|---|
0 | Inteiro | Os dados no registo TSLA são o certificado completo ou SPKI. |
1 | SHA-256 | Os dados no registo TSLA são um hash SHA-256 do certificado ou do SPKI. |
2 | SHA-512 | Os dados no registo TSLA são um hash SHA-512 do certificado ou do SPKI. |
No registo TLSA de exemplo, o Campo de Tipo Correspondente está definido como "1", pelo que os Dados da Associação de Certificados são um hash SHA-256 das Informações da Chave Pública do Requerente do certificado do servidor de destino.
Dados de Associação de Certificados: especifica os dados do certificado que são utilizados para corresponder ao certificado do servidor de destino. Estes dados dependem do valor Campo do Seletor e do Valor do Tipo Correspondente.
No registo TLSA de exemplo, os dados da Associação de Certificados estão definidos como "abc123". xyz789'. Uma vez que o valor Campo do Seletor no exemplo está definido como "1", referenciaria a chave pública do certificado do servidor de destino e o algoritmo identificado para ser utilizado com o mesmo. Uma vez que o valor do campo Tipo Correspondente no exemplo está definido como "1", referenciaria o hash SHA-256 das Informações da Chave Pública do Requerente do certificado do servidor de destino.
De acordo com a documentação de orientação de implementação rfc para DANE SMTP, é recomendado um registo TLSA composto pelo campo Utilização do Certificado definido como 3, o campo Seletor definido como 1 e o campo Tipo Correspondente definido como 1.
O processo de fluxo de correio para Exchange Online com o SMTP DANE, apresentado no fluxograma abaixo, valida a segurança do registo de domínios e recursos através de DNSSEC, suporte TLS no servidor de correio de destino e que o certificado do servidor de correio de destino corresponde ao esperado com base no respetivo registo TLSA associado.
Existem apenas dois cenários em que uma falha de SMTP DANE faz com que o e-mail seja bloqueado:
O domínio de destino sinalizou o suporte DNSSEC, mas um ou mais registos foram devolvidos como inautênticos.
Todos os registos MX do domínio de destino têm registos TLSA e nenhum dos certificados do servidor de destino corresponde ao esperado de acordo com os dados do registo TSLA ou uma ligação TLS não é suportada pelo servidor de destino.
Tecnologia | Informações Adicionais |
---|---|
Agente de Transferência de Correio – Segurança de Transporte Rigorosa (MTA-STS) ajuda a impedir a mudança para uma versão anterior e os ataques Man-in-the-Middle ao fornecer um mecanismo para definir políticas de domínio que especifiquem se o servidor de e-mail de destino suporta TLS e o que fazer quando o TLS não pode ser negociado, por exemplo, parar a transmissão. | Mais informações sobre o próximo suporte da Exchange Online para MTA-STS de entrada e saída serão publicadas ainda este ano. Exchange Online Transport News da Microsoft Ignite 2020 - Microsoft Tech Community rfc8461 (ietf.org) |
O Sender Policy Framework (SPF) utiliza informações de IP para garantir que os sistemas de e-mail de destino confiam nas mensagens enviadas a partir do seu domínio personalizado. | Como o Sender Policy Framework (SPF) impede o spoofing |
DomainKeys O Correio Identificado (DKIM) utiliza informações de certificado X.509 para garantir que os sistemas de e-mail de destino confiam nas mensagens enviadas de saída do seu domínio personalizado. | Use o DKIM para e-mails em seu domínio personalizado |
A Autenticação de Mensagens baseada em domínio, Relatórios e Conformidade (DMARC) funciona com o Sender Policy Framework e o DomainKeys Identified Mail para autenticar remetentes de correio e garantir que os sistemas de e-mail de destino confiam nas mensagens enviadas a partir do seu domínio. | Use DMARC para validar o email, etapas de configuração |
Antes de começar, certifique-se de que cumpre os seguintes pré-requisitos:
- Tem de ter adicionado o domínio como um "Domínio Aceite" e o domínio status tem de ser "Bom estado de funcionamento" no Centro de Administração Microsoft 365. A documentação pressupõe que o registo MX do domínio está definido como prioridade 0 ou 10 e que não existe nenhum registo MX secundário ou "contingência". Se tiver um registo MX de contingência, terá de trabalhar em estreita colaboração com o administrador do Exchange Online para garantir que as alterações são realizadas corretamente.
- Para receber todos os benefícios de segurança da funcionalidade, certifique-se de que ativou o DNSSEC para o seu domínio.
- Tem de ter acesso ao Exchange Online PowerShell e às permissões para executar os cmdlets descritos no Exchange Online PowerShell
- Se o domínio que pretende proteger com o SMTP DE Entrada DANE com DNSSEC for referenciado em quaisquer configurações de smarthost ou em quaisquer conectores, tem de mudar o nome do smarthost para
tenantname.mail.protection.outlook.com
antes de seguir os passos.
Observação
Se quiser ativar o DNSSEC para um domínio que utiliza um gateway de terceiros, pode fazê-lo ao seguir os passos 1 a 3, seguindo a nota no final do passo 3 em gateways de terceiros.
Aviso
Se quiser configurar o SMTP DANE de entrada com dNSSEC para o seu "Domínio Aceite" e os contoso.com
seus parceiros empresariais estiverem a utilizar conectores para o ponto contoso-com.mail.protection.outlook.com
final, tem de trabalhar com os seus parceiros para que atualizem os conectores para referenciar o tenantname.onmicrosoft.com
ponto final ou o tenantname.mail.protection.outlook.com
ponto final, antes de configurar o SMTP DANE de entrada com dNSSEC. Caso contrário, o correio dos conectores dos seus parceiros empresariais falha após concluir a ativação. Depois de concluir a ativação, os seus parceiros podem utilizar o novo contoso-com.<random>.mx.microsoft
ponto final para restabelecer o conector original.
Observação
O aprovisionamento e as atualizações de registos DNS podem demorar algum tempo a concluir. As alterações de DNS podem demorar mais tempo do que o esperado para ficarem visíveis devido a múltiplas camadas de colocação em cache.
Para configurar o SMTP DANE de entrada com dNSSEC, execute os seguintes passos:
Atualize o TTL do registo MX existente para o TTL mais baixo possível (mas não inferior a 30 segundos). Em seguida, aguarde até que o TTL anterior expire antes de continuar. Por exemplo, se o TTL do seu registo MX existente tiver sido "3600 segundos" ou "1 hora" antes de o alterar, terá de aguardar 1 hora antes de prosseguir para o passo 2.
Conecte-se ao PowerShell do Exchange Online.
Aviso
Se estiver a utilizar MTA-STS, tem de definir o modo de política para "testar" e atualizar o ID no registo txt MTA-STS. (Pode utilizar a hora atual em UTC como o novo ID de política.) Em seguida, aguarde até que o "max_age" da política expire antes de continuar. Por exemplo, se o "max_age" da sua política de STS existente for de 3600 segundos ou 1 hora antes de a alterar, terá de aguardar "1 hora" antes de continuar.
Para o domínio para o qual pretende ativar o SMTP DANE com DNSSEC, primeiro tem de ativar o DNSSEC no domínio ao executar o seguinte comando (substitua "domínio" pelo nome do domínio escolhido, por exemplo, contosotest.com):
Enable-DnssecForVerifiedDomain -DomainName <DomainName>
Observação
Este comando pode demorar alguns minutos a ser executado.
Exemplo de saída da execução com êxito
Resultado DnssecMxValue ErrorData Êxito contosotest-com.o-v1.mx.microsoft A resposta com êxito fornece o valor MX para o domínio. Este valor é o nome para o qual o novo registo MX aponta para o domínio que está a ativar com DNSSEC. Por exemplo,
contosotest-com.o-v1.mx.microsoft
.Utilize o valor "DnssecMxValue", navegue para a entidade de registo DNS que aloja o domínio, adicione um novo registo MX com o valor devolvido no passo 3, defina o TTL para o valor mais baixo possível (mas não inferior a 30 segundos) e defina a prioridade do novo registo MX como 20.
Observação
Se estiver a utilizar um gateway de e-mail de terceiros e quiser utilizar este valor como o novo anfitrião de destino Exchange Online para o qual o gateway de e-mail de terceiros enviará o seu e-mail de entrada, navegue para o portal de administração de terceiros, atualize o anfitrião inteligente de destino que os terceiros utilizam para enviar para Exchange Online e, em seguida, valide que "o fluxo de correio funciona através do teste DNSSEC (certifique-se de que seleciona "Validação DNSSEC" durante a entrada de teste e não "Validação DANE [incluindo DNSSEC])" no Analisador de Conectividade Remota da Microsoft: Entrada de Teste". Se o correio estiver a fluir conforme esperado, NÃO tem de continuar a seguir os passos abaixo. Se quiser ativar o SMTP DANE para este domínio, avance para o passo 7.
Aviso
Se estiver a utilizar o MTA-STS, certifique-se de que o modo de política está definido como "teste". Em seguida, elimine a linha mx atual que contém as informações de registo MX legadas e adicione o novo FQDN ao ficheiro de política MTA-STS como uma nova linha mx. Em seguida, atualize o ID da política na política e o registo TXT MTA-STS (pode utilizar a hora atual em UTC como o novo ID da política).
Verifique se o novo MX está a funcionar através do teste de Email SMTP de Entrada (https://testconnectivity.microsoft.com/tests/O365InboundSmtp/input) ao expandir os Passos de Teste e verificar se o Mail Exchanger que termina em mx.microsoft foi testado com êxito. Poderá ter de repetir este teste, dependendo da colocação em cache de DNS.
Exemplo de saída com êxito
Alterar a prioridade do MX legado que aponta para mail.protection.outlook.com da prioridade atual para 30; altere a prioridade do registo MX criado no passo 3 para que esteja definido como prioridade 0 (prioridade mais alta).
Elimine o registo MX legado que termina com "mail.protection.outlook.com", "mail.eo.outlook.com" ou "mail.protection.outlook.de". Em seguida, atualize o TTL para o registo MX que termina em mx.microsoft para 3600 segundos. Opcionalmente, pode confirmar que está tudo a funcionar conforme esperado com o teste DNSSEC (certifique-se de que seleciona "Validação DNSSEC" durante a entrada de teste e não "Validação DANE [incluindo DNSSEC])" no Analisador de Conectividade Remota. Poderá ter de repetir este teste, consoante a colocação em cache de DNS e os TTLs.
Assim que os TTLs no registo MX legado tiverem expirado, uma saída com êxito terá o seguinte aspeto:
Execute o seguinte comando [substituir (DomainName) pelo nome do domínio escolhido, por exemplo, contosotest.com] se quiser ativar o SMTP DANE para esse mesmo domínio assim que a ativação DNSSEC estiver concluída:
Enable-SmtpDaneInbound -DomainName <DomainName>
Resultado ErrorData Êxito Verifique se o registo TLSA foi propagado (o que pode demorar entre 15 a 30 minutos) utilizando uma ferramenta online à sua escolha e o Microsoft Remote Connectivity Analyzer: Entrada de Teste.
Depois de concluir a ativação DNSSEC e o registo DANE (TLSA) SMTP ter sido aprovisionado por Exchange Online, é apresentada uma saída com êxito, conforme mostrado na seguinte captura de ecrã:
Exchange Online aloja vários registos TLSA para aumentar a fiabilidade de um êxito das validações DANE do SMTP. Espera-se que alguns dos registos TLSA possam falhar a validação. Desde que 1 registo TLSA esteja a passar a validação, o SMTP DANE está configurado corretamente e o e-mail é protegido com o SMTP DANE.
Aviso
Se estiver a utilizar o MTA-STS, depois de confirmar que a política está a funcionar e que o correio está a fluir conforme esperado, defina o modo de política novamente como "impor" e atualize o ID no registo txt MTA-STS. (Pode utilizar a hora atual em UTC como o novo ID de política.)
- Domínios de inscrição viral ou self-service: os domínios que foram configurados como "self-service" não são atualmente suportados com o DANE SMTP de Entrada com DNSSEC.
- onmicrosoft.com domínios: o domínio "onmicrosoft.com" do inquilino não é atualmente suportado com o DANE SMTP de Entrada com DNSSEC. Estamos a investigar o suporte para o SMTP DANE de Entrada com DNSSEC para os domínios de onmicrosoft.com; no entanto, o ETA é desconhecido.
- Gateways de terceiros: os clientes que utilizam um gateway de e-mail de terceiros no caminho de entrada (que aceita correio para o inquilino, faz algum processamento e, em seguida, reencaminha-o para Exchange Online) só poderão utilizar esta funcionalidade para proteger os e-mails reencaminhados do gateway de terceiros para Exchange Online se o gateway de terceiros suportar o SMTP DANE com validação DNSSEC. Os clientes nesta configuração teriam de configurar o SMTP DANE de Entrada com dNSSEC através do Exchange PowerShell.
- Outra integração de terceiros com o fluxo de correio: existem clientes para gateways de terceiros no caminho de saída, onde o e-mail é enviado para terceiros através de um conector, os terceiros fazem algum processamento e, em seguida, submetem-se novamente a Exchange Online e, em seguida, Exchange Online enviam finalmente o e-mail. Estes clientes poderão ter de trabalhar com o fornecedor de terceiros ao ativar a funcionalidade para que não haja interrupções. O reencaminhamento de terceiros tem de utilizar uma pesquisa DNS ao submeter o e-mail novamente para Exchange Online e utilizar o novo nome de anfitrião de registo MX -> contoso-com.( subdomínio).mx.microsoft criado durante a ativação de funcionalidades. Os terceiros NÃO DEVEM utilizar o nome de anfitrião de registo MX antigo -> contoso-com.mail.protection.outlook.com como Exchange Online eliminará o registo A aproximadamente no prazo de 2 dias (48 horas) após a ativação da funcionalidade assim que chegarmos ao GA.
- Domínios totalmente delegados: os domínios alojados pela Microsoft e que utilizam a delegação NS para que os servidores de nomes da Microsoft sejam autoritativos para o domínio são suportados com o DANE SMTP de Entrada com DNSSEC. Pretendemos suportar o SMTP DANE de Entrada com DNSSEC para estes domínios; no entanto, o ETA é desconhecido.
DomainNotFound
Mensagem (DNSSEC): "A ativação/desativação do DNSSEC falhou devido ao domínio contoso.com não existente no AAD."
Mensagens (SMTP DANE):- "Falha ao ativar/desativar o DANE do SMTP devido a contoso.com de domínio não existente no AAD."
- "Falha ao ativar/desativar o DANE do SMTP devido a domínio contoso.com não encontrado na lista de domínios aceites."
Causa: o domínio fornecido não foi encontrado na lista de domínios aceites.
Ações a Executar: navegue para o Centro de Administração Microsoft 365 e certifique-se de que o domínio foi verificado com o inquilino. Se o domínio estiver em bom estado de funcionamento no Administração Microsoft 365 Center, navegue para o Centro de Administração do Exchange e certifique-se de que o domínio foi adicionado como um "Domínio Aceite".
DNSSEC
Resultado DnssecMxValue ErrorData Erro ErrorCode: 'DomainNotFound' ErrorDetails 'DNSSEC enabling failed... SMTP DANE
Resultado ErrorData Erro ErrorCode: "DomainNotFound" ErrorDetails "SMTP DANE enabling... - "Falha ao ativar/desativar o DANE do SMTP devido a contoso.com de domínio não existente no AAD."
DnsSecOperationFailed
Mensagem (DNSSEC): "A ativação/desativação do DNSSEC falhou devido a AdditionalErrorDetails. Repita a operação mais tarde.
Mensagens (SMTP DANE): falha ao ativar/desativar o DANE do SMTP devido a AdditionalErrorDetails. Repita a operação mais tarde.
Causa: Uma tentativa de criar a zona DNS adequada e/ou registos falhou.
Ações a Executar: tente executar novamente o cmdlet.DNSSEC
Resultado DnssecMxValue ErrorData Erro ErrorCode: 'DnssecOperationFailed' ErrorDetails 'DNSSEC enabling failed... SMTP DANE
Resultado ErrorData Erro ErrorCode: "DnssecOperationFailed" ErrorDetails "SMTP DANE enabling ... PartitionNotFound
Mensagens (SMTP DANE): "Falha ao ativar/desativar o DANE do SMTP devido ao domínio contoso.com não ter uma partição."
Causa: O DNSSEC não está ativado para o domínio.
Ações a Executar: certifique-se de que utiliza um domínio compatível com DNSSEC.Resultado ErrorData Erro ErrorCode: "PartitionNotFound" ErrorDetails "SMTP DANE enabling" DomainNotSupported
Mensagem (DNSSEC): "O domínio especificado é um domínio onmicrosoft: contoso-com.onmicrosoft.com."
Mensagens (SMTP DANE): "O domínio especificado é um domínio onmicrosoft: contoso-com.onmicrosoft.com."
Causa: o domínio é um domínio inicial ou MOERA. Atualmente, estes não são suportados.
Ações a Executar: certifique-se de que utiliza um domínio que não termina com "onmicrosoft.com".DNSSEC
Resultado DnssecMxValue ErrorData Erro ErrorCode: "DomainNotSupported" ErrorDetails "O domínio especificado... SMTP DANE
Resultado ErrorData Erro ErrorCode: "DomainNotSupported" ErrorDetails "O domínio especificado...
Mensagem: "EG001: Não é possível obter a funcionalidade DNSSEC status para o domínio [{domain}].".
Causa: ao validar a configuração do domínio no Exchange Online, descobrimos que o domínio não foi adicionado ao Exchange Online. Se pensa que já adicionou este domínio a Exchange Online, tente executar novamente o cmdlet, uma vez que este pode ser um problema transitório.
Ações a Executar: repita o cmdlet. Se continuar a falhar, navegue para o Centro de Administração Microsoft 365 e conclua o processo de configuração deste domínio.Mensagem: "EG002: O domínio [{domain}] não é um domínio verificado da organização."
Causa: ao validar a configuração do domínio no Exchange Online, detetámos que o domínio foi adicionado a Exchange Online, mas não verificado.
Ações a Executar: navegue para o Centro de Administração Microsoft 365 e conclua o processo de configuração e verificação deste domínio.Mensagem: "Ocorre um erro de consulta DNS ao obter registos MX para o domínio [{domain}]."
Causa: durante a validação do DNS, recebemos uma falha de DNS genérica ao consultar o domínio.
Ações a Executar: repita a execução do cmdlet. Poderá ter de rever a configuração do domínio que está a tentar ativar com o SMTP DANE com DNSSEC.Mensagem: "Domínio [{domain}] não encontrado."
Causa: durante a validação de DNS, recebemos uma falha de NXDOMAIN ao consultar o domínio.
Ações a Executar: repita a execução do cmdlet depois de verificar a configuração do registo MX para o domínio. A propagação de DNS pode demorar até 48 horas para alguns fornecedores de DNS.Mensagem: "ED003: Domínio [{domain}] encontrado. Não foram encontrados registos MX autênticos."
Causa: durante a validação DNSSEC, não conseguimos encontrar um registo MX que foi resolvido para um registo A protegido por DNSSEC (o registo A para o valor "hostname" do registo MX).
Ações a Executar: repita a execução do cmdlet depois de verificar a configuração do registo MX para o domínio. A propagação de DNS pode demorar até 48 horas para alguns fornecedores de DNS.Mensagem: "EX002: O valor do registo MX não correspondeu ao esperado."
Causa: durante a validação MX, não encontrámos um registo MX que corresponda ao esperado.
Ações a Executar: reveja os seus registos MX no seu domínio. Certifique-se de que um registo MX corresponde ao registo esperado que é exportado após executarEnable-DnssecForVerifiedDomain
ouGet-DnssecStatusForVerifiedDomain
.Mensagem: "EX003: A prioridade do registo MX não correspondeu à esperada."
Causa: durante a validação MX, encontrámos o registo MX esperado, mas a prioridade não estava definida como 0.
Ações a Executar: defina o registo MX (que contém o valor devolvido ao executarEnable-DnssecForVerifiedDomain
ouGet-DnssecStatusForVerifiedDomain
) como prioridade 0.Mensagem: "EX004: Existe um registo MX diferente com a mesma preferência que o esperado."
Causa: durante a validação MX, descobrimos que o registo MX de prioridade mais alta não era o registo MX esperado.
Ações a Tomar: se já tiver concluído os passos 1 a 4 de Configurar o SMTP DANE de entrada com DNSSEC, conclua os passos 5 e 6 ao mudar as prioridades dos seus registos MX para que o MX esperado seja 0 (prioridade mais alta), valide a configuração e, em seguida, elimine o registo MX legado.Mensagem: "EX005: Existe um registo MX diferente com uma preferência inferior à esperada."
Causa: durante a validação MX, encontrámos um registo MX para o domínio que não corresponde ao registo MX esperado.
Ações a Tomar: se já tiver concluído os passos 1 a 5 de Configurar o SMTP DANE de entrada com dNSSEC, conclua o passo 6 ao eliminar o registo MX legado.Mensagem: "EX006: Existe um registo MX diferente com uma preferência superior à esperada."
Causa: durante a validação MX, encontrámos um registo MX diferente com uma preferência superior à esperada.
Ações a Tomar: defina o registo MX legado (que termina em mail.protection.outlook.com, mail.eo.outlook.com ou mail.protection.outlook.de) como prioridade 20.Mensagem: "EX007: O registo MX não foi encontrado."
Causa: durante a validação MX, não encontrámos um registo MX que corresponda ao esperado.
Ações a Executar: reveja os seus registos MX no seu domínio. Certifique-se de que um registo MX corresponde ao registo esperado que é exportado após executarEnable-DnssecForVerifiedDomain
ouGet-DnssecStatusForVerifiedDomain
.Mensagem: "EX008: Foi encontrado o registo MX correto, mas com uma preferência inferior ao esperado."
Causa: durante a validação MX, descobrimos que o registo MX esperado tem a prioridade errada.
Ações a Executar: defina o registo MX (que contém o valor devolvido ao executarEnable-DnssecForVerifiedDomain
ouGet-DnssecStatusForVerifiedDomain
) como prioridade 0.Mensagem: "EX009: Foi encontrado o registo MX correto, mas com uma preferência superior ao esperado."
Causa: durante a validação MX, descobrimos que o registo MX esperado tem a prioridade errada.
Ações a Executar: defina o registo MX (que contém o valor devolvido ao executarEnable-DnssecForVerifiedDomain
ouGet-DnssecStatusForVerifiedDomain
) como prioridade 0.Mensagem: "EX010: Erro desconhecido ao procurar registos MX para o domínio [{domain}]."
Causa: durante a validação MX, ocorreu um erro DNS genérico.
Ações a Executar: repita a execução do cmdlet depois de verificar a configuração do registo MX para o domínio. A propagação de DNS pode demorar até 48 horas para alguns fornecedores de DNS.Mensagem: "EX012: Registos MX não encontrados para o domínio [{domain}]."
Causa: durante a validação MX, não encontrámos um registo MX que corresponda ao esperado.
Ações a Executar: reveja os seus registos MX no seu domínio. Certifique-se de que um registo MX corresponde ao registo esperado que é exportado após executarEnable-DnssecForVerifiedDomain
ouGet-DnssecStatusForVerifiedDomain
.Mensagem: "EX013: Registo MX esperado desconhecido para o domínio [{domain}]."
Causa: durante a validação MX, não encontrámos um registo MX que corresponda ao esperado.
Ações a Executar: reveja os seus registos MX no seu domínio. Certifique-se de que um registo MX corresponde ao registo esperado que é exportado após executarEnable-DnssecForVerifiedDomain
ouGet-DnssecStatusForVerifiedDomain
.Mensagem: "ES001: Registo MX esperado em falta na política enquanto o modo é "imposto"."
Causa: durante a validação MTA-STS, não conseguimos encontrar o valor mx correspondente ao registo esperado.
Ações a Executar: defina o modo da política MTA-STS para testar; em seguida, adicione o valor mxhostname (devolvido ao executarEnable-DnssecForVerifiedDomain
ouGet-DnssecStatusForVerifiedDomain
) como uma linha na política MTA-STS.Mensagem: "ES002: Não foi encontrado nenhum registo MX esperado com o qual comparar a política. Ative a funcionalidade DNSSEC para o domínio [{domain}] primeiro.
Causa: O MTA-STS foi encontrado, mas a status DNSSEC do domínio não era exequível.
Ações a Executar: conclua os passos em Configurar o SMTP DANE de entrada com DNSSEC.
Existem três cenários principais para problemas de fluxo de correio assim que o DANE SMTP de Entrada com DNSSEC tiver sido ativado:
- Problema com falhas nas validações do DANE do SMTP: para obter informações sobre como mitigar este problema, a mitigação das validações do DANE do SMTP falha.
- Problema com a falha de validações DNSSEC: para obter informações sobre como mitigar este problema, veja A mitigação de validações DNSSEC falha.
- Problema com o valor MX: para obter informações sobre como mitigar este problema, veja Mitigating issues with MX value (Mitigar problemas com o valor MX).
Para mitigar o impacto das validações do SMTP DANE, execute o seguinte comando:
Disable-SmtpDaneInbound -DomainName <DomainName>
Para mitigar qualquer impacto de falhas nas validações DNSSEC, tem de desativar o DNSSEC no seu domínio (contoso.com) através do seu fornecedor de DNS.
Observação
Se a desativação do DNSSEC não resolve o problema, poderá ser um problema com o valor MX.
Depois de desativar o DNSSEC no seu domínio através do seu fornecedor de DNS, abra um pedido de suporte junto do seu fornecedor DNS para determinar como reativar o DNSSEC em segurança para o seu domínio.
Certifique-se de que o valor MX corresponde ao valor no Administração Microsoft 365 Center –> Definições –> Domínios.
Selecione o domínio, selecione Registos DNS e, em seguida, execute Verificar estado de funcionamento.
Certifique-se de que o registo MX é apresentado como OK; Se não for o caso, atualize o valor para o que é fornecido no centro de administração.
Navegue para a sua entidade de registo DNS e localize o registo MX do seu domínio. O valor do nome do anfitrião será:
<MX token>.<subdomain>.mx.microsoft
Crie um segundo registo MX com o seguinte valor de nome de anfitrião e defina a prioridade como 20:
<MX token>.mail.protection.outlook.com
Observação
Substitua o valor "MX Token" pelo token MX do registo MX atual do seu domínio encontrado no passo 4. Por exemplo, o token MX para contosotest.com é contosotest-com.
Certifique-se de que o MX criado no passo 5 está a funcionar.
Importante
Uma forma de garantir que o segundo registo MX está a funcionar é utilizar o Microsoft Remote Connectivity Analyzer.
- Introduza o domínio (por exemplo, contoso.com) no teste; e, em seguida, selecione Executar Teste.
- Abra Os Passos de Teste.
- Abra Os Passos de Teste para Testar o fluxo de correio SMTP de entrada para o domínio "admin@(domínio)".
- Abra Detalhes Adicionais em A tentar obter registos DNS MX para o domínio "(domínio)".
- Confirme que o (token MX) .mail.protection.outlook.com registo MX está em bom estado de funcionamento.
Se o fluxo de correio estiver a funcionar com o registo MX token.mail.protection.outlook.com MX, execute o seguinte comando:
Disable-DnssecForVerifiedDomain -DomainName <DomainName>
Elimine o registo MX DNSSEC que corresponde aos valores abaixo:
<MX token>.<subdomain>.mx.microsoft
Certifique-se de que o registo MX que criou no passo 5 é o único registo MX e que está definido como prioridade 0 (prioridade mais alta).
Enquanto cliente Exchange Online, não precisa de fazer nada para configurar esta segurança de e-mail melhorada para o seu e-mail de saída. Esta segurança de e-mail melhorada é algo que criámos para si e está ativada por predefinição para todos os clientes Exchange Online e é utilizada quando o domínio de destino anuncia suporte para o DANE. Para colher os benefícios do envio de e-mails com verificações DNSSEC e DANE, comunique com os seus parceiros empresariais com quem troca e-mails de que precisam para implementar a DNSSEC e a DANE para que possam receber e-mails com estas normas.
Atualmente, existem quatro códigos de erro para o DANE ao enviar e-mails com Exchange Online. A Microsoft está a atualizar ativamente esta lista de códigos de erro. Os erros serão visíveis em:
O portal do Exchange Administração Center através da vista Detalhes do Rastreio de Mensagens.
NDRs gerados quando uma mensagem não é enviada devido a uma falha dane ou DNSSEC.
Ferramenta Do Analisador de Conectividade Remota do Microsoft Remote Connectivity Analyzer.
Código NDR Descrição 4/5.7.321 starttls-not-supported: o servidor de correio de destino tem de suportar o TLS para receber correio. 4/5.7.322 certificado expirado: o certificado do servidor de correio de destino expirou. 4/5.7.323 tlsa-invalid: o domínio falhou na validação dane. 4/5.7.324 dnssec-invalid: o domínio de destino devolveu registos DNSSEC inválidos. Observação
Atualmente, quando um domínio sinaliza que suporta DNSSEC, mas falha nas verificações DNSSEC, Exchange Online não gera o erro 4/5.7.324 dnssec-invalid. Gera um erro DNS genérico:
4/5.4.312 DNS query failed
Estamos a trabalhar ativamente para resolver esta limitação conhecida. Se receber esta instrução de erro, navegue para o Microsoft Remote Connectivity Analyzer 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 de DNS diferente.
Normalmente, este erro indica um problema com o servidor de correio de destino. Depois de receber a mensagem:
- Verifique se o endereço de e-mail de destino foi introduzido corretamente.
- Alertar o administrador de e-mail de destino de que recebeu este código de erro para que este possa determinar se o servidor de destino está configurado corretamente para receber mensagens com o TLS.
- Repita o envio do e-mail e reveja os Detalhes do Rastreio de Mensagens para a mensagem no portal do Exchange Administração Center.
Um certificado X.509 válido que não tenha expirado tem de ser apresentado ao servidor de e-mail 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 e-mail de destino que recebeu este código de erro e forneça a cadeia de código de erro.
- Aguarde tempo para que o certificado do servidor de destino seja renovado e que o registo TLSA seja atualizado para referenciar o novo certificado. Em seguida, repita o envio do e-mail e reveja os Detalhes do Rastreio de Mensagens para a mensagem no portal do Exchange Administração Center.
Este código de erro está relacionado com uma configuração incorreta do registo TLSA e só pode ser gerado depois de ter sido devolvido um registo TLSA de autenticação DNSSEC. Existem muitos cenários durante a validação do DANE que ocorrem após a devolução do registo, o que pode resultar na geração do código. A Microsoft está a trabalhar ativamente nos cenários abrangidos por este código de erro, para que cada cenário tenha um código específico. Atualmente, um ou mais destes 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á a ser atacado.
- Qualquer outra falha DANE.
Depois de receber a mensagem:
- Alerte o administrador de e-mail de destino que recebeu este código de erro e forneça-lhe a cadeia de código de erro.
- Aguarde tempo para que o administrador de e-mail de destino reveja a configuração DANE e a validade do certificado do servidor de e-mail. Em seguida, repita o envio do e-mail e reveja os Detalhes do Rastreio de Mensagens para a mensagem no portal do Exchange Administração Center.
Este código de erro é gerado quando o domínio de destino indicou que era DNSSEC-authentic, mas Exchange Online não conseguiu verificá-lo como DNSSEC-authentic.
Depois de receber a mensagem:
- Alerte o administrador de e-mail de destino que recebeu este código de erro e forneça-lhe a cadeia de código de erro.
- Aguarde tempo para que o administrador de e-mail de destino reveja a configuração DNSSEC do respetivo domínio. Em seguida, repita o envio do e-mail e reveja os Detalhes do Rastreio de Mensagens para a mensagem no portal do Exchange Administração Center.
Atualmente, existem dois métodos que um administrador de um domínio de receção pode utilizar para validar e resolver problemas da configuração DNSSEC e DANE para receber e-mails de Exchange Online com as seguintes normas:
- Adote o SMTP TLS-RPT (Transport Layer Security Reporting) introduzido no RFC8460
- Utilizar 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órios para os remetentes fornecerem detalhes aos administradores de domínio de destino sobre os êxitos e falhas do DANE e do MTA-STS com esses respetivos domínios de destino. Para receber relatórios TLS-RPT, só tem de adicionar um registo TXT nos registos DNS do seu domínio que inclua o endereço de e-mail ou o URI para o qual pretende que os relatórios sejam enviados. Exchange Online enviará relatórios TLS-RPT no formato JSON.
Os dados da tabela seguinte são um exemplo de um registo:
Tipo | Domain Name | TTL | Gravar |
---|---|---|---|
TXT | _smtp._tls.microsoft.com | 3600 | v=TLSRPTv1; rua=https://tlsrpt.azurewebsites.net/report |
O segundo método consiste em utilizar o Analisador de Conectividade Remota do Microsoft Remote Connectivity Analyzer, que pode fazer as mesmas verificações DNSSEC e DANE relativamente à configuração de DNS que Exchange Online irá fazer ao enviar e-mails fora do serviço. Este método é a forma mais direta de resolver erros na sua configuração para receber e-mails de Exchange Online com estas normas.
Quando os erros estão a ser resolvidos, podem ser gerados os códigos de erro abaixo:
Código NDR | Descrição |
---|---|
4/5.7.321 | starttls-not-supported: o servidor de correio de destino tem de suportar o TLS para receber correio. |
4/5.7.322 | certificado expirado: o certificado do servidor de correio de destino expirou. |
4/5.7.323 | tlsa-invalid: o domínio falhou na validação dane. |
4/5.7.324 | dnssec-invalid: o domínio de destino devolveu registos DNSSEC inválidos. |
Observação
Atualmente, quando um domínio sinaliza que suporta DNSSEC, mas falha nas verificações DNSSEC, Exchange Online não gera o erro 4/5.7.324 dnssec-invalid. Gera um erro DNS genérico:
4/5.4.312 DNS query failed
Estamos a trabalhar ativamente para resolver esta limitação conhecida. Se receber esta instrução de erro, navegue para o Microsoft Remote Connectivity Analyzer 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 de DNS diferente.
Observação
Estes passos destinam-se à resolução de problemas dos administradores de e-mail que recebem e-mails de Exchange Online através do SMTP DANE.
Normalmente, este erro indica um problema com o servidor de correio de destino. O servidor de correio com o qual o Analisador de Conectividade Remota está a testar a ligação. Geralmente, existem dois cenários que geram este código:
- O servidor de correio de destino não suporta comunicações seguras e tem de ser utilizada uma comunicação simples e não encriptada.
- O servidor de destino está configurado incorretamente e ignora o comando STARTTLS.
Depois de receber a mensagem:
- Verifique o endereço de e-mail.
- Localize o endereço IP associado à instrução de erro para que possa identificar o servidor de correio ao qual a instrução está associada.
- Verifique a definição do servidor de correio para se certificar de que está configurado para escutar o tráfego SMTP (normalmente, as portas 25 e 587).
- Aguarde alguns minutos e, em seguida, repita o teste com a ferramenta Remote Connectivity Analyzer.
- Se continuar a falhar, tente remover o registo TLSA e execute novamente o teste com a ferramenta Remote Connectivity Analyzer.
- Se não existirem falhas, esta mensagem pode indicar que o servidor de correio que está a utilizar para receber correio não suporta STARTTLS e poderá ter de atualizar para um que o faça para utilizar o DANE.
Observação
Estes passos destinam-se à resolução de problemas dos administradores de e-mail que recebem e-mails de Exchange Online através do SMTP DANE.
Um certificado X.509 válido que não tenha expirado tem de ser apresentado ao servidor de e-mail de envio. Os certificados X.509 devem ser renovados após a expiração, normalmente anualmente. Depois de receber a mensagem:
- Verifique o IP associado à instrução de erro, para que possa identificar o servidor de e-mail ao qual está associado. Localize o certificado expirado no servidor de e-mail que identificou.
- Inicie sessão no site do fornecedor de certificados.
- Selecione o certificado expirado e siga as instruções para renovar e pagar a renovação.
- Depois de o seu fornecedor ter verificado a compra, pode transferir um novo certificado.
- Instale o certificado renovado no respetivo servidor de correio associado.
- Atualize o registo TLSA associado ao servidor de correio com os dados do novo certificado.
- Depois de aguardar um período de tempo adequado, repita o teste com a ferramenta Remote Connectivity Analyzer.
Observação
Estes passos destinam-se à resolução de problemas dos administradores de e-mail que recebem e-mails de Exchange Online através do SMTP DANE.
Este código de erro está relacionado com uma configuração incorreta do registo TLSA e só pode ser gerado depois de um registo TSLA autenticado DNSSEC ter sido devolvido. No entanto, existem muitos cenários durante a validação dane que ocorrem após a devolução do registo, o que pode resultar na geração do código. A Microsoft está a trabalhar ativamente nos cenários abrangidos por este código de erro, para que cada cenário tenha um código específico. Atualmente, um ou mais destes 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 é uma hora válida/configurada para um período de tempo futuro.
- 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 e-mail ao qual está associado.
- Identifique o registo TLSA associado ao servidor de correio identificado.
- Verifique a configuração do registo TLSA para garantir que sinaliza o remetente para efetuar as verificações DANE preferenciais e que os dados de certificado corretos foram incluídos no registo TLSA.
- Se tiver de fazer atualizações ao registo para discrepâncias, aguarde alguns minutos e, em seguida, volte a executar o teste com a ferramenta Remote Connectivity Analyzer.
- Localize o certificado no servidor de correio identificado.
- Verifique a janela de tempo para a qual o certificado é válido. Se estiver definida para iniciar a validade numa data futura, tem de ser renovada para a data atual.
- Inicie sessão no site do fornecedor de certificados.
- Selecione o certificado expirado e siga as instruções para renovar e pagar a renovação.
- Depois de o seu fornecedor ter verificado a compra, pode transferir um novo certificado.
- Instale o certificado renovado no respetivo servidor de correio associado.
Observação
Estes passos destinam-se à resolução de problemas dos administradores de e-mail que recebem e-mails de Exchange Online através do SMTP DANE.
Este código de erro é gerado quando o domínio de destino indica que é DNSSEC-authentic, mas Exchange Online não consegue verificá-lo como DNSSEC-authentic. Esta secção não será abrangente para resolver problemas de DNSSEC e foca-se em cenários em que os domínios passaram anteriormente pela autenticação DNSSEC, mas não agora.
Observação
Este código de erro também é gerado se Exchange Online receber a resposta SERVFAIL do servidor DNS na consulta TLSA para o domínio de destino.
Depois de receber a mensagem:
- Se estiver a utilizar um fornecedor de DNS, por exemplo, a GoDaddy, alerte o fornecedor DNS do erro para que possa trabalhar na resolução de problemas e na alteração da configuração.
- Se estiver a gerir a sua própria infraestrutura DNSSEC, existem muitas configurações incorretas de DNSSEC que podem gerar esta mensagem de erro. Alguns problemas comuns de marcar se a sua zona estava a transmitir anteriormente a autenticação DNSSEC:
- Cadeia de confiança quebrada, quando a zona principal contém um conjunto de registos DS que apontam para algo que não existe na zona subordinada. Tais ponteiros por registos DS podem fazer com que a zona subordinada seja marcada como falsa ao validar as resoluções.
- Resolva ao rever os IDs de chave RRSIG dos domínios subordinados e ao garantir que correspondem aos IDs de chave nos registos DS publicados na zona principal.
- O registo de recursos RRSIG para o domínio não é válido, expirou ou o respetivo período de validade ainda não começou.
- Resolva ao gerar novas assinaturas para o domínio com períodos de tempo válidos.
- Cadeia de confiança quebrada, quando a zona principal contém um conjunto de registos DS que apontam para algo que não existe na zona subordinada. Tais ponteiros por registos DS podem fazer com que a zona subordinada seja marcada como falsa ao validar as resoluções.
Quando um e-mail de saída está a ser enviado, se o domínio de receção tiver o DNSSEC ativado, consultamos os registos TLSA associados às entradas MX no domínio. Se não for publicado nenhum registo TLSA, a resposta à pesquisa TLSA tem de ser NOERROR (nenhum registo do tipo pedido para este domínio) ou NXDOMAIN (não existe tal domínio). O DNSSEC requer esta resposta se não for publicado nenhum registo TLSA; 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 é fidedigna; assim, o domínio de destino falha na validação DNSSEC. Em seguida, este e-mail é adiado com o seguinte erro:
450 4.7.324 dnssec-invalid: Destination domain returned invalid DNSSEC records
Se estiver a utilizar um fornecedor de DNS, por exemplo, a GoDaddy, alerte o fornecedor DNS do erro para que possa resolver problemas com a resposta DNS. Se estiver a gerir a sua própria infraestrutura DNSSEC, pode ser um problema com o próprio servidor DNS ou com a rede.
Acreditamos firmemente que a DNSSEC e a DANE aumentarão significativamente a posição de segurança do nosso serviço e beneficiarão todos os nossos clientes. Trabalhámos diligentemente ao longo do último ano para reduzir o risco e a gravidade do impacto potencial que esta implementação pode ter para os clientes do Microsoft 365. Vamos monitorizar e controlar ativamente a implementação para garantir que o impacto negativo é minimizado à medida que é lançado. Por este motivo, as exceções ao nível do inquilino ou a exclusão não estarão disponíveis. Se tiver problemas relacionados com a ativação de DNSSEC e/ou DANE, os diferentes métodos para investigar falhas anotados neste documento irão ajudá-lo a identificar a origem do erro. Na maioria dos casos, o problema será com a entidade de destino externa e terá de comunicar a estes parceiros empresariais que precisam de configurar corretamente o DNSSEC e o DANE para receber e-mails de Exchange Online a utilizar estas normas.
A DNSSEC adiciona uma camada de confiança à resolução de DNS ao aplicar a infraestrutura de chave pública para garantir que os registos devolvidos em resposta a uma consulta DNS são autênticos. O DANE garante que o servidor de e-mail de receção é o servidor de e-mail legítimo e esperado para o registo MX autêntico.
O DANE e o MTA-STS servem o mesmo propósito, mas o DANE requer DNSSEC para autenticação DNS, enquanto o MTA-STS depende das autoridades de certificação.
O TLS oportunista encriptará a comunicação entre dois pontos finais se ambos concordarem em apoiá-la. No entanto, mesmo que o TLS encripte a transmissão, um domínio pode ser falsificado durante a resolução de DNS de forma a apontar para o ponto final de um ator malicioso em vez do ponto final real do domínio. Esta spoof é uma lacuna na segurança de e-mail que é resolvida através da implementação de MTA-STS e/ou SMTP DANE com DNSSEC.
DNSSEC não é totalmente resistente a ataques Man-in-the-Middle e ataques de mudança para uma versão anterior (do TLS para limpar texto) para cenários de fluxo de correio. A adição de MTA-STS e DANE, juntamente com a DNSSEC, fornece um método de segurança abrangente para impedir ataques MITM e de mudança para uma versão anterior.
Localizar e corrigir problemas após a adição do seu domínio ou de registros DNS
Descrição geral do DNSSEC | Microsoft Docs
Utilizar o DMARC para validar o e-mail, passos de configuração - Office 365 | Microsoft Docs
Como utilizar o DKIM para e-mail no seu domínio personalizado - Office 365 | Microsoft Docs
Como o Sender Policy Framework (SPF) impede o spoofing - Office 365 | Microsoft Docs
Exchange Online Transport News da Microsoft Ignite 2020 - Microsoft Tech Community