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

⚡TL;DR

• MTA-STS (RFC 8461) publica uma política de encriptação obrigatória via HTTPS. Funciona sem DNSSEC, mas a primeira ligaçã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
• Aloje a sua política MTA-STS com o CaptainDNS (primeira ferramenta gratuita, depois 3 €/mês sem IVA): dois registos DNS são suficientes

A encriptação 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 detete. 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 encriptação TLS obrigatória entre servidores de e-mail. Mas os 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 para a melhor estratégia conforme a sua infraestrutura. Se gere domínios de e-mail, seja com um fornecedor cloud ou os seus próprios servidores MX, este comparativo é para si.

Como funcionam MTA-STS e DANE?

Os dois protocolos partilham 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 baseia-se em dois elementos:

1. Um registo TXT DNS _mta-sts.captaindns.com que sinaliza a existência da política e contém um identificador de versão
2. Um ficheiro de texto alojado 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 o seu domínio:

1. Ele consulta o DNS para _mta-sts.captaindns.com
2. Descarrega a política via HTTPS (canal autenticado pelo certificado web)
3. Ele verifica se o servidor MX corresponde à política
4. 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 fiável.

Limitação: o TOFU (Trust On First Use). Na primeira vez que um servidor emissor contacta o 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 ligaçõ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 registo TLSA no DNS:

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

O servidor emissor:

1. Consulta o DNS para os registos MX de captaindns.com
2. Recupera o registo TLSA associado ao servidor MX
3. Verifica a assinatura DNSSEC da resposta (obrigatório)
4. Compara o certificado TLS apresentado pelo servidor MX com o hash TLSA
5. Se tudo corresponder, a ligação é estabelecida. Caso contrário, o e-mail não é enviado

Vantagem: sem TOFU. Cada ligação é verificada individualmente via o DNS assinado. Um atacante não pode falsificar o registo 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é a sua zona, deve ser assinada. Se o seu registrar ou fornecedor DNS não suporta DNSSEC, o DANE é inutilizável.

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ª ligaçã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 + ficheiro 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 fornecedores. É 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 a ser um obstáculo significativo.

Qual protocolo escolher conforme a sua situação?

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

Caso 1: o 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: tem DNSSEC ativado

Recomendação: DANE + MTA-STS.

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: 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 receção. Em ambos os casos, MTA-STS é totalmente suportado e fácil de ativar.

Caso 4: gere os seus próprios servidores MX

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

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

Porque combinar MTA-STS e DANE?

Implantar os dois protocolos simultaneamente é a melhor estratégia quando a 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 encriptação

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

• Sem TOFU: cada ligaçã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:

1. 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
2. Configure o TLS-RPT: sem relatórios, está no escuro. O TLS-RPT (RFC 8460) envia um resumo diário das falhas de negociação TLS
3. Monitorize durante 1 a 2 semanas: verifique os relatórios. Corrija os problemas de certificado ou configuração MX antes de continuar
4. Passe o MTA-STS para modo enforce: os servidores emissores agora recusarão enviar em texto claro para os seus MX
5. Adicione DANE se o DNSSEC estiver ativo: publique os registos TLSA para cada servidor MX. Use o verificador DANE/TLSA para validar os seus registos e em seguida o validador de sintaxe DANE/TLSA para checar a forma bruta antes da publicação

🎯 Plano de ação recomendado

1. Verifique a sua configuração atual: faça uma análise com o verificador MTA-STS para conhecer o estado do seu domínio
2. Ative o MTA-STS em modo testing: aloje a sua política com o CaptainDNS (primeira ferramenta gratuita, depois 3 €/mês sem IVA): dois registos DNS, nenhum servidor web para gerir
3. Configure o TLS-RPT: adicione um registo DNS _smtp._tls.captaindns.com para receber os relatórios de falha TLS
4. Passe para o modo enforce: quando os relatórios confirmarem zero erros, ative o modo enforce para bloquear ligações não encriptadas
5. Avalie o DANE: se o seu registrar suporta DNSSEC, adicione registos TLSA para eliminar o TOFU e reforçar a segurança

---

Proteja o transporte dos seus e-mails agora: aloje a sua política MTA-STS (primeira ferramenta gratuita, depois 3 €/mês sem IVA) com o CaptainDNS. Dois registos 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 encriptação obrigatória via um ficheiro HTTPS. Ele baseia-se na PKI web (certificados SSL) e funciona sem DNSSEC. DANE (RFC 7672) ancora o certificado TLS do servidor MX diretamente no DNS via registos TLSA assinados por DNSSEC. MTA-STS sofre com o TOFU (primeira ligaçã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 baseia-se em HTTPS, não em DNSSEC. Essa é sua principal vantagem: qualquer domínio com alojamento HTTPS pode ativar MTA-STS. Com o CaptainDNS, nem precisa de gerir um servidor web: dois registos DNS CNAME são suficientes para publicar a 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 ligação é verificada individualmente via o DNS assinado. Mas DANE é muito mais difícil de implantar (DNSSEC obrigatório) e menos bem suportado pelos grandes fornecedores (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 registo TLSA em prioridade. Se ele suportar apenas MTA-STS, usará a política HTTPS. Assim 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 ligação de um servidor emissor ao seu domínio não é protegida pelo MTA-STS. O servidor precisa primeiro descarregar e armazenar em cache a sua política. Se um atacante bloquear essa primeira requisição HTTPS, o servidor não saberá que o MTA-STS está ativo. As ligaçõ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 ligação.

Google e Microsoft suportam DANE?

A Microsoft está a implantar 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 receção (sem registos TLSA publicados), mas verifica e respeita os registos 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 o seu registo TXT _mta-sts está publicado e se o seu ficheiro de política está acessível via HTTPS. Para DANE, verifique se os seus registos 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.

Descarregue as tabelas comparativas

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

• Descarregar comparativo (CSV)
• Descarregar comparativo (JSON)

📖 Glossário

• MTA-STS: Mail Transfer Agent Strict Transport Security (RFC 8461). Política publicada via HTTPS que impõe a encriptação TLS para a receçã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 registos TLSA, verificado por DNSSEC.
• TLSA: tipo de registo 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 ligaçã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 a sua falsificação.
• STARTTLS: extensão SMTP (RFC 3207) que permite negociar uma ligação TLS após o estabelecimento de uma ligaçã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

Fontes

• RFC 8461 - SMTP MTA Strict Transport Security (MTA-STS)
• RFC 7672 - SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE)
• RFC 6698 - The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security Protocol
• RFC 8460 - SMTP TLS Reporting (TLS-RPT)
• Google Transparency Report - Email encryption in transit