Gerador de Política MTA-STS

MTA-STS: TLS obrigatório no SMTP de entrada

O MTA-STS (Mail Transfer Agent — Strict Transport Security) é o equivalente do HSTS para transporte de e-mail, padronizado pela IETF na RFC 8461 em 2018. O SMTP historicamente negociava criptografia de forma oportunista via STARTTLS, o que significa que um atacante no caminho pode simplesmente remover a resposta STARTTLS e forçar o servidor remetente a cair para texto puro. O MTA-STS fecha esse buraco: o domínio receptor publica uma política declarando "você precisa usar TLS, precisa validar meu certificado, e esses são meus MX válidos" — e os remetentes compatíveis cacheiam e impõem essa regra.

A implantação tem três partes:

• Um registro DNS TXT em _mta-sts.example.com anunciando que a política existe e carregando um id opaco.
• Um endpoint HTTPS em https://mta-sts.example.com/.well-known/mta-sts.txt servindo o arquivo de política com certificado público válido (sem self-signed).
• Um arquivo de política listando o modo, os padrões de MX e um max_age para o cache.

O registro DNS e o arquivo de política

_mta-sts.example.com.  IN  TXT  "v=STSv1; id=20260101120000Z"

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

O id dentro do TXT é o token que invalida o cache: quando você troca o conteúdo do arquivo, precisa atualizar o id (um timestamp dá certo) para que os remetentes baixem de novo em vez de continuarem servindo a cópia cacheada até o max_age expirar.

Modos de política: none, testing, enforce

none desativa o MTA-STS — usado para reverter uma política. testing faz os remetentes aplicarem a política, mas entregarem mesmo se houver falha, e ainda assim emitirem relatórios TLS-RPT (veja a ferramenta companheira). enforce instrui os remetentes a recusar a entrega se o certificado do MX, o hostname ou o handshake TLS falharem. O caminho padrão de rollout é deixar em testing por algumas semanas, observar o TLS-RPT atrás de surpresas e só então passar para enforce.

Adoção e realidade operacional

Google, Microsoft 365, Yahoo, ProtonMail, Fastmail e AWS SES respeitam MTA-STS como remetentes, e a maioria deles publica a própria política como receptores. Grandes provedores e ESPs brasileiros estão atrás na adoção, o que é uma oportunidade de entregabilidade para times preocupados com segurança. O custo é praticamente zero — um registro TXT, um subdomínio na sua infra HTTPS existente e um arquivo de cinco linhas — e o retorno é fechar o ataque mais explorado de downgrade no SMTP.

Padrões companheiros. O DANE (RFC 7672) faz algo parecido, mas amarra certificados via registros TLSA assinados com DNSSEC; é mais rigoroso e bem menos adotado porque o DNSSEC não é universal. A maioria escolhe MTA-STS por pragmatismo. O TLS-RPT (RFC 8460) é o canal de relatórios e quase sempre é implantado junto.

Perguntas frequentes

Preciso disso num domínio de e-mail pequeno? Estritamente não, mas é o reforço TLS mais barato que dá para comprar — um único TXT mais um arquivo estático. Se você já publica HTTPS, vale a pena.

E se o arquivo de política sumir? Remetentes que já cachearam a política continuam impondo-a até o max_age expirar. Novos remetentes não veem política nenhuma e caem no TLS oportunista. Por isso o max_age costuma ser de uma semana ou mais em produção.

Como faço para testar? Use hardenize.com, mxtoolbox.com ou aykira.com.au/mta-sts-checker. Eles buscam o TXT, o arquivo de política e validam a lista de MX e o certificado.

Quais são as falhas mais comuns? A URL em .well-known respondendo 404, certificado self-signed no subdomínio da política, MX faltando na lista da política, ou esquecer de bumpar o id depois de editar o arquivo.