Em 2015, pesquisadores demonstraram algo que deveria ter aterrorizado qualquer empresa que lida com emails sensíveis: eles conseguiam interceptar emails entre grandes corporações explorando uma fraqueza fundamental na forma como servidores de email negociam a criptografia. O ataque era elegante em sua simplicidade. Quando dois servidores de email se conectam, tentam fazer upgrade para uma conexão criptografada usando STARTTLS. Mas se um atacante se coloca entre eles, pode simplesmente remover a oferta de criptografia, forçando ambos os servidores a se comunicarem em texto simples.
Os servidores não reclamam. Não alertam ninguém. Eles apenas dão de ombros e enviam seus contratos confidenciais, registros médicos e demonstrativos financeiros pela internet em texto claro, legível por qualquer um que esteja observando.
MTA-STS—Mail Transfer Agent Strict Transport Security—existe para evitar exatamente esse cenário.
O problema do STARTTLS
Para entender por que o MTA-STS importa, é preciso entender como a criptografia de email normalmente funciona — e por que ela é surpreendentemente frágil.
Quando seu servidor de email quer entregar uma mensagem para outro domínio, ele se conecta ao servidor de email do destinatário na porta 25. Essa conexão inicial é não criptografada. Os servidores então negociam: "Ei, você suporta criptografia?" Se ambos concordam, fazem upgrade para TLS e prosseguem de forma segura.
Isso é chamado de criptografia oportunista, e tem uma falha fatal. A negociação acontece em um canal não criptografado. Um atacante realizando um ataque man-in-the-middle pode interceptar a mensagem "Eu suporto TLS" e substituí-la por "Eu não suporto TLS". Ambos os servidores acham que o outro não faz criptografia, então prosseguem em texto simples.
Isso não é teórico. Pesquisadores de segurança documentaram ISPs e Estados-nação realizando ativamente esses ataques de downgrade. Em alguns países, isso é rotina. Seu email pode estar criptografado quando sai do seu servidor e criptografado quando chega ao destino, mas em algum ponto no meio, alguém leu cada palavra.
Como o MTA-STS resolve isso
O MTA-STS adota uma abordagem simples: ele permite que donos de domínios publiquem uma política dizendo "sempre exija TLS ao entregar emails para nós, e aqui estão exatamente quais servidores você deve conectar".
A política é publicada em dois lugares. Primeiro, um registro DNS anuncia que o domínio usa MTA-STS. Segundo, um arquivo de política hospedado via HTTPS especifica os requisitos exatos. A parte do HTTPS é crucial — significa que a própria política é entregue por um canal criptografado e autenticado que não pode ser adulterado.
Quando um servidor de email remetente quer entregar para um domínio com MTA-STS habilitado, ele primeiro verifica o registro DNS. Se presente, busca o arquivo de política via HTTPS. A política diz: exija TLS versão 1.2 ou superior, verifique se o certificado corresponde a estes padrões e conecte-se apenas a estes servidores de email específicos.
Se qualquer um desses requisitos não puder ser atendido — se a conexão não puder ser criptografada, se o certificado for inválido, se o nome do servidor não corresponder — o servidor remetente se recusa a entregar o email. Ele não volta para texto simples. Ele falha de maneira explícita.
Configurando o MTA-STS
Implementar MTA-STS requer três componentes: um registro DNS, um arquivo de política e um servidor web para hospedar essa política.
O registro DNS é um registro TXT em _mta-sts.yourdomain.com. Ele se parece com isto: "v=STSv1; id=20240115". O campo 'id' é um identificador de versão — você o altera sempre que atualizar sua política, o que informa aos servidores remetentes para buscar a nova versão.
O arquivo de política fica em https://mta-sts.yourdomain.com/.well-known/mta-sts.txt. Observe o subdomínio — você precisa de um certificado HTTPS válido para mta-sts.yourdomain.com. O arquivo contém sua política em um formato de texto simples.
Uma política típica especifica a versão, o modo (testing ou enforce), a idade máxima em segundos que os remetentes devem armazenar em cache a política, e os hostnames de MX que são válidos para seu domínio. O max_age é importante — valores maiores significam melhor proteção contra ataques, mas recuperação mais lenta se você precisar mudar algo.
Modo testing vs modo enforce
O MTA-STS suporta dois modos, e a diferença importa enormemente.
No modo testing, servidores remetentes buscam e avaliam sua política, mas não a aplicam de fato. Se uma conexão falharia pela política, eles entregam o email mesmo assim — mas enviam um relatório dizendo o que aconteceu. Isso permite identificar problemas antes que causem falhas de entrega.
No modo enforce, a política é obrigatória. Conexões que não atendem aos requisitos falham, e o email não é entregue. Essa é proteção real, mas também é risco real se sua política estiver errada.
A abordagem inteligente é começar em modo testing com um max_age curto. Monitore os relatórios por algumas semanas. Procure servidores de email legítimos que não conseguem atender aos seus requisitos — talvez um sistema de parceiro antigo com uma implementação de TLS desatualizada, ou um MX de backup mal configurado. Corrija esses problemas, então mude para modo enforce com um max_age mais longo.
Relatórios: TLSRPT
O MTA-STS funciona de mãos dadas com TLSRPT — TLS Reporting. Este é um registro DNS separado que informa aos servidores remetentes para onde enviar relatórios sobre tentativas de conexão TLS.
Os relatórios incluem sucessos e falhas: quais servidores conectaram, qual versão de TLS usaram, se a validação de certificado passou e, se algo falhou, por quê. Essa visibilidade é inestimável. Sem ela, você está voando às cegas — não saberá se atacantes estão tentando downgrades ou se remetentes legítimos estão tendo problemas.
Configurar TLSRPT é simples: adicione um registro TXT em _smtp._tls.yourdomain.com especificando para onde enviar relatórios. Você pode recebê-los via email ou HTTPS POST. Vários serviços agregam e visualizam esses relatórios para você, tornando muito mais fácil identificar padrões.
Erros comuns de implementação
O erro de MTA-STS mais frequente é problema de certificado. Seu subdomínio mta-sts precisa de um certificado válido, e seus servidores de email precisam de certificados válidos com hostnames que correspondam à sua política. Let's Encrypt torna isso fácil, mas você precisa lembrar de incluir o subdomínio mta-sts no seu processo de renovação de certificados.
Outro problema comum é desencontro nos registros de MX. Sua política de MTA-STS lista hostnames específicos, e seus registros de MX precisam corresponder exatamente. Se seu MX aponta para mail.example.com mas sua política lista mx1.example.com, conexões falharão em modo enforce.
Esquecer de atualizar o ID da política também derruba muita gente. Quando você altera seu arquivo de política, deve também atualizar o ID no seu registro DNS. Servidores remetentes armazenam políticas em cache com base no ID — se você não o mudar, eles não buscarão suas atualizações.
Por fim, definir max_age alto demais cedo demais é arriscado. Se você publicar uma política com max_age de um ano e depois descobrir um problema, servidores remetentes aplicarão a política quebrada por até um ano. Comece com horas ou dias, não meses.
MTA-STS vs DANE
Você pode ter ouvido falar de DANE (DNS-based Authentication of Named Entities) como outra solução para o mesmo problema. Ambos evitam ataques de downgrade de TLS, mas funcionam de maneiras diferentes.
DANE usa DNSSEC para autenticar certificados TLS. É talvez mais elegante — tudo vive no DNS, sem necessidade de servidor web. Mas a adoção de DNSSEC ainda é limitada, e muitos provedores de DNS não o suportam bem. MTA-STS foi projetado como uma alternativa mais implantável que funciona com a infraestrutura existente.
Na prática, MTA-STS teve adoção muito mais ampla. Google, Microsoft e a maioria dos grandes provedores de email o suportam. Se você está escolhendo entre eles, MTA-STS é a opção pragmática. Se seu foco é segurança e você já tem DNSSEC, implementar ambos fornece defesa em profundidade.
Vale o esforço?
MTA-STS exige mais configuração do que um simples registro DNS. Você precisa hospedar um arquivo de política, manter certificados, monitorar relatórios. Vale a pena?
Se você lida com emails sensíveis — serviços financeiros, saúde, jurídico ou qualquer negócio em que a interceptação de email seria catastrófica — sim, absolutamente. O ataque que ele previne é real e ativamente explorado. O custo de configuração são algumas horas; a proteção é contínua.
Para organizações menores com emails menos sensíveis, é uma questão de julgamento. A boa notícia é que, à medida que mais domínios adotam MTA-STS, o ecossistema fica mais seguro para todos. Atacantes não conseguem fazer downgrade seletivo das conexões quando a maior parte da internet se recusa a aceitar downgrades.
Frequently asked questions
O MTA-STS protege o conteúdo do email ponta a ponta?
Não. O MTA-STS protege o email em trânsito entre servidores de email, mas o email é descriptografado em cada servidor. Para criptografia ponta a ponta de verdade, você precisa de S/MIME ou PGP. MTA-STS e criptografia ponta a ponta resolvem problemas diferentes e podem ser usados juntos.
O que acontece se meu arquivo de política MTA-STS ficar indisponível?
Se os remetentes não conseguem buscar sua política via HTTPS, eles voltam à criptografia oportunista — o mesmo que se você não tivesse MTA-STS. É por isso que a confiabilidade da hospedagem importa. Considere usar um CDN ou hospedagem redundante para o arquivo de política.
Todos os provedores de email suportam MTA-STS?
A maioria dos provedores grandes suporta, incluindo Gmail, Outlook, Yahoo e outros. Contudo, alguns servidores de email menores ou antigos não suportam. Verifique os relatórios TLSRPT para ver quais remetentes estão avaliando sua política.
O MTA-STS pode causar falhas na entrega de email?
Em modo enforce, sim — esse é o objetivo. Se um servidor remetente não consegue estabelecer uma conexão segura que atenda aos requisitos da sua política, o email não será entregue. É por isso que modo testing e monitoramento são essenciais antes de aplicar.