MTA-STS

Este guia faz parte do nosso guia sobre autenticação de e-mail. Relacionados: MTA-STS e DKIM vs DMARC.

O MTA-STS (SMTP MTA Strict Transport Security) é um padrão que permite a um domínio exigir que o correio de entrada seja entregue por TLS criptografado e autenticado, prevenindo ataques de rebaixamento (downgrade) e de intermediário (man-in-the-middle). O TLS-RPT é o seu padrão de relatórios complementar, coletando relatórios diários sobre falhas de TLS na entrega. O MTA-STS protege a camada de transporte, complementando SPF, DKIM e DMARC, que autenticam o remetente em vez da conexão.

O problema que o MTA-STS resolve

Quando dois servidores de correio trocam mensagens por SMTP, eles normalmente negociam a criptografia usando STARTTLS. O problema é que o STARTTLS é oportunista: o servidor de envio pergunta se o receptor suporta TLS e, se a resposta for não, ele silenciosamente recorre ao texto simples (plaintext). Essa pergunta e resposta acontecem em texto aberto, o que significa que um atacante posicionado entre os dois servidores pode remover o comando STARTTLS da conversa. O servidor de envio então acredita que o receptor não tem suporte a TLS e entrega a mensagem sem criptografia, ou se conecta a um servidor impostor apresentando um certificado forjado.

Esses são conhecidos como ataques de rebaixamento (downgrade) e de intermediário (man-in-the-middle). Como o SMTP foi projetado priorizando a interoperabilidade e a segurança depois, historicamente não havia uma forma de um domínio receptor dizer “sempre criptografe o correio para mim, e recuse a entrega se não puder”. O MTA-STS preenche exatamente essa lacuna. Ele permite que um domínio publique uma política declarando que o correio de entrada deve ser entregue por TLS, usando um certificado válido que corresponda a um dos seus hosts MX publicados. Os servidores de envio que suportam MTA-STS honram a política e adiarão ou devolverão (bounce) uma mensagem em vez de enviá-la em texto aberto.

Como o MTA-STS funciona

O MTA-STS depende de duas peças trabalhando juntas: um registro TXT de DNS que anuncia a política, e um arquivo de política hospedado via HTTPS que a define.

Primeiro, publique um registro TXT em _mta-sts.yourdomain.com. Esse registro sinaliza que uma política existe e carrega um ID que muda sempre que você atualiza a política, para que os servidores de envio saibam quando buscá-la novamente.

_mta-sts.yourdomain.com.  IN  TXT  "v=STSv1; id=20260910T120000;"

Segundo, sirva o arquivo de política via HTTPS em um local fixo e bem conhecido: https://mta-sts.yourdomain.com/.well-known/mta-sts.txt. O requisito de HTTPS importa porque o certificado naquele host prova que a política é autêntica e não foi adulterada em trânsito.

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

As linhas mx listam cada hostname autorizado a receber o seu correio, correspondendo aos seus registros MX. max_age diz aos servidores de envio por quanto tempo armazenar a política em cache, em segundos (604800 é uma semana). Um cache mais longo é mais resistente a um atacante que consiga manipular o DNS brevemente, então um valor de pelo menos alguns dias é recomendado assim que você estiver confiante na sua configuração.

Modo enforce vs testing

O campo mode no arquivo de política controla com que rigor a política é aplicada, e é o botão mais importante ao implantar o MTA-STS.

Comece com mode: testing. No modo testing, os servidores de envio avaliam a sua política, mas nunca bloqueiam a entrega quando ela falha. Em vez disso, combinados com o TLS-RPT abaixo, eles reportam as falhas de volta a você. Isso permite que você descubra hosts MX mal configurados, certificados expirados, ou incompatibilidades de hostname sem nunca perder uma mensagem legítima.

Assim que os seus relatórios voltarem limpos por uma ou duas semanas, mude para mode: enforce. Agora os servidores de envio se recusarão a entregar correio que não possa ser enviado por TLS autenticado a um host MX listado. Um terceiro valor, mode: none, efetivamente desativa a política e é usado para aposentar o MTA-STS de forma graciosa. Sempre passe de testing para enforce deliberadamente, nunca o contrário com pressa.

TLS-RPT: relatórios

O MTA-STS por si só não lhe diz nada sobre como está indo a entrega. O TLS-RPT (SMTP TLS Reporting) é o canal de retorno. Você publica um segundo registro TXT em _smtp._tls.yourdomain.com nomeando um endereço que deve receber os relatórios agregados.

_smtp._tls.yourdomain.com.  IN  TXT  "v=TLSRPTv1; rua=mailto:tls-reports@yourdomain.com"

Os servidores de envio participantes lhe enviam um relatório JSON diário resumindo as sessões TLS bem-sucedidas e as que falharam para o seu domínio, incluindo o motivo de cada falha, como um certificado que não validou ou uma negociação STARTTLS que foi removida. Esses relatórios são o que tornam o modo testing útil, e permanecem valiosos no modo enforce como um sistema de alerta antecipado para expiração de certificado ou mudanças de MX. Muitas equipes direcionam o endereço rua para um painel de monitoramento em vez de uma caixa de entrada humana.

Onde ele se encaixa junto ao SPF, DKIM e DMARC

É fácil agrupar o MTA-STS com os outros acrônimos, mas ele resolve um problema diferente. SPF, DKIM e DMARC autenticam o remetente, respondendo “esta mensagem é realmente do domínio que ela afirma?” O MTA-STS protege a conexão, respondendo “esta mensagem está sendo entregue de forma privada e ao servidor certo?” Você quer ambos. Uma mensagem pode estar perfeitamente autenticada e ainda ser interceptada em trânsito, e uma conexão perfeitamente criptografada ainda pode carregar uma mensagem falsificada.

Para o quadro completo da autenticação de remetente, veja o nosso guia sobre autenticação de e-mail. O MTA-STS combina naturalmente com esses padrões como um acréscimo na camada de transporte e, uma vez que você os tenha implementados, o BIMI é outra camada avançada que vale a pena considerar, permitindo exibir um logotipo de marca verificado em caixas de entrada compatíveis.

Perguntas Frequentes

O que é o MTA-STS?

O MTA-STS (SMTP MTA Strict Transport Security) é um padrão que permite a um domínio exigir que o e-mail de entrada seja entregue por TLS criptografado e autenticado. Ele publica um registro de DNS e um arquivo de política hospedado via HTTPS para que os servidores de envio imponham a criptografia e se recusem a recorrer ao texto simples, bloqueando ataques de rebaixamento (downgrade) e de intermediário (man-in-the-middle) contra o SMTP.

Qual é a diferença entre MTA-STS e TLS-RPT?

O MTA-STS é o padrão de imposição: ele define a política que exige a entrega via TLS. O TLS-RPT é o padrão de relatórios: ele define um registro de DNS e um formato de relatório JSON para que os servidores de envio lhe enviem resumos diários dos sucessos e falhas de entrega via TLS. Você os implanta juntos, usando o TLS-RPT para validar com segurança uma política MTA-STS antes de impô-la.

O MTA-STS é obrigatório?

Não, o MTA-STS não é obrigatório, e o e-mail funciona sem ele. No entanto, ele é fortemente recomendado para qualquer domínio que lide com correio sensível, porque fecha uma lacuna real que SPF, DKIM e DMARC não abordam. Implantá-lo primeiro em modo testing não traz risco de entrega, então há pouca razão para não adotá-lo.

O MTA-STS substitui SPF, DKIM ou DMARC?

Não. O MTA-STS opera em uma camada diferente. SPF, DKIM e DMARC autenticam o remetente e detectam a falsificação, enquanto o MTA-STS protege a conexão de transporte para que o correio seja entregue de forma privada ao servidor correto. Eles são controles complementares, e um domínio bem protegido implanta todos eles juntos, em vez de escolher um em detrimento de outro.