DANE/TLSA: o guia completo para autenticar certificados de email via DNS

Q: Como monitorizar falhas DANE em produção?

Ative TLS-RPT (RFC 8460) publicando um registo DNS _smtp._tls com um endereço de recebimento. Os servidores remetentes enviarão relatórios JSON diários detalhando as falhas DANE: certificado não correspondente, DNSSEC inválido, TLSA ausente. Sem TLS-RPT, as falhas passam despercebidas.

Por CaptainDNS
Publicado em 21 de fevereiro de 2026

Atualizado em 9 de julho de 2026

DANE/TLSA: autenticar certificados TLS de servidores de email via DNS e DNSSEC

TL;DR

DANE vincula certificados TLS a nomes de domínio por meio de registos DNS TLSA assinados por DNSSEC, eliminando a dependência das autoridades certificadoras
O uso DANE-EE com SPKI e SHA-256 (3 1 1) é o gold standard para proteger o SMTP
DNSSEC é um pré-requisito absoluto: sem zona assinada, os registos TLSA são ignorados
DANE e MTA-STS são complementares: DANE verifica o certificado via DNS, MTA-STS impõe TLS via HTTPS
TLS-RPT (RFC 8460) permite monitorizar as falhas DANE em produção e antecipar problemas de rotação

Em 2026, mais de 95% dos emails recebidos pelo Gmail circulam através de TLS (Google Transparency Report). Ainda assim: quando um servidor SMTP envia um email, como é que ele sabe que o servidor destinatário é o correto? Por predefinição, ele não sabe. STARTTLS encripta a ligação de forma oportunista, mas não verifica a identidade do servidor nem a autenticidade do certificado. Um atacante posicionado na rede pode interceptar a ligação, apresentar um certificado falso e ler as suas mensagens.

DANE (DNS-based Authentication of Named Entities) resolve esse problema publicando diretamente no DNS as informações do certificado esperado. O servidor remetente consulta o registo TLSA, verifica que o certificado apresentado corresponde e recusa a ligação em caso de divergência. O ponto-chave: DNSSEC assina essa informação, garantindo que ela não foi falsificada.

Este guia abrange o funcionamento do DANE, a anatomia de um registo TLSA, os usos recomendados para email, a implantação passo a passo, a complementaridade com o MTA-STS e a monitorização via TLS-RPT. Ele é destinado a administradores de email, engenheiros de infraestrutura e DevOps que gerem servidores de email.

Como funciona o DANE?

O problema do TLS oportunista

O SMTP foi concebido em 1982 sem qualquer encriptação. O STARTTLS só chegou em 2002 (RFC 3207), para permitir que os servidores negociassem uma ligação TLS. Mas essa negociação é oportunista: se o servidor remoto não suporta TLS, a mensagem é enviada em texto puro. Pior, um atacante pode remover o comando STARTTLS da resposta SMTP (ataque downgrade) e forçar o envio sem encriptação.

Mesmo quando o TLS é negociado, o servidor remetente não verifica o certificado por predefinição. Ele aceita qualquer certificado, incluindo um certificado autoassinado apresentado por um atacante. A encriptação existe, mas a autenticação está ausente.

DANE: o certificado no DNS

DANE inverte a lógica. Em vez de confiar em uma autoridade certificadora (CA) externa, o proprietário do domínio publica no DNS a impressão digital do certificado que o seu servidor deve apresentar. O servidor remetente:

Resolve o MX do domínio destinatário
Busca o registo TLSA associado ao servidor MX
Verifica a assinatura DNSSEC da resposta
Estabelece a ligação TLS e compara o certificado apresentado com a impressão digital TLSA
Recusa a ligação se o certificado não corresponder

A cadeia de confiança DNSSEC

DANE só funciona se a zona DNS estiver assinada por DNSSEC. Sem DNSSEC, um atacante poderia falsificar o registo TLSA e apresentar a sua própria impressão digital de certificado. Ora, segundo o APNIC, em 2026 menos de 40% dos domínios validam DNSSEC, o que continua a travar a adoção do DANE. A cadeia de confiança vai da raiz DNS até o registo TLSA:

. (raiz) → com. → captaindns.com. → _25._tcp.mail.captaindns.com. TLSA

Cada elo é assinado pela zona superior. Se um único elo estiver quebrado (zona não assinada, assinatura expirada), a validação DNSSEC falha e o registo TLSA é ignorado.

Fluxo de verificação DANE: do DNS ao certificado TLS passando pela validação DNSSEC

Anatomia de um registo TLSA

TLSA é um tipo de registo DNS dedicado (RRTYPE 52, definido na RFC 6698), com o seu próprio formato binário. Diferente de SPF, DKIM ou DMARC que usam registos TXT, TLSA é um tipo nativo: os clientes DNS consultam especificamente o tipo TLSA (QTYPE=52). Publicar dados TLSA em um registo TXT não funcionaria.

Um registo TLSA é composto por quatro campos:

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

O nome segue a convenção _porta._protocolo.hostname. Para um servidor SMTP na porta 25, é _25._tcp.mail.captaindns.com.

Usage (campo 1): o que verificar?

Valor	Nome	Descrição
0	PKIX-TA	Verifica o certificado CA + a cadeia CA clássica
1	PKIX-EE	Verifica o certificado do servidor + a cadeia CA clássica
2	DANE-TA	Verifica o certificado CA, sem exigir a cadeia CA clássica
3	DANE-EE	Verifica o certificado do servidor diretamente, sem CA

Selector (campo 2): qual parte do certificado?

Valor	Nome	Descrição
0	Cert	Certificado completo (DER)
1	SPKI	Apenas a chave pública (SubjectPublicKeyInfo)

SPKI (1) é recomendado: a chave pública não muda quando renova o certificado com o mesmo par de chaves. Isso simplifica a rotação.

Matching type (campo 3): formato dos dados

Valor	Nome	Descrição
0	Full	Dados brutos completos
1	SHA-256	Hash SHA-256 (32 bytes, 64 caracteres hex)
2	SHA-512	Hash SHA-512 (64 bytes, 128 caracteres hex)

SHA-256 (1) é o padrão: compacto, resistente a colisões, suportado em todos os lugares.

Qual uso TLSA escolher?

DANE-EE (usage 3): a escolha recomendada para SMTP

A RFC 7672 (secção 3.1) recomenda DANE-EE para email. A combinação 3 1 1 (DANE-EE + SPKI + SHA-256) é o gold standard:

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

Com DANE-EE, a confiança passa inteiramente pelo DNSSEC em vez das autoridades certificadoras. O certificado serve apenas como contêiner para a chave pública: a RFC 7671 (secção 5.1) especifica que nem a cadeia CA, nem o nome do host no certificado, nem a data de expiração são verificados. É uma escolha de design deliberada, não um defeito. O modelo CA clássico é inadequado para SMTP: entre as 150+ autoridades certificadoras reconhecidas, qualquer uma pode emitir um certificado para qualquer domínio. DANE-EE reduz a superfície de confiança ao único proprietário da zona DNS (RFC 7672, secção 1.3.2).

Vantagens do DANE-EE:

Sem dependência de CA: a confiança baseia-se no DNSSEC, não em 150+ autoridades
Certificados autoassinados aceites: o certificado é um contêiner de chave, não uma atestação de identidade
Sem verificação de expiração: um certificado expirado permanece válido enquanto o TLSA e DNSSEC estiverem corretos
Rotação simplificada: com SPKI, o hash não muda se mantém a mesma chave
Superfície de ataque reduzida: uma única fonte de confiança em vez de 150+

DANE-TA (usage 2): quando usar a CA?

DANE-TA (2 0 1 ou 2 1 1) é útil quando gere vários servidores assinados pela mesma CA interna. Em vez de publicar um TLSA por servidor, publica a impressão digital da CA e todos os certificados assinados por ela são aceites.

Desvantagem: se a CA for comprometida, todos os servidores estarão comprometidos.

PKIX-EE e PKIX-TA (usages 1 e 0): casos particulares

Esses usos combinam a verificação DANE com a validação CA clássica. Eles são raramente usados para SMTP, pois adicionam complexidade sem benefício claro em relação ao DANE-EE.

Árvore de decisão para escolher o uso TLSA adequado à sua infraestrutura

DANE para email: RFC 7672

A RFC 7672, publicada em outubro de 2015, adapta o DANE especificamente ao contexto SMTP. Define como um servidor remetente deve resolver e validar os registos TLSA dos servidores MX. Algumas especificidades:

STARTTLS e a porta 25

Para email, o DANE aplica-se na porta 25 com STARTTLS (não na porta 465 com TLS implícito). O servidor remetente inicia uma ligação SMTP clássica, envia EHLO, recebe o comando 250-STARTTLS e então negocia o TLS. É nesse momento que ele compara o certificado apresentado com o registo TLSA.

Nomenclatura TLSA para servidores MX

O nome do registo TLSA é construído a partir do hostname MX, não do domínio do email:

# Email destinado a user@captaindns.com
# MX de captaindns.com → mail.captaindns.com
# TLSA → _25._tcp.mail.captaindns.com

Se o domínio tiver vários MX, cada MX deve ter o seu próprio registo TLSA. Inversamente, se dois domínios de email partilham o mesmo servidor MX, eles partilham o mesmo registo TLSA: a correspondência é sempre feita pelo hostname MX, não pelo domínio destinatário (RFC 7672, secção 2.2.1).

Resolução: do domínio ao certificado

O fluxo completo para um email para user@captaindns.com:

Resolver captaindns.com → MX → mail.captaindns.com (validar DNSSEC)
Resolver _25._tcp.mail.captaindns.com → TLSA (validar DNSSEC)
Resolver mail.captaindns.com → A/AAAA (validar DNSSEC)
Ligação TCP → SMTP → STARTTLS → Verificar o certificado contra o TLSA
Se o certificado corresponder: entregar. Senão: recusar.

DNSSEC no domínio de email e no hostname MX: para proteção completa, ambas as zonas devem ser assinadas. O domínio MX de destino (mail.captaindns.com) deve ter DNSSEC para que os registos TLSA sejam validados. O domínio de email (captaindns.com) deveria também ser assinado: sem DNSSEC na zona de email, um atacante pode redirecionar os registos MX para um servidor malicioso (ataque de redirecionamento MX). O DANE protege então contra a interceptação passiva, mas não contra ataques ativos de redirecionamento MX (RFC 7672, secção 2.2.1).

Implantar DANE em 6 etapas

1. Ativar DNSSEC na sua zona

Esse é o pré-requisito absoluto. Entre em contacto com o seu registrar ou o seu fornecedor DNS para ativar o DNSSEC. Verifique se a cadeia de confiança está completa com uma ferramenta como dig +dnssec ou o verificador DNSSEC CaptainDNS. Se está a começar do zero, o nosso guia passo a passo de DNSSEC por registrar detalha o procedimento para a Cloudflare, a OVHcloud, a GoDaddy e outros.

2. Gerar o registo TLSA

Gere o seu registo com uma ferramenta dedicada (veja o CTA no final do artigo). Forneça o seu certificado PEM ou deixe a ferramenta recuperá-lo via STARTTLS. Escolha a combinação 3 1 1 (DANE-EE, SPKI, SHA-256).

3. Publicar no DNS

Adicione o registo na sua zona:

_25._tcp.mail.captaindns.com. 3600 IN TLSA 3 1 1 a0b1c2d3e4f5678901234567890abcdef0123456789abcdef0123456789abcdef

4. Verificar a configuração

Após a propagação (respeite o TTL), valide que tudo está correto: registo TLSA resolvido, DNSSEC válido, certificado correspondente. O inspetor no final do artigo permite essa verificação em poucos segundos.

5. Ativar TLS-RPT

Publique um registo TLS-RPT para receber os relatórios de falhas:

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

6. Planear a rotação dos certificados

Esse é o ponto crítico. A maioria dos incidentes DANE em produção vem de uma renovação de certificado sem atualização do TLSA. Quando renovar o seu certificado:

Com a mesma chave (selector SPKI): o hash não muda, não há nada a fazer no DNS
Com uma nova chave: publique o novo TLSA antes de implantar o novo certificado. Mantenha os dois registos durante pelo menos 2x o TTL do TLSA (ex.: TTL de 3600 s = aguardar no mínimo 2 horas)
Automatize: integre a verificação do TLSA no seu pipeline de renovação (hook do certbot, CI/CD) e apoie-a numa gestão do ciclo de vida dos certificados que monitorize as expirações e desencadeie as renovações

DANE e MTA-STS: complementaridade, não concorrência

DANE e MTA-STS protegem contra ataques ao transporte SMTP, mas por mecanismos diferentes. Nosso guia completo MTA-STS detalha o segundo aspeto.

Critério	DANE	MTA-STS
Canal de autenticação	DNSSEC (DNS assinado)	HTTPS (CA clássica)
Pré-requisito	DNSSEC ativo na zona	Servidor HTTPS + certificado válido
Certificados autoassinados	Aceites (DANE-EE)	Recusados
Resistência ao comprometimento de uma CA	Sim	Não
Modo de teste nativo	Não	Sim (`mode: testing`)
Complexidade de implantação	Média (exige DNSSEC)	Baixa (ficheiro de texto + DNS TXT)

A estratégia ideal: os dois

Implantar DANE e MTA-STS simultaneamente cobre os dois casos:

Os servidores que suportam DANE usam a verificação TLSA
Os servidores que suportam apenas MTA-STS usam a política HTTPS
Os servidores que suportam ambos têm dupla proteção

Monitorizar DANE com TLS-RPT

TLS-RPT (RFC 8460) é o companheiro indispensável do DANE em produção. Sem TLS-RPT, uma renovação de certificado que quebra a correspondência TLSA passa despercebida durante dias.

Os relatórios JSON diários incluem os códigos de falha específicos do DANE:

Código de falha	Significado	Ação corretiva
`dane-required`	Nenhum TLSA válido encontrado	Verificar a publicação e a propagação DNS
`tlsa-invalid`	Registo TLSA mal formado	Regerar com o formato correto (usage, selector, matching type)
`dnssec-invalid`	Validação DNSSEC falhada	Verificar as assinaturas RRSIG e a cadeia DS
`dane-policy-failure`	Certificado != impressão digital TLSA	Atualizar o TLSA ou voltar ao certificado anterior

Consulte o nosso guia completo TLS-RPT para a configuração e a interpretação dos relatórios.

Plano de ação recomendado

Etapa	Ação	Critério de validação
1	Verifique o seu DNSSEC	Cadeia de confiança completa (DS no TLD, RRSIG válidas)
2	Escolha o uso `3 1 1`	DANE-EE + SPKI + SHA-256
3	Gere e publique o TLSA	Registo resolvido e coerente com o certificado atual
4	Valide com o inspetor	TLSA + DNSSEC + correspondência do certificado confirmados
5	Ative o TLS-RPT	Relatórios recebidos 24-48 h após a publicação
6	Documente a rotação	Procedimento escrito para a renovação do certificado + atualização do TLSA

Verifique a sua configuração DANE agora: Use nosso inspetor DANE/TLSA para analisar a configuração DANE do seu domínio em poucos segundos. Precisa criar um registo? O gerador DANE/TLSA produz um registo TLSA pronto para publicar. Também pode validar a sintaxe bruta de um registo existente com o validador de sintaxe DANE/TLSA antes da publicação.

FAQ

O que é DANE e como funciona?

DANE (DNS-based Authentication of Named Entities) é um padrão da internet (RFC 6698) que permite publicar no DNS as informações do certificado TLS esperado para um servidor. O servidor remetente consulta o registo TLSA, verifica a assinatura DNSSEC e então compara o certificado apresentado pelo servidor com a impressão digital publicada. Se o certificado não corresponder, a ligação é recusada.

Qual é a diferença entre DANE e MTA-STS?

DANE usa DNSSEC e registos TLSA para autenticar certificados. MTA-STS usa HTTPS e autoridades certificadoras. DANE oferece segurança superior (sem dependência de CA), mas requer DNSSEC. MTA-STS é mais simples de implantar. Os dois mecanismos são complementares e podem coexistir no mesmo domínio.

O DNSSEC é obrigatório para o DANE?

Sim, DNSSEC é um pré-requisito absoluto. Sem zona assinada, os registos TLSA não são fiáveis, pois um atacante poderia falsificá-los. Servidores remetentes em conformidade com a RFC 7672 ignoram os TLSA cuja cadeia DNSSEC não é válida.

Qual uso TLSA escolher para email?

A RFC 7672 recomenda DANE-EE (usage 3) com SPKI (selector 1) e SHA-256 (matching type 1), ou seja, a combinação 3 1 1. É o gold standard para SMTP: sem dependência de CA, rotação simplificada com SPKI e compatibilidade máxima.

O DANE funciona com Let's Encrypt?

Sim, o DANE funciona com Let's Encrypt. Com DANE-EE e o selector SPKI (3 1 1), o hash não muda enquanto renovar o certificado com a mesma chave privada. Let's Encrypt renova a cada 90 dias, mas se mantiver a chave, o TLSA permanece válido. Se regenerar a chave, publique o novo TLSA antes da implantação do certificado.

Quais fornecedores de email suportam DANE?

Os principais fornecedores que suportam DANE em envio (verificação DANE de saída) incluem Postfix, Gmail (verificação parcial) e vários fornecedores europeus. A Microsoft anunciou o suporte ao DANE para o Exchange Online. Na receção, qualquer servidor com DNSSEC e um TLSA publicado é compatível. A adoção é mais forte na Europa (Alemanha, Países Baixos) do que nos Estados Unidos.

Como monitorizar falhas DANE em produção?

Ative TLS-RPT (RFC 8460) publicando um registo DNS _smtp._tls com um endereço de recebimento. Os servidores remetentes enviarão relatórios JSON diários detalhando as falhas DANE: certificado não correspondente, DNSSEC inválido, TLSA ausente. Sem TLS-RPT, as falhas passam despercebidas.

Glossário

DANE: DNS-based Authentication of Named Entities. Protocolo definido na RFC 6698 que publica no DNS informações de certificados TLS, permitindo que servidores verifiquem certificados sem depender de autoridades certificadoras.
TLSA: tipo de registo DNS usado pelo DANE para armazenar dados de associação de certificados (usage, selector, matching type e hash do certificado).
DNSSEC: DNS Security Extensions. Adiciona assinaturas criptográficas aos registos DNS, permitindo verificar que as respostas não foram manipuladas. Pré-requisito absoluto para o DANE.
DANE-EE: tipo de usage DANE 3. Verifica diretamente o certificado end-entity (servidor), sem validação da cadeia CA.
SPKI: SubjectPublicKeyInfo. A parte de chave pública de um certificado, usada como selector 1 nos registos TLSA. Preferida porque sobrevive à renovação do certificado com o mesmo par de chaves.
MTA-STS: Mail Transfer Agent Strict Transport Security (RFC 8461). Impõe a encriptação TLS para recebimento de emails por meio de uma política HTTPS.
TLS-RPT: SMTP TLS Reporting (RFC 8460). Mecanismo para receber relatórios diários sobre sucessos e falhas de negociação TLS, incluindo erros específicos do DANE.