Seu DMARC está em p=reject. Seu SPF está limpo. Cada mensagem enviada carrega uma assinatura DKIM válida. Por todas as métricas que o setor definiu, o stack de autenticação do seu domínio está completo.
E, no entanto, existe uma classe de ataque que nenhum desses registros consegue parar – um que não opera na camada de políticas, mas no fio em si, enquanto seu email está em movimento entre servidores.
O MTA-STS é o padrão projetado para fechar essa lacuna. Segundo o Relatório de Adoção de DMARC e MTA-STS nos Estados Unidos 2026 da PowerDMARC, apenas 1,7% dos domínios americanos o implementaram. Globalmente, a pesquisa 2026 da URIports sobre o milhão de domínios mais importantes encontrou menos de 1% com uma política MTA-STS ativa. O padrão foi publicado como RFC 8461 desde 2018 – oito anos disponível, amplamente acessível, e quase em nenhum lugar implementado.
O Ataque Que o DMARC Nunca Foi Projetado para Parar
DMARC, SPF e DKIM abordam uma ameaça específica: um invasor se passando pelo seu domínio enviando emails que alegam vir do seu endereço. Eles respondem à pergunta “Este email realmente vem de quem diz ser?”
Eles não abordam o que acontece depois que o email sai do seu servidor de correio e antes de chegar ao servidor do destinatário. Esse segmento da jornada – o trânsito SMTP de servidor para servidor – é onde opera uma classe diferente de ataque.
O SMTP usa um mecanismo chamado STARTTLS para negociar o transporte criptografado entre servidores de correio. O problema é que o STARTTLS é anunciado em texto claro. Um invasor posicionado entre os dois servidores – seja na rede ou por meio de um nó de roteamento comprometido – pode interceptar o comando STARTTLS, removê-lo e substituí-lo por uma mensagem de rejeição. O servidor remetente, não vendo nenhuma oferta de TLS do destino, volta a enviar o email em texto claro.
Nesse ponto, o invasor pode ler cada palavra da mensagem, modificar o conteúdo antes de encaminhá-lo, ou capturar credenciais e anexos. Seu registro DMARC, sua assinatura DKIM, seu alinhamento SPF – nenhum deles é visível para um invasor observando o tráfego SMTP em texto claro. O stack de autenticação permanece intacto e irrelevante.
Essa classe de ataque – conhecida como ataque de downgrade STARTTLS – foi observada em escala nacional. Pesquisadores da EFF e equipes universitárias documentaram seu uso por múltiplos atores estatais para interceptar tráfego de email internacional nas principais rotas SMTP.
O Que o MTA-STS Faz
O MTA-STS (Mail Transfer Agent Strict Transport Security) é a resposta do IETF aos ataques de downgrade STARTTLS.
O mecanismo funciona em duas partes. Um domínio publica um arquivo de texto em um caminho HTTPS conhecido (https://mta-sts.seudominio.com/.well-known/mta-sts.txt) declarando sua política TLS: os nomes de host MX que espera, se o modo é enforce ou testing, e uma idade máxima de política. Em seguida, publica um registro DNS TXT em _mta-sts.seudominio.com que sinaliza a versão da política.
Quando um servidor de correio remetente pesquisa o MTA-STS para seu domínio e encontra uma política enforce, ele só entregará correio por meio de uma conexão TLS com um certificado válido correspondente aos nomes de host MX declarados. Se um invasor remover a oferta STARTTLS ou apresentar um certificado inválido, o servidor remetente se recusa a entregar – e você recebe um relatório TLS-RPT explicando a falha.
A diferença crítica em relação ao STARTTLS sozinho: o MTA-STS é obtido por HTTPS antes do início da conexão SMTP. Um invasor no caminho SMTP não pode manipular uma política obtida por HTTPS sem quebrar a validação do certificado. A política cria um compromisso que a negociação STARTTLS sozinha não consegue criar.
TLS-RPT: O Companheiro de Visibilidade
A aplicação do MTA-STS sem relatórios é proteção sem painel de controle. O TLS-RPT (RFC 8460) é o padrão complementar que fecha esse ciclo.
Ao publicar um registro DNS TXT _smtp._tls, você instrui os servidores de correio remetentes a reportar cada falha de STARTTLS e MTA-STS que encontrarem ao entregar correio para seu domínio. Os relatórios chegam como resumos em formato JSON uma vez por dia – semelhantes em estrutura aos relatórios agregados do DMARC – mostrando quais servidores remetentes tentaram a entrega, se a negociação TLS foi bem-sucedida e o erro específico quando não foi.
O TLS-RPT informa se alguém está ativamente tentando fazer o downgrade das suas conexões de correio de entrada, e quais remetentes legítimos estão enfrentando problemas de TLS que podem estar silenciosamente afetando a entregabilidade. Assim como o DMARC em p=none, o MTA-STS no modo testing fornece essa visibilidade sem bloquear nenhum correio – um ponto de partida seguro para qualquer domínio.
A Lacuna de Adoção
Os números de adoção global para 2026 são impressionantes por quão baixos permanecem, apesar dos oito anos de história do padrão.
A análise da PowerDMARC encontrou que, enquanto 95,7% dos domínios americanos têm SPF e 95,8% têm um registro DMARC, apenas 1,7% implementaram o MTA-STS. Mesmo entre os 49% dos domínios americanos que aplicam o DMARC em p=quarantine ou p=reject, a grande maioria deixou a lacuna de segurança de trânsito aberta.
Um ponto positivo é o Reino Unido. O relatório do Reino Unido da PowerDMARC encontrou adoção de MTA-STS de 20,6% – mais de doze vezes a taxa americana – em grande parte atribuível às orientações do NCSC (Centro Nacional de Segurança Cibernética) que recomenda explicitamente o MTA-STS como parte da base de segurança de email do governo britânico. Os domínios governamentais lideram com adoção de 39,9%. Quando os reguladores estabelecem expectativas claras, as organizações respondem.
A pesquisa global 2026 da URIports descobriu que a implementação do MTA-STS no milhão de domínios mais importantes mais do que dobrou nos últimos dois anos. A direção está correta. O ritmo não é suficiente dado que o padrão está disponível há oito anos.
Como Implementar o MTA-STS
Implementar o MTA-STS é um processo de três etapas que não requer alterações em software instalado localmente:
Etapa 1 – Começar no modo de teste. Antes de aplicar a política, publique sua política MTA-STS em mode: testing e ative o relatório TLS-RPT. Isso fornece visibilidade imediata sobre falhas de TLS sem bloquear nenhum correio. Colete relatórios por pelo menos duas a quatro semanas para estabelecer uma linha de base.
Etapa 2 – Validar sua configuração MX. Sua política MTA-STS declara nomes de host MX específicos. Esses nomes de host devem resolver para servidores que apresentem certificados TLS válidos e não expirados de uma autoridade certificadora confiável. Se algum host MX tiver um problema de incompatibilidade de certificado ou expiração, mudar para o modo enforce causará falhas de entrega para remetentes que respeitam o MTA-STS. Corrija esses problemas antes de aplicar a política.
Etapa 3 – Mudar para o modo enforce. Quando os relatórios TLS-RPT confirmarem negociação TLS limpa em todo o seu fluxo de correio de entrada, atualize seu arquivo de política para mode: enforce. Incremente a string de versão da política no seu registro DNS TXT para que os servidores remetentes saibam que devem buscar novamente a política atualizada.
O tempo decorrido desde nenhum MTA-STS até o enforce é tipicamente de duas a seis semanas para organizações que gerenciam sua própria infraestrutura MX. Provedores de email hospedados – Google Workspace, Microsoft 365 – gerenciam automaticamente o lado do certificado MX, tornando a etapa de publicação da política direta.
DMARC e MTA-STS: Complementares, Não Concorrentes
DMARC e MTA-STS protegem diferentes superfícies do mesmo caminho de email.
O DMARC responde: “Este email realmente vem de quem diz ser?” Ele opera sobre a identidade do remetente e a autenticação da mensagem. Protege contra falsificação e personificação de domínio – ataques que se originam fora da sua infraestrutura.
O MTA-STS responde: “Este email está sendo entregue por meio de uma conexão segura e verificada?” Ele opera na camada de transporte. Protege contra interceptação e modificação enquanto o email está em trânsito entre servidores que você não controla.
Um domínio com forte aplicação do DMARC mas sem MTA-STS está protegendo a identidade do remetente enquanto deixa o canal aberto à inspeção. Ambos os registros funcionam no nível DNS, ambos não requerem hardware ou software local e ambos são gratuitos para publicar.
A lacuna entre os 95,8% de implantação do DMARC e os 1,7% do MTA-STS é a lacuna entre organizações que abordaram a personificação e organizações que abordaram a segurança de transporte. Abordar apenas um lado não é uma postura de segurança de email completa – e a superfície de ataque de downgrade STARTTLS permanece exatamente tão explorável contra um domínio com p=reject quanto contra um domínio com p=none.
Pronto para construir uma postura de segurança de email completa além do DMARC? O Excello Mail ajuda você a configurar e monitorar a camada de aplicação DMARC que sustenta um canal de email seguro. Cadastre-se gratuitamente no Excello Mail e veja exatamente onde seu domínio está em autenticação e além.