MTA-STS: o guia completo para proteger o transporte dos seus emails

⚡TL;DR

• MTA-STS (RFC 8461) força a criptografia TLS nos emails recebidos e impede ataques do tipo downgrade e man-in-the-middle no SMTP
• Dois componentes a implantar: um registro DNS TXT _mta-sts e um arquivo de política hospedado em HTTPS em mta-sts.captaindns.com/.well-known/mta-sts.txt
• Três modos disponíveis: none (desativado), testing (monitoramento via TLS-RPT) e enforce (rejeição se a criptografia TLS falhar)
• Sempre comece pelo modo testing e configure o TLS-RPT para receber os relatórios de falha antes de mudar para enforce

Seus emails transitam todos os dias entre servidores SMTP. Mas você sabe se essas trocas são realmente criptografadas? Por padrão, o SMTP usa STARTTLS de forma oportunista: se o servidor remoto não responde à criptografia, a mensagem é enviada em texto puro. Um invasor posicionado na rede pode forçar esse comportamento e interceptar suas comunicações.

MTA-STS (Mail Transfer Agent Strict Transport Security) resolve esse problema. Definido na RFC 8461, esse padrão permite que um domínio declare publicamente que exige criptografia TLS para receber emails. Os servidores de envio que respeitam o MTA-STS se recusarão a enviar uma mensagem se a conexão TLS falhar.

Este guia explica como o MTA-STS funciona, quais são seus componentes, como implantá-lo passo a passo e por que ele se tornou um complemento indispensável ao DMARC, SPF e DKIM na stack de segurança de email.

O que é MTA-STS? (RFC 8461)

MTA-STS, Mail Transfer Agent Strict Transport Security, é um mecanismo que permite ao proprietário de um domínio publicar uma política de segurança de transporte para seus servidores de recepção de email (MX). Essa política indica aos servidores de envio que eles devem:

1. Negociar uma conexão TLS válida antes de enviar um email
2. Verificar o certificado do servidor destinatário (nome de host, cadeia de confiança, expiração)
3. Recusar o envio se a criptografia TLS falhar (no modo enforce)

Por que STARTTLS não é suficiente?

STARTTLS é o mecanismo padrão para criptografar conexões SMTP. Mas ele sofre de duas falhas fundamentais:

• Ataque downgrade: um invasor pode remover o comando STARTTLS da resposta do servidor, forçando o envio em texto puro. O servidor de envio não sabe que a criptografia estava disponível.
• Sem validação de certificado: mesmo que o STARTTLS seja negociado, o SMTP não verifica a identidade do servidor destinatário por padrão. Um servidor falso com um certificado autoassinado pode interceptar as mensagens.

MTA-STS corrige esses dois problemas: a política, obtida via HTTPS (canal separado e autenticado), impõe a criptografia TLS e a validação do certificado.

Os dois componentes do MTA-STS

MTA-STS se baseia em dois elementos que funcionam juntos.

O registro DNS TXT _mta-sts

Um registro TXT publicado na sua zona DNS em _mta-sts.captaindns.com:

_mta-sts.captaindns.com. 300 IN TXT "v=STSv1; id=20260205120000"

Tag	Obrigatório	Descrição
v	Sim	Versão do protocolo, sempre STSv1
id	Sim	Identificador único da política, deve ser alterado a cada atualização

O campo id funciona como sinal de atualização. Quando um servidor de envio detecta uma mudança no id, ele baixa novamente a política. Use um carimbo de data/hora (ex.: 20260205120000) ou um número incremental.

O arquivo de política mta-sts.txt

Um arquivo de texto hospedado na URL exata https://mta-sts.captaindns.com/.well-known/mta-sts.txt:

version: STSv1
mode: testing
mx: mail.captaindns.com
mx: backup.captaindns.com
max_age: 604800

Diretiva	Obrigatório	Descrição
version	Sim	Sempre STSv1
mode	Sim	none, testing ou enforce
mx	Sim	Padrão(ões) MX autorizados (um por linha, wildcards permitidos como *.captaindns.com)
max_age	Sim	Duração do cache em segundos (máx. 31 557 600 = 1 ano)

Hospedagem HTTPS obrigatória

O arquivo de política deve ser servido via HTTPS com um certificado TLS válido no subdomínio mta-sts. Este é um elemento fundamental da segurança do MTA-STS: diferentemente do DNS (que pode ser falsificado sem DNSSEC), o HTTPS garante a autenticidade da política por meio da validação do certificado.

Os 3 modos MTA-STS: testing, enforce, none

Modo testing: monitorar sem bloquear

mode: testing

No modo testing, os servidores de envio tentam negociar TLS e relatam as falhas via TLS-RPT (RFC 8460), mas entregam mesmo assim a mensagem se a criptografia falhar. Este é o modo de início recomendado.

Modo enforce: criptografia ou rejeição

mode: enforce

No modo enforce, os servidores de envio recusam entregar a mensagem se a conexão TLS falhar ou se o certificado não for válido. Este é o modo alvo para uma proteção completa.

Modo none: desativação

mode: none

O modo none indica que o MTA-STS está desativado. Use-o para desativar corretamente uma política existente (os servidores de envio que têm uma política em cache devem esperar a expiração do max_age).

Qual valor de max_age escolher?

Fase de implantação	max_age recomendado	Duração
Início (testing)	86 400	1 dia
Estabilização	604 800	7 dias
Produção (enforce)	2 592 000 a 31 557 600	30 dias a 1 ano

Um max_age curto na fase de teste permite corrigir erros rapidamente. Uma vez em enforce, um max_age longo reduz a frequência de re-download e reforça a proteção contra ataques DNS temporários.

Implantar MTA-STS passo a passo

Etapa 1: Verificar seus MX e certificados TLS

Antes de implantar o MTA-STS, certifique-se de que todos os seus servidores MX possuem um certificado TLS válido (TLS 1.2 no mínimo) com um nome de host correspondente. Um certificado expirado ou mal configurado causará rejeições no modo enforce.

Etapa 2: Criar o arquivo de política

Crie o arquivo mta-sts.txt com seus servidores MX. Você pode usar o gerador MTA-STS CaptainDNS para criá-lo automaticamente:

version: STSv1
mode: testing
mx: mail.captaindns.com
mx: backup.captaindns.com
max_age: 86400

Etapa 3: Hospedar a política na URL .well-known

Publique o arquivo na URL exata:

https://mta-sts.captaindns.com/.well-known/mta-sts.txt

O subdomínio mta-sts deve resolver para um servidor web HTTPS com um certificado válido. Opções comuns de hospedagem:

• Cloudflare Pages / Cloudflare Workers: gratuito, HTTPS automático
• GitHub Pages: gratuito, certificado Let's Encrypt
• Azure Static Web Apps: integração com Microsoft 365
• Servidor web existente: Apache, Nginx com Let's Encrypt

O Content-Type da resposta deve ser text/plain.

Etapa 4: Publicar o registro DNS TXT

Adicione na sua zona DNS:

_mta-sts.captaindns.com. 300 IN TXT "v=STSv1; id=20260205120000"

Etapa 5: Validar sua configuração

Use o verificador MTA-STS CaptainDNS para confirmar que tudo está configurado: registro DNS, arquivo de política, certificado TLS, correspondência MX.

MTA-STS vs DANE vs STARTTLS

Três mecanismos coexistem para proteger o transporte SMTP. Veja as diferenças:

Critério	STARTTLS sozinho	MTA-STS	DANE
Proteção	Criptografia oportunista	Criptografia obrigatória	Criptografia obrigatória
Validação do certificado	Não	Sim (via HTTPS/CA)	Sim (via DNSSEC/TLSA)
Resiste a ataques downgrade	Não	Sim	Sim
Pré-requisitos	Nenhum	HTTPS no subdomínio mta-sts	DNSSEC na zona DNS
Complexidade de implantação	Baixa	Média	Alta
Adoção	Universal	Crescente (Google, Microsoft)	Limitada (pré-requisito DNSSEC)
RFC	RFC 3207	RFC 8461	RFC 7671

Na prática: MTA-STS é a escolha pragmática. DANE oferece uma segurança teoricamente superior (sem dependência de CAs), mas requer DNSSEC, ainda pouco implantado. As duas abordagens são complementares e podem coexistir.

TLS-RPT: monitorar sua implantação MTA-STS

TLS-RPT (SMTP TLS Reporting, RFC 8460) é o companheiro indispensável do MTA-STS. Ele permite receber relatórios JSON diários descrevendo os sucessos e falhas de negociação TLS com seu domínio.

Para ativar o TLS-RPT, publique um registro DNS:

_smtp._tls.captaindns.com. 300 IN TXT "v=TLSRPTv1; rua=mailto:tls-reports@captaindns.com"

Esses relatórios são essenciais no modo testing: eles permitem identificar problemas (certificados expirados, MX não cobertos, servidores incompatíveis com TLS 1.2) antes de mudar para o modo enforce.

Plano de ação recomendado

1. Verifique seus certificados TLS: todos os seus servidores MX devem ter um certificado válido com TLS 1.2+
2. Implante no modo testing: crie a política e o registro DNS com mode: testing e max_age: 86400
3. Ative o TLS-RPT: publique o registro _smtp._tls para receber os relatórios de falha
4. Monitore durante 2 a 4 semanas: analise os relatórios TLS-RPT e corrija os problemas identificados
5. Mude para o modo enforce: quando os relatórios estiverem limpos, altere para mode: enforce e aumente o max_age

---

Verifique sua configuração MTA-STS agora: Use nosso verificador MTA-STS para analisar seu domínio em poucos segundos.

---

FAQ

O que é MTA-STS e por que preciso dele?

MTA-STS (Mail Transfer Agent Strict Transport Security) é um padrão da internet (RFC 8461) que permite a um domínio declarar que exige criptografia TLS para receber emails. Sem MTA-STS, as conexões SMTP usam STARTTLS de forma oportunista, o que as torna vulneráveis a ataques downgrade e man-in-the-middle. O MTA-STS garante que seus emails recebidos sejam sempre criptografados em trânsito.

MTA-STS é obrigatório para a segurança de email?

MTA-STS ainda não é obrigatório no sentido regulatório, mas é fortemente recomendado. Google e Microsoft o ativaram em seus domínios e verificam a presença de MTA-STS nos domínios que contatam. Para organizações sujeitas a requisitos de conformidade (LGPD, PCI-DSS), o MTA-STS reforça a postura de segurança do transporte de email.

Qual é a diferença entre os modos testing e enforce?

No modo testing, os servidores de envio tentam a conexão TLS e relatam as falhas via TLS-RPT, mas entregam a mensagem mesmo assim. No modo enforce, os servidores recusam entregar a mensagem se o TLS falhar. Sempre comece com testing para identificar problemas antes de mudar para enforce.

Como o MTA-STS se compara ao DANE?

MTA-STS usa HTTPS e autoridades certificadoras (CA) para autenticar a política, enquanto DANE usa DNSSEC e registros TLSA. DANE oferece segurança superior (sem dependência de CAs), mas requer DNSSEC, ainda pouco implantado. MTA-STS é mais simples de implantar e mais amplamente adotado. Os dois mecanismos são complementares.

Também preciso configurar TLS-RPT com MTA-STS?

Sim, é fortemente recomendado. TLS-RPT (RFC 8460) envia relatórios diários sobre os sucessos e falhas de negociação TLS com seu domínio. Sem TLS-RPT, você não tem visibilidade sobre os problemas da sua implantação MTA-STS. Publique um registro _smtp._tls com um endereço de recebimento.

Como configurar MTA-STS para Microsoft 365?

Para Microsoft 365, use o padrão MX *.mail.protection.outlook.com na sua política MTA-STS. Hospede o arquivo de política no Azure Static Web Apps, Cloudflare Pages ou qualquer servidor HTTPS. A Microsoft suporta MTA-STS no envio (ela verifica a política dos seus destinatários) e na recepção (você pode publicar uma política para seu domínio M365).

Como configurar MTA-STS para Google Workspace?

Para Google Workspace, inclua os seguintes padrões MX na sua política: aspmx.l.google.com, *.google.com e *.googlemail.com. O Google verifica ativamente as políticas MTA-STS dos domínios que contata e publica relatórios TLS-RPT. Hospede o arquivo de política em um servidor HTTPS com um certificado válido para o subdomínio mta-sts.

O que acontece se o arquivo de política não estiver acessível?

Se o arquivo mta-sts.txt não estiver acessível (erro HTTP, timeout, certificado inválido), o servidor de envio não pode aplicar a política. Na ausência de uma política em cache, ele volta ao comportamento STARTTLS oportunista padrão. Se uma política estiver em cache (não expirada conforme max_age), ela continua sendo aplicada. É por isso que um max_age suficientemente longo protege contra interrupções temporárias.

Glossário

• MTA-STS: Mail Transfer Agent Strict Transport Security. Padrão RFC 8461 que impõe criptografia TLS para a recepção de emails.
• STARTTLS: Extensão SMTP que permite transformar uma conexão em texto puro em uma conexão criptografada TLS. Oportunista por padrão.
• TLS-RPT: SMTP TLS Reporting (RFC 8460). Mecanismo de relatório sobre os sucessos e falhas de negociação TLS.
• DANE: DNS-based Authentication of Named Entities (RFC 7671). Usa DNSSEC e registros TLSA para validar certificados TLS.
• Ataque downgrade: Técnica em que um invasor força uma conexão a usar um protocolo menos seguro (ex.: remover STARTTLS para forçar o envio em texto puro).
• max_age: Diretiva da política MTA-STS que indica a duração do armazenamento em cache em segundos.

Guias de MTA-STS relacionados

• Configurar MTA-STS para Microsoft 365 e Google Workspace (em breve)
• MTA-STS não funciona? Guia completo de solução de problemas (em breve)

Fontes

• RFC 8461 - SMTP MTA Strict Transport Security (MTA-STS)
• RFC 8460 - SMTP TLS Reporting
• RFC 7671 - The DNS-Based Authentication of Named Entities (DANE)
• Google Support - Reforçar a segurança de emails com MTA-STS e TLS-RPT