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.
Diagnosticar o TLS obrigatório na entrega de correio (MTA-STS)
A cifragem no SMTP é de origem um assunto optativo, tentado onde se pode, o que significa que um atacante interposto que arranque o anúncio de STARTTLS pode forçar a troca até o texto plano. MTA-STS é o arranjo que fecha essa porta, **instruindo os servidores remetentes de que o correio para o domínio há de ir por TLS.** Esta ferramenta recolhe tanto o registro TXT `_mta-sts` quanto o arquivo de política, e comunica se a configuração está completa.
**O que confunde neste arranjo é que a política mesma não reside no DNS.** Quanto o registro TXT leva é um `id` que marca a versão; **a substância é servida por HTTPS a partir de `https://mta-sts.seudominio/.well-known/mta-sts.txt`.** A confiança deste mecanismo descansa, pois, nos certificados web e não no DNS. **E o ponto onde mais se emperra é deixar `mode` em `testing`.** Nesse estado a entrega prossegue apesar de uma falha de TLS, e **a obrigatoriedade só surte efeito uma vez que o valor seja `enforce`.** A ordem assentada de adoção consiste em permanecer em `testing`, observar os relatórios de TLS-RPT até ficar satisfeito de que nada se rompe, e só então passar a `enforce`.
Como se usa
- Insira o domínio Indique unicamente o domínio, na forma `example.com`.
- Confira o registro TXT **Busque `v=STSv1` e um `id=`.** O `id` muda-se a cada vez que a política é atualizada.
- Leia o conteúdo do arquivo de política Aparecem três entradas: `mx`, `max_age` e `mode`.
- Confirme o mode **Em `testing` não se está impondo nada.** Alcançar `enforce` é o que dá efeito à política.
Dicas para aproveitar melhor
- 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.
Quando é útil
Inspecionar o seu próprio domínio
**Como o mecanismo precisa ao mesmo tempo de DNS e HTTPS, você pode achar qual das duas metades falta.**
Conferir antes de passar a enforce
Os erros de configuração podem ser despejados enquanto se segue em `testing`.
Revisar depois de acrescentar um MX
**Esquecer de acrescentar um novo host MX à lista `mx` da política faz que se recuse a entrega a esse host.**
Saber até onde chegou um correspondente
Você pode ver se ele impõe TLS no seu próprio correio.
Termos de MTA-STS
- _mta-sts TXT
- **O registro DNS que leva o `id` marcador da versão da política.** A política mesma não reside aqui.
- Arquivo de política
- A substância, colocada em `https://mta-sts.seudominio/.well-known/mta-sts.txt`. **Ao ser servida por HTTPS, exige um certificado válido.**
- Mode
- Um de `enforce`, `testing` ou `none`. **Sob `testing` o correio é entregue ainda quando a verificação falhe.**
- Max_age
- Quantos segundos um remetente pode guardar a política em cache. Um valor maior reforça a proteção mas retarda a difusão de qualquer mudança.
- Mx
- A lista de hosts MX nos quais se há de impor TLS. **Recusa-se a entrega a um host ausente desta lista.**
- Degradação de STARTTLS
- O ataque em que um interposto arranca o anúncio de STARTTLS para forçar o texto plano. **MTA-STS foi ideado para impedi-lo.**
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.