Por que verificar seu DANE TLSA
O transporte SMTP em TLS oportunista deixa a porta aberta para dois cenários discretos: um atacante em posição intermediária que remove STARTTLS para forçar texto puro, ou um certificado falso aceito por um MTA emissor que não consegue distinguir o real do falso. DANE fecha essa brecha publicando um hash do certificado esperado no DNS, assinado por DNSSEC.
Mas o DANE é exigente: um registro TLSA mal posicionado, uma zona não assinada por DNSSEC ou um hash dessincronizado após renovação do certificado bastam para invalidar silenciosamente seu deploy. Nenhuma mensagem de erro chega ao MTA emissor: a conexão volta ao TLS oportunista sem ruído e seu fluxo SMTP perde a proteção que você acreditava ter.
Verificar seu DANE TLSA em tempo real torna-se indispensável:
- Após a publicação inicial: confirmar que o registro é resolvido, está assinado por DNSSEC e o hash corresponde ao certificado servido
- Após qualquer renovação de certificado: a causa número 1 das falhas DANE é a dessincronização hash/certificado
- Auditoria de segurança de e-mail: validar que o DANE cobre todos os MX e que nenhuma ponta fica em TLS oportunista
- Antes de migrar o provedor de e-mail: Microsoft 365, Google Workspace e provedores tradicionais não oferecem o mesmo nível de suporte ao DANE
Como usar este checker em 3 passos
Passo 1: digitar o domínio a analisar
Digite o domínio de e-mail exatamente como ele aparece nos seus endereços:
captaindns.com(domínio principal)marketing.captaindns.com(subdomínio, se você gerencia várias zonas)
A ferramenta enumera automaticamente os MX, depois consulta _25._tcp.<host-mx> para cada um. A validação DNSSEC sobe a cadeia completa até a raiz.
Passo 2: ler os resultados por MX
O checker exibe, para cada MX:
| Elemento | Descrição |
|---|---|
| Status DNSSEC | A zona do host MX está assinada e a cadeia de confiança completa? |
| Registro TLSA | Conteúdo bruto publicado em _25._tcp.<host> |
| Usage / selector / matching | Decomposição dos três primeiros campos com seu significado |
| Hash publicado | Dados hexadecimais para comparar com o certificado servido |
| Certificado STARTTLS | Certificado servido na porta 25 e seu hash calculado |
| Correspondência | O hash publicado corresponde byte a byte ao certificado apresentado? |
Passo 3: aplicar as correções
Os diagnósticos são classificados por gravidade:
- Bloqueante: DNSSEC ausente, TLSA não encontrado, hash desalinhado. O deploy DANE não protege ninguém no estado atual.
- Aviso: combinação não recomendada (usage 0 ou 1 sem CA controlada), matching type 0 que publica o certificado bruto, TTL anormalmente longo.
- Info: MX sem suporte DANE esperado (Google Workspace), registros múltiplos compatíveis com uma rotação de chave em curso.
Corrija a zona DNS, aguarde a propagação (TTL) e relance o checker para confirmar.
Anatomia de um registro TLSA
O registro TLSA é publicado em uma posição precisa e contém quatro campos rigorosamente especificados pela RFC 6698.
Posição DNS
_25._tcp.mail.captaindns.com. IN TLSA 3 1 1 2bb183af2e2b295b...
O owner name segue o padrão _<porta>._<protocolo>.<host>. Para SMTP de entrada, é invariavelmente _25._tcp.<host-mx>. Publicar o registro no apex do domínio em vez do nome do host MX é o erro mais frequente: nenhum MTA o encontra.
Os quatro campos
| Campo | Valores | Significado |
|---|---|---|
| Usage | 0 (PKIX-TA), 1 (PKIX-EE), 2 (DANE-TA), 3 (DANE-EE) | Ancoragem de confiança |
| Selector | 0 (cert completo), 1 (SubjectPublicKeyInfo) | Parte hasheada |
| Matching type | 0 (bruto), 1 (SHA-256), 2 (SHA-512) | Algoritmo |
| Dado | hexadecimal | Hash ou bloco binário |
A combinação recomendada para SMTP
3 1 1 continua sendo o padrão de fato:
- Usage 3 (DANE-EE): a confiança está ancorada na sua chave, independentemente de qualquer autoridade de certificação
- Selector 1 (SPKI): o registro continua válido enquanto a chave pública for preservada, mesmo após renovação do certificado
- Matching type 1 (SHA-256): 32 bytes, suportado universalmente, suficientemente robusto
DNSSEC: o pré-requisito incontornável
Sem DNSSEC, um registro TLSA é ignorado por qualquer MTA conforme. O checker limita explicitamente a pontuação a 30/100 assim que a cadeia DNSSEC está quebrada ou ausente.
Cadeia de confiança a validar
Raiz (.) -> TLD (.com) -> Domínio (captaindns.com) -> _25._tcp.mail.captaindns.com
DNSSEC DNSSEC DNSSEC Assinado
Cada elo deve estar assinado. Uma zona pai não assinada invalida tudo o que vem depois, independentemente da qualidade do registro TLSA mais abaixo. O checker sobe a cadeia e identifica o elo defeituoso.
Armadilhas comuns ligadas ao DNSSEC
- Zona do domínio assinada mas não a zona do host MX: se seus MX apontam para um subdomínio em uma zona separada, é essa zona que deve estar assinada.
- Registros DS ausentes no registrador: a zona assinada localmente continua invisível para resolvers externos se o DS não foi enviado ao TLD.
- RRSIG expiradas: as assinaturas DNSSEC têm um período de validade. Uma renovação malsucedida coloca a zona em estado bogus.
O checker indica qual desses casos está em jogo.
Estratégias de rotação de chave
A rotação de certificado sem interrupção de serviço é o principal desafio operacional do DANE. Coexistem três estratégias.
Estratégia 1: selector SPKI + reutilização de chave
Com --reuse-key (Certbot) ou um --key-type rsa compartilhado, a chave pública permanece idêntica entre renovações. O hash SPKI nunca muda e o registro 3 1 1 <hash-spki> continua válido indefinidamente. É a estratégia mais simples.
Estratégia 2: DANE-TA na autoridade de certificação
2 0 1 <sha256-do-certificado-CA>
Você fixa o certificado raiz da sua CA (Let's Encrypt ISRG Root X1, por exemplo) em vez do seu próprio certificado. Vantagem: nenhuma atualização DNS na renovação. Desvantagem: confiança delegada à CA, portanto menos rigoroso que DANE-EE.
Estratégia 3: registro duplo durante a transição
_25._tcp.mail.captaindns.com. IN TLSA 3 1 1 <hash-chave-atual>
_25._tcp.mail.captaindns.com. IN TLSA 3 1 1 <hash-chave-seguinte>
Publique o hash da próxima chave 7 dias antes da rotação (no mínimo o dobro do TTL máximo). MTAs conformes aceitam uma conexão se pelo menos um registro corresponder ao certificado apresentado. Após a rotação, remova o hash antigo.
O checker reconhece a presença de registros múltiplos e os rotula como rotação de chave em curso em vez de erro.
DANE e SMTP: o que acontece na entrega
- O servidor emissor resolve os MX de
captaindns.com - Consulta
_25._tcp.<mx>para recuperar o registro TLSA - Valida a cadeia DNSSEC até a raiz
- Abre STARTTLS na porta 25 e recupera o certificado apresentado
- Calcula o hash do certificado conforme o matching type publicado
- Se o hash corresponder: conexão segura confirmada
- Caso contrário: recusa de entrega (diferença fundamental em relação ao TLS oportunista)
DANE vs TLS oportunista
| Aspecto | TLS oportunista | DANE |
|---|---|---|
| Verificação de certificado | Nenhuma (aceita tudo) | Hash assinado por DNSSEC obrigatório |
| Proteção MITM | Não | Sim |
| Fallback sem TLS | Sim (downgrade silencioso) | Não |
| Pré-requisito | Nenhum | DNSSEC na zona do MX |
Diagnósticos comuns e soluções
Nenhum registro TLSA encontrado
Causa: o domínio não configurou DANE, ou o registro está publicado na posição errada.
Solução: gere e publique um registro TLSA em _25._tcp.<host-mx>. Nosso guia de instalação DANE TLSA para Postfix, BIND e Let's Encrypt cobre o deploy passo a passo.
DNSSEC ausente ou quebrado
Causa: a zona não está assinada, ou os DS não foram enviados ao registrador.
Solução: ative o DNSSEC no seu provedor de DNS, exporte os DS e publique-os no seu registrador. Verifique a propagação com uma ferramenta DNSSEC dedicada antes de relançar este checker.
Hash de certificado dessincronizado
Causa: o certificado TLS foi renovado e o hash publicado já não está atualizado.
Solução: use o selector SPKI (1) com --reuse-key para tornar o registro invariante à renovação. Caso contrário, atualize o hash imediatamente e adote a estratégia de registro duplo para as próximas rotações.
TLSA na posição errada
Causa: registro publicado no domínio raiz em vez do nome do host MX, ou na porta errada.
Solução: republique exatamente em _25._tcp.<host-mx>. Para um MX mail.captaindns.com, é _25._tcp.mail.captaindns.com. Mais nada.
Microsoft 365 / Google Workspace sem DANE de entrada
Causa: esses provedores não assinam suas zonas DNS, portanto o DANE não é aplicável no lado de entrada.
Solução: implante MTA-STS no lugar do DANE para esses provedores. O MTA-STS se apoia em HTTPS em vez de DNSSEC e é suportado pelo Google Workspace e pelo Microsoft 365.
DANE e MTA-STS: abordagens complementares
Os dois protocolos formam uma defesa em profundidade, não uma escolha exclusiva.
| Critério | DANE | MTA-STS |
|---|---|---|
| Mecanismo | DNSSEC + registro TLSA | HTTPS + política em texto |
| Dependência | DNSSEC necessário | HTTPS necessário |
| Confiança | Criptográfica (DNS assinado) | PKI (CA HTTPS) |
| Suporte Postfix / Exim | Excelente | Bom |
| Suporte Microsoft 365 | Parcial (saída 2022, entrada 2024) | Completo |
| Suporte Google Workspace | Nenhum (zonas não assinadas) | Completo |
| Deploy | Complexo (DNSSEC) | Mais simples |
Recomendação: implante os dois. DANE para os domínios hospedados em Postfix ou Exim, MTA-STS para os domínios delegados ao Microsoft 365 ou Google Workspace. A cobertura máxima impõe a combinação.
Ferramentas complementares e recursos
| Ferramenta | Utilidade |
|---|---|
| Validador DANE TLSA | Validar a sintaxe de um registro ANTES da publicação DNS |
| Gerador DANE TLSA | Criar um registro TLSA a partir de um certificado ou de uma chave |
| MTA-STS Checker | Verificar a política MTA-STS complementar |
| TLS-RPT Checker | Monitorar falhas TLS pelos relatórios |
| Inspetor DMARC | Completar a autenticação de e-mail |
| Auditoria email-authentication | Visão geral das ferramentas de autenticação de e-mail |
Guias relacionados
- DANE TLSA: o guia completo - Entender DANE de ponta a ponta, do DNSSEC ao deploy SMTP.
- DANE TLSA em Postfix, BIND e Let's Encrypt - Instalação passo a passo com rotação de chave.
- DANE TLSA e Microsoft 365 Exchange Online - Suporte de DANE de entrada e saída no Exchange Online.
- DANE TLSA: 12 casos práticos de troubleshooting - Diagnóstico e resolução de incidentes DANE.
- MTA-STS vs DANE: comparativo detalhado - Escolher ou combinar os dois protocolos.
Especificações
- RFC 6698 - DANE TLSA (especificação original)
- RFC 7671 - Updates to DANE (esclarecimentos operacionais)
- RFC 7672 - SMTP Security via DANE (DANE para SMTP)