DANE/TLSA: o guia completo para autenticar certificados de email via DNS
Por CaptainDNS
Publicado em 21 de fevereiro de 2026
- DANE vincula certificados TLS a nomes de domínio por meio de registros 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 registros 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 monitorar as falhas DANE em produção e antecipar problemas de rotação
Quando um servidor SMTP envia um email, como ele sabe que o servidor destinatário é o correto? Por padrão, ele não sabe. STARTTLS criptografa a conexã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 conexão, apresentar um certificado falso e ler 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 registro TLSA, verifica que o certificado apresentado corresponde e recusa a conexã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 registro TLSA, os usos recomendados para email, a implantação passo a passo, a complementaridade com o MTA-STS e o monitoramento via TLS-RPT. Ele é destinado a administradores de email, engenheiros de infraestrutura e DevOps que gerenciam servidores de email.
Como funciona o DANE?
O problema do TLS oportunista
O SMTP foi projetado sem criptografia. STARTTLS foi adicionado depois (RFC 3207) para permitir que os servidores negociassem uma conexã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 criptografia.
Mesmo quando o TLS é negociado, o servidor remetente não verifica o certificado por padrão. Ele aceita qualquer certificado, incluindo um certificado autoassinado apresentado por um atacante. A criptografia 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 seu servidor deve apresentar. O servidor remetente:
- Resolve o MX do domínio destinatário
- Busca o registro TLSA associado ao servidor MX
- Verifica a assinatura DNSSEC da resposta
- Estabelece a conexão TLS e compara o certificado apresentado com a impressão digital TLSA
- Recusa a conexã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 registro TLSA e apresentar sua própria impressão digital de certificado. A cadeia de confiança vai da raiz DNS até o registro 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 registro TLSA é ignorado.
Anatomia de um registro TLSA
Um registro 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 você 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 (seçã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...
Vantagens do DANE-EE:
- Sem dependência de CA: você controla totalmente a confiança
- Certificados autoassinados aceitos: a CA não precisa ser reconhecida
- Rotação simplificada: com SPKI, o hash não muda se você mantém a mesma chave
- Sem verificação da cadeia: apenas o certificado end-entity importa
DANE-TA (usage 2): quando usar a CA?
DANE-TA (2 0 1 ou 2 1 1) é útil quando você gerencia vários servidores assinados pela mesma CA interna. Em vez de publicar um TLSA por servidor, você publica a impressão digital da CA e todos os certificados assinados por ela são aceitos.
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.
DANE para email: RFC 7672
A RFC 7672 adapta o DANE ao contexto SMTP. Algumas especificidades:
STARTTLS e a porta 25
Para email, o DANE se aplica na porta 25 com STARTTLS (não na porta 465 com TLS implícito). O servidor remetente inicia uma conexã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 registro TLSA.
Nomenclatura TLSA para servidores MX
O nome do registro 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 seu próprio registro TLSA.
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) - Conexão TCP → SMTP → STARTTLS → Verificar o certificado contra o TLSA
- Se o certificado corresponder: entregar. Senão: recusar.
Implantar DANE em 6 etapas
1. Ativar DNSSEC na sua zona
Esse é o pré-requisito absoluto. Entre em contato com seu registrar ou seu provedor 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.
2. Gerar o registro TLSA
Gere seu registro com uma ferramenta dedicada (veja o CTA no final do artigo). Forneça 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 registro 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: registro 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 registro 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. Planejar a rotação dos certificados
Esse é o ponto crítico. Quando você renovar seu certificado:
- Com a mesma chave (selector SPKI): o hash não muda, nada a fazer
- Com uma nova chave: publique o novo TLSA antes de implantar o novo certificado. Mantenha os dois registros durante o período de transição.
DANE e MTA-STS: complementaridade, não concorrência
DANE e MTA-STS protegem contra ataques ao transporte SMTP, mas por mecanismos diferentes.
O que o DANE faz que o MTA-STS não faz
- Verifica o certificado via DNS: sem dependência de CA
- Aceita certificados autoassinados: o DNS é a autoridade
- Resiste ao comprometimento de uma CA: apenas o DNS do domínio importa
O que o MTA-STS faz que o DANE não faz
- Funciona sem DNSSEC: usa HTTPS como canal autenticado
- Implantação mais simples: um arquivo de texto em um servidor web
- Modo testing: permite monitorar antes de impor
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
Monitorar DANE com TLS-RPT
TLS-RPT (RFC 8460) é o companheiro indispensável do DANE em produção. Os relatórios JSON diários incluem as falhas específicas do DANE:
dane-required: o servidor remetente exige DANE, mas não encontra um TLSA válidotlsa-invalid: o registro TLSA está mal formadodnssec-invalid: a validação DNSSEC falhoudane-policy-failure: o certificado não corresponde ao registro TLSA
Sem TLS-RPT, você não saberia que uma renovação de certificado quebrou a correspondência TLSA. Consulte nosso guia completo TLS-RPT para a configuração.
Plano de ação recomendado
- Verifique seu DNSSEC: sua zona deve estar assinada com uma cadeia de confiança completa
- Escolha o uso
3 1 1: DANE-EE + SPKI + SHA-256, o padrão para SMTP - Gere e publique o TLSA: use o gerador, publique, aguarde a propagação
- Valide com o inspetor: verifique TLSA + DNSSEC + correspondência do certificado
- Ative TLS-RPT: receba os relatórios de falhas para antecipar problemas
- Documente a rotação: procedimento de renovação de certificado com atualização do TLSA
Verifique 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 registro? O gerador DANE/TLSA produz um registro TLSA pronto para publicar.
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 registro 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 conexão é recusada.
Qual é a diferença entre DANE e MTA-STS?
DANE usa DNSSEC e registros 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 registros TLSA não são confiá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 você renovar o certificado com a mesma chave privada. Let's Encrypt renova a cada 90 dias, mas se você mantiver a chave, o TLSA permanece válido. Se você regenerar a chave, publique o novo TLSA antes da implantação do certificado.
Quais provedores de email suportam DANE?
Os principais provedores que suportam DANE em envio (verificação DANE de saída) incluem Postfix, Gmail (verificação parcial) e vários provedores europeus. A Microsoft anunciou o suporte ao DANE para o Exchange Online. Na recepçã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 monitorar falhas DANE em produção?
Ative TLS-RPT (RFC 8460) publicando um registro 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.
Guias de DANE/TLSA relacionados
- Configurar DANE/TLSA com Postfix, Bind e Let's Encrypt (em breve)
- Solução de problemas DANE/TLSA: diagnosticar e corrigir erros comuns (em breve)
- Implantar DANE para um servidor Exchange ou Microsoft 365 (em breve)
Fontes
- RFC 6698 - The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA
- RFC 7672 - SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS)
- RFC 8460 - SMTP TLS Reporting
- Microsoft - SMTP DNS-Based Authentication of Named Entities (DANE)
