O problema: STARTTLS é oportunista
A maioria do correio entre servidores é criptografada com STARTTLS, uma extensão SMTP que atualiza a conexão de texto simples para TLS. No entanto, o STARTTLS tem uma falha fundamental: é oportunista. Se a negociação TLS falhar por qualquer motivo — um atacante bloqueando o comando STARTTLS, um certificado expirado, um erro de configuração — a maioria dos servidores remetentes prossegue em texto simples, enviando os e-mails sem criptografia. Um atacante posicionado na rede (man-in-the-middle) pode simplesmente interceptar o comando STARTTLS e forçar a conexão em texto simples, lendo todos os e-mails em trânsito.
O MTA-STS (Mail Transfer Agent Strict Transport Security, RFC 8461) resolve esse problema permitindo que o domínio destinatário declare: "os e-mails para meu domínio devem ser entregues apenas por meio de conexões TLS válidas". Se o servidor remetente suporta MTA-STS e a negociação TLS falha, o e-mail não é enviado em texto simples — ele é retido e o remetente é notificado. Isso elimina a possibilidade de ataques de downgrade.
Como o MTA-STS funciona
O MTA-STS requer dois componentes: um registro DNS TXT em _mta-sts.dominio.com que sinaliza a presença da política e inclui um ID único (tipicamente um carimbo de data/hora) que é atualizado a cada alteração, e um arquivo de política servido via HTTPS em https://mta-sts.dominio.com/.well-known/mta-sts.txt. O fato de a política ser servida via HTTPS (e não DNS) adiciona uma camada extra de segurança: um atacante também precisaria comprometer o certificado HTTPS para falsificar a política.
A política especifica: a versão (STSv1), o modo (testing ou enforce), os hostnames dos servidores de correio autorizados (mx:) e a duração do cache da política (max_age em segundos). O modo testing reporta problemas nos relatórios TLS-RPT sem bloquear a entrega, permitindo identificar e resolver problemas antes de mudar para enforce.
MTA-STS e TLS-RPT: o par perfeito
MTA-STS sem TLS-RPT Lookup é como um sistema de segurança sem alarme: bloqueia os problemas, mas não avisa você. O TLS-RPT (RFC 8460) fornece relatórios detalhados sobre falhas TLS, permitindo monitorar quantas conexões TLS são bem-sucedidas, quantas falham e por quê. Configure sempre o TLS-RPT juntamente com o MTA-STS para ter visibilidade completa sobre a segurança das conexões de entrada de e-mail.
Nosso MTA-STS Lookup verifica ambos os componentes: o registro DNS e a política HTTPS. Ele confere se o registro existe e possui um ID válido, se o arquivo de política está acessível via HTTPS com um certificado válido, se os servidores MX na política correspondem aos registros MX reais do domínio e se o modo e o max_age estão configurados corretamente.
Implementação passo a passo
Implementar o MTA-STS requer um servidor web HTTPS para servir a política. Se você já possui um site para o domínio, pode criar um subdomínio mta-sts.seudominio.com com um certificado SSL válido. Alternativamente, serviços como Cloudflare Workers ou GitHub Pages podem hospedar o arquivo de política gratuitamente. O certificado HTTPS deve ser válido e emitido por uma CA pública — certificados autoassinados não são aceitos.
Comece com mode: testing para coletar dados sem impactar a entrega. Monitore os relatórios TLS-RPT por pelo menos 2 semanas. Verifique se seu certificado SSL Check é válido e se seus servidores MX suportam TLS 1.2+. Após confirmar que não há problemas, passe para mode: enforce. Atualize o ID no registro DNS a cada alteração de política para forçar a atualização do cache nos servidores remetentes.