Verificador de política MTA-STS
Obtém o registro TXT _mta-sts e o arquivo de política mta-sts.txt de um domínio para diagnosticar se a criptografia TLS obrigatória no transporte de e-mail (MTA-STS) está configurada corretamente.
Dicas
- O MTA-STS é verificado pelo servidor que envia o e-mail, não pelo que o recebe. Ao publicá-lo, os servidores de terceiros passam a exigir TLS ao enviar e-mails para o seu domínio.
- Implante primeiro em modo testing por algumas semanas a um mês antes de mudar para enforce, para não ser pego de surpresa por rejeições de entrega inesperadas.
- O max_age costuma ser definido entre 604800 segundos (7 dias) e 31557600 segundos (1 ano). Um valor curto demais obriga a buscar o arquivo de política com mais frequência.
- É possível usar um curinga (*.example.com) no campo mx, mas o SAN (Subject Alternative Name) do certificado TLS precisa corresponder a esse curinga.
- Publicar apenas o registro DNS ou apenas o arquivo de política não tem efeito algum — o MTA-STS só entra em vigor quando ambos estão presentes ao mesmo tempo.
Perguntas frequentes
Curiosidade — Por que o STARTTLS não bastava e como surgiu o MTA-STS
Por décadas, a criptografia em trânsito do SMTP dependeu do STARTTLS (padronizado em 1999), que abre a conexão em texto puro e só depois a atualiza para TLS. Em 2014, pesquisadores confirmaram ataques reais de "STARTTLS stripping": como a própria negociação do STARTTLS ocorre antes de a criptografia entrar em ação, um atacante no caminho podia reescrever a resposta do servidor para esconder seu suporte ao STARTTLS, enganando o outro lado para que voltasse ao texto puro.
A causa raiz era o STARTTLS ter sido projetado deliberadamente para recuar ao texto puro quando o outro lado não suportava TLS — um recurso de compatibilidade que os atacantes podiam explorar simplesmente fingindo que não havia suporte a TLS. Por volta de 2015, medições do próprio Google mostraram que o STARTTLS stripping ocorria em larga escala em certos países e provedores.
O MTA-STS (RFC 8461, publicado em 2018) foi a resposta da indústria, desenvolvida em conjunto por Google, Microsoft, Yahoo e outros. Um domínio declara suporte ao MTA-STS por meio de um registro TXT no DNS e publica um arquivo de política obtido via HTTPS, listando os hosts MX permitidos e os requisitos de TLS. Uma vez obtida, a política fica em cache pelo período de max_age, de modo que uma tentativa posterior de downgrade pode ser detectada e rejeitada em vez de aceita silenciosamente.
O MTA-STS costuma ser combinado com o TLS-RPT (TLS Reporting, RFC 8460), que permite aos donos de domínio receber relatórios sempre que um servidor remetente falha ao estabelecer TLS. O MTA-STS cuida da camada de aplicação forçada; o TLS-RPT, da observabilidade. Usar os dois juntos é a prática recomendada atualmente.