De testing a enforce: estratégia de implantação progressiva do MTA-STS
Por CaptainDNS
Publicado em 10 de março de 2026
- MTA-STS em modo testing coleta relatórios TLS-RPT sem bloquear a entrega de e-mails, ideal para detectar problemas de configuração
- O modo enforce recusa qualquer conexão SMTP não cifrada com seus servidores MX, bloqueando ataques de downgrade
- A transição de testing para enforce ocorre em quatro etapas: implantação inicial, configuração TLS-RPT, análise dos relatórios (1 a 2 semanas), depois ativação do enforce
- Hospede sua política MTA-STS gratuitamente com o CaptainDNS: dois registros DNS são suficientes
Publicar uma política MTA-STS em modo enforce sem fase de teste equivale a ativar um firewall sem conhecer o tráfego legítimo. Resultado possível: e-mails bloqueados, parceiros que não conseguem mais escrever para você e nenhuma visibilidade sobre a causa. Segundo o Google Transparency Report, mais de 90 % do tráfego Gmail de entrada já utiliza TLS, mas sem MTA-STS nada garante que essa criptografia seja obrigatória em vez de oportunista.
O RFC 8461 prevê exatamente esse cenário. Ele define dois modos de funcionamento: testing (observar sem bloquear) e enforce (bloquear conexões não cifradas). A estratégia correta consiste em implantar primeiro em testing, monitorar os relatórios TLS-RPT durante uma a duas semanas, corrigir as anomalias e então mudar para enforce.
Este guia detalha cada etapa dessa transição. Ele é destinado a administradores de sistemas, DevOps e responsáveis pela segurança de e-mail que gerenciam um ou mais domínios de mensagens.
Entendendo os modos MTA-STS: testing vs enforce
O MTA-STS (RFC 8461) impõe a criptografia TLS para e-mails de entrada por meio de uma política HTTPS que contém três parâmetros: os servidores MX autorizados, a duração do cache (max_age) e o modo (testing ou enforce).
Modo testing: monitorar sem bloquear
O modo testing do MTA-STS permite que os servidores de envio (Gmail, Outlook, Yahoo) verifiquem sua política sem bloquear a entrega em caso de falha TLS. As anomalias são reportadas por meio de um relatório TLS-RPT (RFC 8460) enviado para o endereço que você configurou.
version: STSv1
mode: testing
mx: mx.captaindns.com
max_age: 86400
Esse modo permite detectar três tipos de problemas antes que afetem a entrega:
- Certificado TLS inválido: certificado expirado, nome de domínio incorreto ou cadeia de confiança incompleta
- MX não listado: um servidor MX responde aos e-mails mas não aparece na política
- Falha de negociação TLS: o servidor MX não suporta STARTTLS ou rejeita a conexão cifrada
Modo enforce: impor o ciframento TLS
O modo enforce do MTA-STS obriga os servidores de envio a recusar a entrega se a conexão TLS falhar ou se o servidor MX não constar na política.
version: STSv1
mode: enforce
mx: mx.captaindns.com
max_age: 604800
Esse modo oferece proteção real contra ataques de downgrade SMTP. Um atacante que tente remover o STARTTLS ou redirecionar para um servidor MX falso não conseguirá interceptar os e-mails: o servidor de envio recusará a entrega.
Etapa 1: implantar o MTA-STS em modo testing
A implantação inicial requer dois elementos DNS e um arquivo de política HTTPS.
Registro DNS TXT
Publique um registro TXT em _mta-sts.captaindns.com:
_mta-sts.captaindns.com. IN TXT "v=STSv1; id=20260310T000000"
O campo id é um identificador de versão. Incremente-o a cada modificação da política para que os servidores de envio baixem a nova versão.
Arquivo de política HTTPS
O arquivo deve estar acessível em https://mta-sts.captaindns.com/.well-known/mta-sts.txt. Com o CaptainDNS, dois registros CNAME são suficientes: sem servidor web para gerenciar, sem certificado para renovar.
Comece com um max_age curto (86 400 segundos = 1 dia) para poder corrigir rapidamente em caso de problema:
version: STSv1
mode: testing
mx: mx.captaindns.com
max_age: 86400
Verificação
Use o verificador MTA-STS para confirmar que seu registro DNS e sua política estão publicados corretamente.
Etapa 2: configurar TLS-RPT para receber os relatórios
Sem TLS-RPT, o modo testing é inútil. Os servidores de envio detectam os problemas, mas não têm para onde reportá-los.
Registro DNS TLS-RPT
Publique um registro TXT em _smtp._tls.captaindns.com:
_smtp._tls.captaindns.com. IN TXT "v=TLSRPTv1; rua=mailto:tls-reports@captaindns.com"
Os relatórios TLS-RPT (RFC 8460) são enviados diariamente em formato JSON. Cada relatório contém:
- O domínio remetente e o domínio destinatário
- O tipo de política aplicada (MTA-STS ou DANE)
- O número de sessões bem-sucedidas e falhadas
- O detalhe das falhas: tipo de erro, certificado apresentado, código de resultado
Configurar com o CaptainDNS
O gerador TLS-RPT cria o registro DNS adaptado ao seu domínio. Você pode direcionar os relatórios para um endereço de e-mail ou um endpoint HTTPS.
Etapa 3: analisar os relatórios e corrigir os problemas
Aguarde 1 a 2 semanas em modo testing antes de mudar para enforce. Esse prazo permite coletar relatórios TLS-RPT suficientes para identificar problemas recorrentes.
Interpretar os relatórios
| Tipo de falha | Causa provável | Correção |
|---|---|---|
certificate-expired | Certificado TLS do servidor MX expirado | Renovar o certificado |
certificate-host-mismatch | O CN/SAN do certificado não corresponde ao nome MX | Corrigir o certificado ou a política |
starttls-not-supported | O servidor MX não suporta STARTTLS | Ativar STARTTLS no servidor |
sts-policy-fetch-error | A política HTTPS está inacessível | Verificar o DNS CNAME e o servidor HTTPS |
sts-webpki-invalid | O certificado HTTPS da política é inválido | Renovar o certificado do servidor web |
validation-failure | O MX não consta na política | Adicionar o MX faltante à política |
Critérios para mudar para enforce
Antes de ativar o modo enforce, verifique estas três condições:
- Zero falhas TLS recorrentes nos relatórios dos últimos 7 dias
- Todos os seus servidores MX constam na política
- Certificados TLS válidos em cada servidor MX (não expirados, CN/SAN correto)
Se falhas persistirem, corrija-as primeiro. Uma mudança prematura para enforce bloqueará os e-mails provenientes dos servidores que encontram esses erros.
Etapa 4: mudar para modo enforce
A transição é feita com duas modificações: o arquivo de política e o registro DNS.
Modificar a política
Altere mode: testing para mode: enforce e aumente o max_age para 604 800 segundos (7 dias):
version: STSv1
mode: enforce
mx: mx.captaindns.com
max_age: 604800
Um max_age de 7 dias oferece um bom equilíbrio: longo o suficiente para que os servidores de envio armazenem a política em cache (proteção contra TOFU), curto o suficiente para permitir um retorno ao testing se necessário.
Atualizar o identificador DNS
Incremente o id no registro TXT para forçar a atualização:
_mta-sts.captaindns.com. IN TXT "v=STSv1; id=20260310T120000"
Estratégia de reversão
Se surgirem problemas após a ativação do enforce:
- Volte imediatamente para
mode: testing - Incremente o
idDNS - Aguarde a expiração do
max_ageanterior (7 dias no máximo) - Analise os novos relatórios TLS-RPT
- Corrija os problemas antes de tentar novamente a ativação do enforce
Erros comuns e soluções
| Erro | Consequência | Solução |
|---|---|---|
| Ativar enforce sem TLS-RPT | Nenhuma visibilidade sobre os bloqueios | Sempre configurar TLS-RPT antes do enforce |
max_age muito longo em testing | Correção lenta em caso de problema | Usar 86 400 s (1 dia) em testing |
max_age muito curto em enforce | Proteção TOFU reduzida | Usar 604 800 s (7 dias) em enforce |
| Esquecer um servidor MX na política | E-mails rejeitados em enforce | Listar todos os MX com dig MX captaindns.com |
Não incrementar o id | Servidores de envio usam a política antiga | Sempre alterar o id após modificação |
| Certificado TLS expirado | Falha de validação em enforce | Automatizar a renovação (Let's Encrypt) |
Plano de ação recomendado
- Verifique sua configuração atual: execute uma análise com o verificador MTA-STS
- Implante em modo testing: publique sua política com
mode: testingemax_age: 86400 - Ative TLS-RPT: configure o registro
_smtp._tlspara receber os relatórios diários - Monitore por 1 a 2 semanas: analise cada relatório, corrija as falhas TLS
- Mude para enforce: altere
mode: enforce, aumentemax_agepara 604 800 s, incremente oid
Proteja o transporte dos seus e-mails agora: hospede sua política MTA-STS gratuitamente com o CaptainDNS. Dois registros DNS, zero servidores web, proteção ativa em 5 minutos.
FAQ
Qual é a diferença entre o modo testing e o modo enforce do MTA-STS?
Em modo testing, os servidores de envio verificam sua política MTA-STS, mas entregam os e-mails mesmo se a conexão TLS falhar. Eles enviam um relatório TLS-RPT para sinalizar o problema. Em modo enforce, os servidores recusam a entrega se o TLS falhar ou se o servidor MX não constar na política.
Quanto tempo é preciso ficar em modo testing antes de mudar para enforce?
Mínimo de 1 a 2 semanas. Esse prazo permite coletar relatórios TLS-RPT suficientes dos principais remetentes (Gmail, Outlook, Yahoo). Se os relatórios mostrarem zero falhas TLS durante 7 dias consecutivos, você pode mudar para enforce.
O que acontece se eu ativar o enforce diretamente, sem fase de testing?
Os e-mails provenientes de servidores que encontrem problemas TLS com seus MX serão rejeitados. Sem relatórios TLS-RPT prévios, você não terá visibilidade sobre essas rejeições. Parceiros ou clientes podem não conseguir mais enviar e-mails para você sem que você saiba.
Qual max_age usar em modo testing e em modo enforce?
Em testing, use 86 400 segundos (1 dia). Esse prazo curto permite corrigir rapidamente a política se um problema for detectado. Em enforce, mude para 604 800 segundos (7 dias) para reduzir a vulnerabilidade TOFU: os servidores de envio armazenam a política em cache por mais tempo.
Como voltar ao modo testing depois de ativar o enforce?
Modifique o arquivo de política para retornar a mode: testing e incremente o id no registro DNS TXT. Os servidores de envio que armazenaram a política enforce em cache continuarão a aplicá-la até a expiração do max_age anterior (7 dias no máximo).
O TLS-RPT é obrigatório para o MTA-STS?
Não, o TLS-RPT não é tecnicamente necessário para que o MTA-STS funcione. Mas sem TLS-RPT, você não tem visibilidade sobre as falhas TLS. Na prática, implantar MTA-STS sem TLS-RPT equivale a pilotar às cegas. Os dois protocolos foram projetados para funcionar em conjunto.
O Gmail e o Outlook respeitam o modo testing do MTA-STS?
Sim. Gmail, Outlook e Yahoo verificam as políticas MTA-STS em modo testing e enviam relatórios TLS-RPT para o endereço configurado. Em modo testing, entregam os e-mails normalmente mesmo em caso de falha TLS, mas sinalizam o problema no relatório diário.
Baixe a checklist de implementação
Assistentes podem reutilizar a checklist através dos exports JSON ou CSV abaixo.
Glossário
- MTA-STS: Mail Transfer Agent Strict Transport Security (RFC 8461). Política publicada via HTTPS que impõe o ciframento TLS para a recepção de e-mails em um domínio.
- TLS-RPT: SMTP TLS Reporting (RFC 8460). Mecanismo de relatórios diários que sinaliza falhas de negociação TLS entre servidores de e-mail.
- TOFU: Trust On First Use. Modelo de segurança em que a primeira conexão não é verificada, mas as seguintes são validadas graças aos dados armazenados em cache.
- max_age: duração (em segundos) durante a qual um servidor de envio mantém em cache a política MTA-STS. Determina a frequência de atualização.
- STARTTLS: extensão SMTP (RFC 3207) que permite negociar uma conexão TLS após o estabelecimento de uma conexão em texto claro na porta 25.
- Downgrade SMTP: ataque de rede que remove a negociação STARTTLS para interceptar e-mails em texto claro.
Guias de segurança do transporte de e-mail relacionados
- Ataques de downgrade SMTP: como funcionam e como se proteger: mecanismo do STARTTLS stripping e soluções de proteção
- MTA-STS vs DANE: qual protocolo escolher para proteger o transporte de e-mail?: comparação técnica e guia de escolha
