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

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

No modo testing , os servidores de envio tentam a ligaçã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 .

Q: 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. Aloje o ficheiro 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 receção (pode publicar uma política para o seu domínio M365).

Q: O que acontece se o ficheiro de política não estiver acessível?

Se o ficheiro 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 a ser aplicada. É por isso que um max_age suficientemente longo protege contra interrupções temporárias.

Por CaptainDNS
Publicado em 6 de fevereiro de 2026

Atualizado em 31 de julho de 2026

MTA-STS: proteger o transporte de email com encriptação TLS obrigatória

TL;DR

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

Os seus emails transitam todos os dias entre servidores SMTP. Mas sabe se essas trocas são realmente encriptadas? Por predefinição, o SMTP usa STARTTLS de forma oportunista: se o servidor remoto não responde à encriptação, a mensagem é enviada em texto puro. Um invasor posicionado na rede pode forçar esse comportamento e interceptar as 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 encriptação TLS para receber emails. Os servidores de envio que respeitam o MTA-STS se recusarão a enviar uma mensagem se a ligação TLS falhar.

Este guia explica como o MTA-STS funciona, quais são os seus componentes, como implantá-lo passo a passo e porque 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 os seus servidores de receção de email (MX). Essa política indica aos servidores de envio que eles devem:

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

Porque STARTTLS não é suficiente?

STARTTLS é o mecanismo padrão para encriptar ligaçõ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 encriptação 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 predefiniçã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 encriptação TLS e a validação do certificado.

Diagrama do funcionamento do MTA-STS: o servidor de envio verifica a política antes de enviar

Os dois componentes do MTA-STS

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

O registo DNS TXT `_mta-sts`

Um registo 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 deteta uma mudança no id, descarrega novamente a política. Use um carimbo de data/hora (ex.: 20260205120000) ou um número incremental.

O ficheiro de política mta-sts.txt

Um ficheiro de texto alojado 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)

Alojamento HTTPS obrigatório

O ficheiro 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: monitorizar 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 encriptação falhar. Este é o modo de início recomendado.

Modo enforce: encriptação ou rejeição

mode: enforce

No modo enforce, os servidores de envio recusam entregar a mensagem se a ligaçã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 os 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 ficheiro de política

Crie o ficheiro mta-sts.txt com os seus servidores MX. 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: Alojar a política na URL .well-known

Publique o ficheiro 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 alojamento:

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 registo DNS TXT

Adicione na sua zona DNS:

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

Etapa 5: Validar a sua configuração

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

Checklist de implantação MTA-STS em 5 etapas

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	Encriptação oportunista	Encriptação obrigatória	Encriptação 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: monitorizar a 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 o seu domínio.

Para ativar o TLS-RPT, publique um registo 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

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

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

FAQ

O que é MTA-STS e porque 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 encriptação TLS para receber emails. Sem MTA-STS, as ligaçõ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 os seus emails recebidos sejam sempre encriptados 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 nos seus domínios e verificam a presença de MTA-STS nos domínios que contactam. Para organizações sujeitas a requisitos de conformidade (RGPD, 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 ligaçã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 registos 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 o seu domínio. Sem TLS-RPT, não tem visibilidade sobre os problemas da sua implantação MTA-STS. Publique um registo _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. Aloje o ficheiro 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 receção (pode publicar uma política para o seu domínio M365).

Como configurar MTA-STS para Google Workspace?

Para Google Workspace, declare os MX que o seu domínio publica realmente (dig MX oseudominio.com +short). Desde 2023, o Google documenta um registo único, smtp.google.com com prioridade 1: nesse caso basta o padrão smtp.google.com. Um domínio criado antes de 2023 publica o conjunto histórico, ainda suportado, que exige três padrões: aspmx.l.google.com, *.aspmx.l.google.com e *.googlemail.com. O wildcard MTA-STS vale apenas para uma etiqueta, pelo que *.google.com não cobriria nenhum servidor desse conjunto histórico. O Google verifica ativamente as políticas MTA-STS dos domínios que contacta e publica relatórios TLS-RPT. Aloje o ficheiro de política em um servidor HTTPS com um certificado válido para o subdomínio mta-sts.

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

Se o ficheiro 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 a ser 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 encriptação TLS para a receção de emails.
STARTTLS: Extensão SMTP que permite transformar uma ligação em texto puro em uma ligação encriptada TLS. Oportunista por predefiniçã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 registos TLSA para validar certificados TLS.
Ataque downgrade: Técnica em que um invasor força uma ligaçã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.