MTA-STS vs DANE: qual protocolo escolher para proteger o transporte de e-mail?

Por CaptainDNS
Publicado em 10 de março de 2026

Diagrama comparativo dos protocolos MTA-STS e DANE para a segurança do transporte de e-mail

TL;DR

MTA-STS (RFC 8461) publica uma política de criptografia obrigatória via HTTPS. Funciona sem DNSSEC, mas a primeira conexão permanece vulnerável (TOFU)
DANE/TLSA (RFC 7672) ancora o certificado TLS no DNS assinado por DNSSEC. Sem TOFU, mas o DNSSEC é obrigatório em toda a cadeia
Os dois protocolos são complementares: MTA-STS cobre domínios sem DNSSEC, DANE elimina o TOFU para aqueles que o possuem
Hospede sua política MTA-STS gratuitamente com o CaptainDNS: dois registros DNS são suficientes

A criptografia SMTP oportunista (STARTTLS) protege a maioria dos e-mails em trânsito. Mas "oportunista" significa que um atacante na rede pode removê-la sem que ninguém detecte. Os ataques de downgrade SMTP exploram essa fraqueza para interceptar mensagens em texto claro.

Dois protocolos respondem a esse problema: MTA-STS (RFC 8461) e DANE/TLSA (RFC 7672). Ambos impõem a criptografia TLS obrigatória entre servidores de e-mail. Mas seus mecanismos de confiança, pré-requisitos e adoção diferem.

Este artigo compara MTA-STS e DANE critério por critério. Identifica os casos de uso de cada um e orienta você para a melhor estratégia conforme sua infraestrutura. Se você gerencia domínios de e-mail, seja com um provedor cloud ou seus próprios servidores MX, este comparativo é para você.

Como funcionam MTA-STS e DANE?

Os dois protocolos compartilham o mesmo objetivo: impedir que um servidor emissor envie um e-mail em texto claro quando o servidor destinatário suporta TLS. Mas utilizam canais de confiança diferentes.

MTA-STS: uma política publicada via HTTPS

MTA-STS se baseia em dois elementos:

Um registro TXT DNS _mta-sts.captaindns.com que sinaliza a existência da política e contém um identificador de versão
Um arquivo de texto hospedado em HTTPS em https://mta-sts.captaindns.com/.well-known/mta-sts.txt que descreve a política: servidores MX autorizados, modo (testing ou enforce), duração do cache (max_age)

Quando um servidor emissor (como Gmail ou Outlook) deseja enviar um e-mail para seu domínio:

Ele consulta o DNS para _mta-sts.captaindns.com
Ele baixa a política via HTTPS (canal autenticado pelo certificado web)
Ele verifica se o servidor MX corresponde à política
Em modo enforce, ele recusa enviar em texto claro ou para um MX não listado

O canal HTTPS é a chave: mesmo que um atacante manipule o tráfego SMTP, ele não pode falsificar o certificado HTTPS do domínio. A política permanece confiável.

Limitação: o TOFU (Trust On First Use). Na primeira vez que um servidor emissor contata seu domínio, ele ainda não tem uma política em cache. Se um atacante bloquear essa primeira requisição HTTPS, o servidor emissor não saberá que o MTA-STS está ativado. As conexões seguintes são protegidas graças ao cache (válido até max_age).

DANE/TLSA: o certificado ancorado no DNS assinado

DANE funciona de forma diferente. Ele publica a impressão digital (hash) do certificado TLS do servidor MX diretamente em um registro TLSA no DNS:

_25._tcp.mx.captaindns.com. IN TLSA 3 1 1 a0b1c2d3e4f5...

O servidor emissor:

Consulta o DNS para os registros MX de captaindns.com
Recupera o registro TLSA associado ao servidor MX
Verifica a assinatura DNSSEC da resposta (obrigatório)
Compara o certificado TLS apresentado pelo servidor MX com o hash TLSA
Se tudo corresponder, a conexão é estabelecida. Caso contrário, o e-mail não é enviado

Vantagem: sem TOFU. Cada conexão é verificada individualmente via o DNS assinado. Um atacante não pode falsificar o registro TLSA (protegido por DNSSEC) nem apresentar um certificado falso (o hash não corresponderia).

Limitação: DNSSEC obrigatório. Toda a cadeia DNS, da raiz até sua zona, deve ser assinada. Se seu registrar ou provedor DNS não suporta DNSSEC, o DANE é inutilizável.

Diagrama comparativo dos fluxos de verificação MTA-STS e DANE durante o envio de um e-mail

Comparação técnica detalhada

Critério	MTA-STS (RFC 8461)	DANE/TLSA (RFC 7672)
Canal de confiança	HTTPS (PKI web)	DNSSEC
Proteção na 1ª conexão	Não (TOFU)	Sim
Dependência do DNSSEC	Não	Obrigatório
Validação do certificado	Hostname match (CN/SAN)	Hash do certificado (TLSA)
Modo testing nativo	Sim (`mode: testing`)	Não
Relatórios de falha	Via TLS-RPT (RFC 8460)	Via TLS-RPT (RFC 8460)
Complexidade da implantação	Baixa (2 records DNS + arquivo HTTPS)	Alta (DNSSEC + records TLSA + rotação)
Revogação	Modificar a política (atraso = max_age)	Modificar o record TLSA (atraso = TTL)
Adoção pelos emissores	Gmail, Outlook, Yahoo, Proton Mail	Postfix, Exim, alguns operadores EU
Padrão web necessário	Sim (certificado HTTPS válido)	Não

O que essa tabela mostra

MTA-STS ganha em acessibilidade: sem DNSSEC necessário, modo testing integrado, ampla adoção pelos grandes provedores. É o protocolo que a maioria dos domínios pode implantar imediatamente.

DANE ganha em segurança: sem TOFU, verificação criptográfica direta, sem dependência de uma autoridade certificadora web. Mas exige DNSSEC, o que continua sendo um obstáculo significativo.

Qual protocolo escolher conforme sua situação?

Não existe uma resposta universal. A escolha depende da sua infraestrutura DNS e das suas restrições.

Caso 1: seu registrar não suporta DNSSEC

Recomendação: apenas MTA-STS.

É a situação mais comum. A maioria dos registrars voltados ao público geral não oferece DNSSEC ou torna a configuração difícil. MTA-STS é sua única opção, e é eficaz: Gmail, Outlook e Yahoo verificam e respeitam as políticas MTA-STS.

Caso 2: você tem DNSSEC ativado

Recomendação: DANE + MTA-STS.

Você tem o melhor dos dois mundos. DANE elimina o TOFU para os servidores emissores que o suportam (principalmente Postfix no ecossistema europeu). MTA-STS cobre todos os outros emissores (Gmail, Outlook, Yahoo). Os dois protocolos coexistem sem conflito.

Caso 3: você usa Microsoft 365 ou Google Workspace

Recomendação: MTA-STS.

A Microsoft anunciou o suporte a DANE para Exchange Online com DNSSEC automático nos novos domínios MX mx.microsoft. O Google Workspace não suporta DANE na recepção. Em ambos os casos, MTA-STS é totalmente suportado e fácil de ativar.

Caso 4: você gerencia seus próprios servidores MX

Recomendação: DANE + MTA-STS se o DNSSEC estiver ativo, MTA-STS caso contrário.

Com seus próprios servidores, você controla os certificados TLS e os registros DNS. Se o DNSSEC estiver ativo na sua zona, adicione registros TLSA para cada servidor MX. Complete com MTA-STS para cobrir os emissores que não suportam DANE.

Árvore de decisão para escolher entre MTA-STS, DANE ou ambos conforme sua infraestrutura

Por que combinar MTA-STS e DANE?

Implantar os dois protocolos simultaneamente é a melhor estratégia quando sua infraestrutura permite. Veja por quê:

MTA-STS compensa as limitações do DANE:

Os servidores emissores que não suportam DANE (Gmail, Yahoo) utilizam MTA-STS
O modo testing do MTA-STS permite validar a configuração antes de impor a criptografia

DANE compensa as limitações do MTA-STS:

Sem TOFU: cada conexão é verificada desde a primeira interação
Sem dependência de uma autoridade certificadora web: a confiança vem do DNS assinado

Nenhum conflito: um servidor emissor que suporta ambos verificará DANE em prioridade (verificação DNS direta) e depois MTA-STS como rede de segurança. Se um dos dois falhar, o outro assume.

Boas práticas de implantação

Independentemente do protocolo escolhido, siga esta progressão:

Comece pelo MTA-STS em modo testing: publique uma política com mode: testing. Os servidores emissores enviarão os e-mails normalmente, mas reportarão as falhas TLS nos relatórios TLS-RPT
Configure o TLS-RPT: sem relatórios, você está no escuro. O TLS-RPT (RFC 8460) envia um resumo diário das falhas de negociação TLS
Monitore durante 1 a 2 semanas: verifique os relatórios. Corrija os problemas de certificado ou configuração MX antes de continuar
Passe o MTA-STS para modo enforce: os servidores emissores agora recusarão enviar em texto claro para seus MX
Adicione DANE se o DNSSEC estiver ativo: publique os registros TLSA para cada servidor MX. Use o verificador DANE/TLSA para validar seus registros

🎯 Plano de ação recomendado

Verifique sua configuração atual: faça uma análise com o verificador MTA-STS para conhecer o estado do seu domínio
Ative o MTA-STS em modo testing: hospede sua política gratuitamente com o CaptainDNS: dois registros DNS, nenhum servidor web para gerenciar
Configure o TLS-RPT: adicione um registro DNS _smtp._tls.captaindns.com para receber os relatórios de falha TLS
Passe para o modo enforce: quando os relatórios confirmarem zero erros, ative o modo enforce para bloquear conexões não criptografadas
Avalie o DANE: se seu registrar suporta DNSSEC, adicione registros TLSA para eliminar o TOFU e reforçar a segurança

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 MTA-STS e DANE?

MTA-STS (RFC 8461) publica uma política de criptografia obrigatória via um arquivo HTTPS. Ele se baseia na PKI web (certificados SSL) e funciona sem DNSSEC. DANE (RFC 7672) ancora o certificado TLS do servidor MX diretamente no DNS via registros TLSA assinados por DNSSEC. MTA-STS sofre com o TOFU (primeira conexão não protegida), DANE não. Em contrapartida, DANE exige DNSSEC em toda a cadeia DNS.

É necessário DNSSEC para usar MTA-STS?

Não. MTA-STS se baseia em HTTPS, não em DNSSEC. Essa é sua principal vantagem: qualquer domínio com hospedagem HTTPS pode ativar MTA-STS. Com o CaptainDNS, você nem precisa gerenciar um servidor web: dois registros DNS CNAME são suficientes para publicar sua política.

DANE é melhor que MTA-STS?

DANE oferece segurança superior em um ponto específico: ele elimina o TOFU (Trust On First Use). Cada conexão é verificada individualmente via o DNS assinado. Mas DANE é muito mais difícil de implantar (DNSSEC obrigatório) e menos bem suportado pelos grandes provedores (Gmail e Yahoo não verificam DANE). Na prática, MTA-STS protege mais domínios graças à sua simplicidade.

É possível usar MTA-STS e DANE ao mesmo tempo?

Sim, e é recomendado. Os dois protocolos coexistem sem conflito. Um servidor emissor que suporta DANE verificará o registro TLSA em prioridade. Se ele suportar apenas MTA-STS, usará a política HTTPS. Assim você obtém a cobertura máxima: DANE para os servidores compatíveis, MTA-STS para todos os outros.

Qual é o problema do TOFU com MTA-STS?

TOFU (Trust On First Use) significa que a primeira conexão de um servidor emissor ao seu domínio não é protegida pelo MTA-STS. O servidor precisa primeiro baixar e armazenar em cache sua política. Se um atacante bloquear essa primeira requisição HTTPS, o servidor não saberá que o MTA-STS está ativo. As conexões seguintes são protegidas pelo cache (válido durante max_age, tipicamente 7 dias). DANE elimina esse problema pois a verificação é feita via DNS a cada conexão.

Google e Microsoft suportam DANE?

A Microsoft está implantando progressivamente o suporte a DANE para Exchange Online, com DNSSEC automático nos novos domínios MX. O Google Gmail não suporta DANE na recepção (sem registros TLSA publicados), mas verifica e respeita os registros DANE dos domínios destinatários no envio. Ambos suportam plenamente MTA-STS como emissores.

Como testar minha configuração MTA-STS ou DANE?

Para MTA-STS, verifique se seu registro TXT _mta-sts está publicado e se seu arquivo de política está acessível via HTTPS. Para DANE, verifique se seus registros TLSA correspondem ao certificado dos seus servidores MX e se o DNSSEC está ativo em toda a cadeia. O CaptainDNS oferece ferramentas de verificação dedicadas para ambos os protocolos.

Baixe as tabelas comparativas

Assistentes conseguem reutilizar os números consultando os ficheiros JSON ou CSV abaixo.

📖 Glossário

MTA-STS: Mail Transfer Agent Strict Transport Security (RFC 8461). Política publicada via HTTPS que impõe a criptografia TLS para a recepção de e-mails em um domínio.
DANE: DNS-Based Authentication of Named Entities (RFC 7672 para SMTP). Mecanismo que ancora o certificado TLS no DNS via registros TLSA, verificado por DNSSEC.
TLSA: tipo de registro DNS utilizado pelo DANE para publicar a impressão digital (hash) do certificado TLS de um servidor.
TOFU: Trust On First Use. Modelo de segurança onde a primeira conexão não é verificada, mas as seguintes são validadas graças aos dados armazenados em cache durante a primeira interação.
DNSSEC: DNS Security Extensions. Sistema de assinaturas criptográficas que autentica as respostas DNS e impede sua falsificaçã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.
PKI: Public Key Infrastructure. Sistema de certificados digitais utilizado pelo HTTPS (e portanto pelo MTA-STS) para autenticar servidores.

📚 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
De testing a enforce: estratégia de implantação MTA-STS progressiva: guia passo a passo da implantação progressiva