Aprimorando o fluxo de emails com o MTA-STS

Artigo
01/15/2025

O suporte para o padrão SMTP MTA Strict Transport Security (MTA-STS) foi adicionado ao Exchange Online. O padrão foi desenvolvido para garantir que o TLS seja sempre usado para conexões entre servidores de email. Ele também fornece uma maneira de enviar servidores para validar se o servidor de recebimento possui um certificado confiável. Se o TLS não for oferecido ou o certificado não for válido, o remetente se recusará a entregar as mensagens. Essas novas verificações melhoram a segurança geral do SMTP e protegem contra ataques man-in-the-middle.

O MTA-STS pode ser dividido em dois cenários: proteção de Entrada e de Saída. A proteção de entrada abrange a proteção de domínios alojados no Exchange Online com MTA-STS. A proteção de saída abrange as validações MTA-STS executadas por Exchange Online ao enviar e-mails para domínios protegidos por MTA-STS.

Dica

Se você não é um cliente E5, use a avaliação das soluções do Microsoft Purview de 90 dias para explorar como os 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 do Microsoft Purview. Saiba mais detalhes sobre os termos de inscrição e avaliação.

Proteção de Saída

Todas as mensagens enviadas de saída de Exchange Online para destinatários protegidos por MTA-STS estão a ser validadas com estas verificações de segurança adicionais definidas pela norma MTA-STS. Não há nada que os administradores precisem de fazer para o aplicar. Nossa implementação de saída respeita os desejos dos proprietários de domínio do destinatário por meio de sua política MTA-STS. O MTA-STS faz parte da infraestrutura de segurança do Exchange Online e, portanto, está sempre ativado (como outras funcionalidades principais do SMTP).

O MTA-STS de saída pode impedir a entrega de e-mails consoante os resultados da validação MTA-STS relativamente ao domínio de destino. Se o domínio não for seguro e a política MTA-STS estiver definida como Impor, um NDR poderá ser devolvido ao remetente com um dos seguintes códigos de erro:

Código de erro	Descrição	Causa possível	Informações adicionais
5.4.8	Os anfitriões MX de "{domain}" falharam a validação MTA-STS	O anfitrião MX de destino não era o anfitrião esperado de acordo com a política de STS do domínio.	Normalmente, este erro indica um problema com a política MTA-STS do domínio de destino que não contém o anfitrião MX. Para obter mais informações sobre o MTA-STS, consulte https://datatracker.ietf.org/doc/html/rfc8461.
5.7.5	Falha no certificado remoto de validação MTA-STS. Motivo: {validityStatus}	O certificado do servidor de correio de destino tem de ser ligado a uma Autoridade de Certificação de raiz fidedigna e o Nome Comum ou Nome Alternativo do Requerente tem de conter uma entrada para o nome do anfitrião na política STS.	Normalmente, este erro indica um problema com o certificado do servidor de correio de destino. Para obter mais informações sobre o MTA-STS, consulte https://datatracker.ietf.org/doc/html/rfc8461.

Proteção de Entrada

Os proprietários de domínio podem tomar medidas para proteger os emails enviados para seus domínios com o MTA-STS, se o registro MX apontar para o Exchange Online. Se o seu registo MX apontar para um serviço intermediário de terceiros, terá de saber se os requisitos de MTA-STS são cumpridos por eles e, em seguida, seguir as instruções.

Assim que o MTA-STS estiver configurado para o seu domínio, quaisquer mensagens enviadas de remetentes que suportem o MTA-STS realizarão as validações estabelecidas pelo padrão para garantir uma conexão segura. Se você estiver recebendo um email de um remetente que não oferece suporte ao MTA-STS, o email ainda será entregue sem a proteção extra. Da mesma forma, não há interrupção nas mensagens se você ainda não estiver usando o MTA-STS, mas o remetente o suportar. O único cenário em que as mensagens não são entregues é quando ambos os lados estão usando o MTA-STS e a validação do MTA-STS falha.

Como adotar o MTA-STS

O MTA-STS permite que um domínio declare suporte para TLS e comunique o registro MX e o certificado de destino esperado. Também indica o que um servidor de envio tem de fazer se houver um problema. Esta comunicação é efetuada através de uma combinação de um registo TXT de DNS e de um ficheiro de política publicado como uma página Web HTTPS. A política protegida por HTTPS apresenta outra proteção de segurança que os invasores devem superar.

O registro TXT do MTA-STS de um domínio indica suporte ao MTA-STS para um remetente, após o qual a política do MTA-STS baseada em HTTPS do domínio é recuperada pelo remetente. O registo TXT deve conter v=STSv1; até o STSv2 ser suportado e o ID da política. O ID TEM de ser exclusivo para o proprietário e a política do domínio, como uma alteração nos sinais de ID aos remetentes de que precisam para obter novamente a política. O ID não tem de ser globalmente exclusivo, não se preocupe com os IDs de política de outros proprietários de domínios. Após qualquer atualização da política MTA-STS, tem de atualizar o ID ou os remetentes continuarão a utilizar políticas em cache para o seu domínio até que a max_age da política em cache expire.

Um padrão repetível para definir um ID exclusivo é utilizar a hora UTC como tal:
id=<yyyymmddhh0000>Z;

O seguinte registo TXT é um exemplo que declara suporte para MTA-STS, o ID foi definido às 8:00 de 1 de janeiro de 2022 hora UTC:

_mta-sts.contoso.com. 3600 IN TXT v=STSv1; id=20220101080000Z;

A política MTA-STS de um domínio precisa estar localizada em uma URL predefinida e hospedada pela infraestrutura da Web do domínio. A sintaxe do URL é https://mta-sts.<domain name>/.well-known/mta-sts.txt. Por exemplo, a política da Microsoft.com pode ser encontrada em: https://mta-sts.microsoft.com/.well-known/mta-sts.txt.

version: STSv1
mode: enforce
mx: *.mail.protection.outlook.com
max_age: 604800

Qualquer cliente cujos registos MX apontem diretamente para Exchange Online pode especificar na sua própria política os mesmos valores que são mostrados em https://mta-sts.microsoft.com/.well-known/mta-sts.txt. As informações exclusivas necessárias na política são o registo MX que aponta para Exchange Online (*.mail.protection.outlook.com) e o mesmo certificado é partilhado por todos os clientes Exchange Online. Exchange Online só permite que uma organização receba e-mails para um determinado domínio para que a utilização de um caráter universal não enfraqueca a segurança; no entanto, isso pode não ser o caso de outros serviços de e-mail. É possível publicar a política no modo de teste para garantir que é válida antes de a alterar para o modo de imposição . Existem ferramentas de validação de terceiros que podem verificar sua configuração.

Estas políticas não são algo que Exchange Online possam alojar em nome dos clientes, pelo que os clientes têm de configurar a política de STS do seu domínio com os serviços que preferem. Os serviços do Azure podem ser facilmente utilizados para o alojamento de políticas e existe uma orientação de configuração mais adiante neste artigo. A política precisa ser protegida por HTTPS com um certificado para o subdomínio mta-sts.<domain name>.

Assim que o registo TXT de DNS for criado e o ficheiro de política estiver disponível no URL HTTPS necessário, o domínio será protegido por MTA-STS. Os detalhes sobre o MTA-STS estão disponíveis no RFC 8461.

Configurar o MTA-STS de Entrada com os Serviços do Azure

Observação

Estes fluxos de configuração foram desenvolvidos para ajudar Microsoft Exchange Online clientes a alojar a política MTA-STS com os recursos do Azure. Este fluxo de configuração pressupõe que é um cliente Exchange Online que tem conhecimento de como o MTA-STS funciona e dos respetivos requisitos. Para obter mais informações sobre o protocolo para além deste tópico, veja RFC8461.

Existem dois recursos do Azure que podem ser utilizados para alojar a política MTA-STS: Aplicação Web Estática do Azure e Azure Functions. Embora este artigo descreva como implementar a política com ambos os recursos, o método recomendado é a Aplicação Web Estática do Azure , uma vez que foi concebido para alojar páginas estáticas, como a política sts, e o Azure simplifica a configuração ao fornecer um certificado TLS para a página Web MTA-STS fora da caixa, sem que seja necessária mais configuração. Se não conseguir utilizar a Aplicação Web Estática do Azure, também pode alojar a sua política como código sem servidor com Azure Functions. Esta abordagem não é o método preferencial porque Azure Functions é uma funcionalidade concebida para outros cenários e não emite automaticamente um certificado TLS, ao contrário Aplicativos Web Estáticos do Azure. Assim, utilizar Azure Functions para MTA-STS requer que emita o seu próprio "mta-sts.[ o seu domínio]" certificado e vinculá-lo à função.

Independentemente da abordagem que tomou, recomendamos que valide se a política foi configurada corretamente e se o tempo de resposta é aceitável – o tempo limite por orientação de RFC é de 60 segundos.

Estes fluxos de configuração destinam-se a fornecer apenas informações técnicas sobre as funcionalidades do Azure que podem ser utilizadas para alojar a política MTA-STS e não fornecem informações sobre os custos ou os custos das funcionalidades do Azure. Se quiser saber os custos das funcionalidades do Azure, utilize a Calculadora de Preços do Azure.

Opção 1 (RECOMENDADO): Aplicação Web Estática do Azure

Crie uma organização do Azure DevOps ou utilize uma organização que já exista. Neste exemplo, será utilizada uma organização denominada "ContosoCorporation" para alojar a política MTA-STS.
Em Ficheiros > de Repositório, clone o seu repositório em qualquer IDE que preferir. Neste exemplo, o repositório será clonado no Visual Studio.
Depois de clonar o repositório, crie o caminho home\.well-known\da pasta . Em seguida, crie os seguintes ficheiros:
- Ficheiro 1: home.well-known\mta-sts.txt
  
  Observação
  
  Esta configuração permite que apenas Exchange Online recebam mensagens em nome do seu domínio. Se estiver a utilizar vários fornecedores de e-mail, também terá de referenciar anfitriões MX para os domínios desses outros fornecedores. Os carateres universais ou "*" não podem ser utilizados como prefixo MX em todos os cenários MTA-STS; as definições abaixo são específicas apenas Exchange Online e NÃO devem ser utilizadas como orientação geral para configurar o MTA-STS.
  1. Introduza o seguinte texto no mta-sts.txt ficheiro:
```
version: STSv1
mode: testing
mx: *.mail.protection.outlook.com
max_age: 604800
```
    Observação
    
    Recomenda-se que o modo de política seja inicialmente definido como teste. Em seguida, no final da configuração e depois de validar que a política está a funcionar conforme esperado, atualize o mta-sts.txt ficheiro de forma a que o modo seja forçado.
    
    O ficheiro só tem de conter o conteúdo, conforme mostrado na seguinte captura de ecrã:
- Ficheiro 2: home\index.html
  1. Crie um index.html ficheiro e introduza o seguinte código no mesmo:
```
<!DOCTYPE html>
<html lang="en">

<head>
<meta charset="UTF-8">
<title>MTA-STS</title>
</head>

<body>
<h1>MTA-STS Static Website index</h1>
</body>

</html>
```
    O ficheiro só tem de conter o conteúdo, conforme mostrado na seguinte captura de ecrã:
    
    Assim que o caminho e os ficheiros da pasta forem criados, não se esqueça de consolidar as alterações e enviá-las para o ramo main.
Crie uma nova Aplicação Web Estática do Azure com a seguinte configuração:
- Nome: MTA-STS-StaticWebApp
- Tipo de plano: Standard
- Detalhes da Implementação: Azure DevOps
- Organização: ContosoCorporation
- Projeto: MTA-STS_Project
- Repositório: MTA-STS_Project
- Ramo: master
- Criar Predefinições: Angular
- Localização da Aplicação: /home
Assim que a criação da Aplicação Web Estática estiver concluída e o recurso for aprovisionado, aceda a Descrição Geral > Gerir token de implementação e, em seguida, copie o token como será utilizado no passo seguinte.
Aceda a Pipelines > Create Pipeline > Azure Repos Git > MTA-STS_Project e execute as seguintes subtarefas:
1. Aceda a Variáveis > Nova Variável e escreva o seguinte:
  1. Nome: token
  2. Valor: (cole o token que copiou anteriormente, no Passo 5)
2. Assim que a variável for guardada, regresse a Rever o YAML do pipeline e cole o seguinte yml, guarde-o e execute-o:
```
trigger:
- main

pool:
vmImage: ubuntu-latest

steps:
- checkout: self
submodules: true
- task: AzureStaticWebApp@0
inputs:
 app_location: '/home'
 azure_static_web_apps_api_token: $(token)
```
  No Azure DevOps, durante a implementação, se ocorrer o erro Nenhum paralelismo alojado foi comprado ou concedido, solicite através deste formulário ou implemente uma configuração através de Tarefas paralelas de Definições da Organização Tarefas paralelas >> da Microsoft Hosted > Change > Paid Parallel de modo a que sejam permitidas "Tarefas paralelas pagas".
Assim que a tarefa for concluída com êxito, pode validar a implementação através do portal do Azure acedendo ao Browser de Ambiente > da Aplicação > Web Estática do Azure. Tem de ver o index.html conteúdo do ficheiro.
Adicione o seu domínio intuitivo no Azure Static Web App Custom domains Add( Adicionar domínios personalizados > da Aplicação > Web Estática do Azure). Terá de criar um registo CNAME através do seu fornecedor de DNS (por exemplo, a GoDaddy) para validar se a zona lhe pertence. Quando a validação estiver concluída, o Azure emitirá um certificado e vinculará-o automaticamente à Aplicação Web Estática.
Valide se a política MTA-STS é publicada através de: https://mta-sts.[o seu domínio]/.bem conhecido/mta-sts.txt.
Crie o registo DNS TXT MTA-STS através do seu fornecedor de DNS. O formato é:
```
Hostname: _mta-sts.<domain name>
TTL: 3600 (recommended)
Type: TXT
Text: v=STSv1; id=<ID unique for your domain’s STS policy>Z;
```
Observação

Pode encontrar um registo TXT MTA-STS de exemplo em Como Adotar MTA-STS.
Assim que o registo TXT estiver disponível no DNS, valide a configuração MTA-STS. Assim que a configuração tiver sido validada com êxito, atualize o mta-sts.txt ficheiro para que o modo de política seja imposta e, em seguida, atualize o ID da política no registo TXT.

Opção 2: Função do Azure

Crie uma nova Aplicação de Funções do Azure com a seguinte configuração:
- Nome da Aplicação de Funções: [Como a sua escolha]
- Publicar: Código
- Pilha de runtime: .NET
- Versão: 6
- Sistema Operativo: Windows
- Tipo de Plano: [À sua escolha]
Adicione o seu domínio personalizado à Aplicação de Funções. Terá de criar um registo CNAME para validar se o domínio lhe pertence.
Vincular o seu "mta-sts. [o seu domínio]" para a Aplicação de Funções.
No Ficheiro de Aplicação, adicione a seguinte extensão à host.json da Aplicação de Funções para eliminar o routePrefix. Esta adição é necessária para remover a /api do URL da função.
```
"extensions": {
  "http": {
    "routePrefix": ""
  }
}
```
Na Aplicação de Funções, aceda a Funções > Criar e configurar os seguintes parâmetros:

Observação

Embora este exemplo descreva o desenvolvimento da função através do portal, pode utilizar o VS Code ou qualquer outra ferramenta que prefira.
- Ambiente de desenvolvimento: [À sua escolha; este exemplo utilizará "Desenvolver no Portal"]
- Selecionar um modelo: acionador HTTP
- Nova Função: [À sua escolha]
- Nível de autorização: Anónimo
Assim que a função for criada, abra Código + Teste e desenvolva em C# uma resposta HTTP assíncrona simples que será a sua política MTA-STS. O exemplo seguinte indica que Exchange Online deverá receber e-mails:

Observação

Recomenda-se que o modo de política seja inicialmente definido como teste. Em seguida, no final da configuração e depois de validar que a política está a funcionar conforme esperado, atualize o mta-sts.txt ficheiro de forma a que o modo seja forçado.
Em HTTP de Integração > (req), edite o acionador para os seguintes valores:
- Modelo de Rota: .well-known/mta-sts.txt
- Métodos HTTP selecionados: GET
Confirme que a política MTA-STS é publicada através de: https://mta-sts.[o seu domínio]/.bem conhecido/mta-sts.txt.
Crie o registo DNS TXT MTA-STS através do seu fornecedor de DNS no seguinte formato:
```
Hostname: _mta-sts.<domain name>
TTL: 3600 (recommended)
Type: TXT
Text: v=STSv1; id=<ID unique for your domain’s STS policy>Z;
```
Observação

Pode encontrar um registo TXT MTA-STS de exemplo em Como Adotar MTA-STS.
Assim que o registo TXT estiver disponível no DNS, valide a configuração MTA-STS. Assim que a configuração tiver sido validada com êxito, atualize o mta-sts.txt ficheiro de modo a que o modo de política seja imposta e, em seguida, atualize o ID da política no registo TXT.