Porque verificar o 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 aceite 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 registo TLSA mal posicionado, uma zona não assinada por DNSSEC ou um hash dessincronizado após renovação do certificado bastam para invalidar silenciosamente o seu deploy. Nenhuma mensagem de erro chega ao MTA emissor: a ligação volta ao TLS oportunista sem ruído e o seu fluxo SMTP perde a proteção que acreditava ter.
Verificar o seu DANE TLSA em tempo real torna-se indispensável:
- Após a publicação inicial: confirmar que o registo é 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 fornecedor de e-mail: Microsoft 365, Google Workspace e fornecedores tradicionais não oferecem o mesmo nível de suporte ao DANE
Como usar este checker em 3 passos
Passo 1: introduzir o domínio a analisar
Introduza 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 gere 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é à 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? |
| Registo TLSA | Conteúdo bruto publicado em _25._tcp.<host> |
| Usage / selector / matching | Decomposição dos três primeiros campos com o seu significado |
| Hash publicado | Dados hexadecimais para comparar com o certificado servido |
| Certificado STARTTLS | Certificado servido na porta 25 e o 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 em falta, 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), registos 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 registo TLSA
O registo TLSA é publicado numa 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 registo 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 a ser a norma de facto:
- Usage 3 (DANE-EE): a confiança está ancorada na sua chave, independentemente de qualquer autoridade de certificação
- Selector 1 (SPKI): o registo 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 registo TLSA é ignorado por qualquer MTA conforme. O checker limita explicitamente a pontuação a 30/100 assim que a cadeia DNSSEC está quebrada ou em falta.
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 registo 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 os seus MX apontam para um subdomínio numa zona separada, é essa zona que deve estar assinada.
- Registos DS em falta no registrar: 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 partilhado, a chave pública permanece idêntica entre renovações. O hash SPKI nunca muda e o registo 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 1 1 <sha256-spki-do-intermediario>
Fixe o intermediário que o servidor envia de facto (Let's Encrypt R10 ou R11), não a raiz. A RFC 7671 secção 5.2.2 exige que o certificado fixado conste da cadeia TLS apresentada pelo servidor, e os MTA não colocam lá a raiz: um 2 0 1 assente em ISRG Root X1 não valida, a menos que o servidor seja reconfigurado para juntar essa raiz. Vantagem: nenhuma atualização DNS enquanto o intermediário se mantiver. Desvantagem: confiança delegada à CA, portanto menos rigoroso que DANE-EE. Na dúvida, convém ficar por DANE-EE (3) + SPKI (1), que não tem esta restrição de cadeia.
Estratégia 3: registo 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 ligação se pelo menos um registo corresponder ao certificado apresentado. Após a rotação, remova o hash antigo.
O checker reconhece a presença de registos múltiplos e rotula-os 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 registo TLSA - Valida a cadeia DNSSEC até à 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: ligação segura confirmada
- Caso contrário: recusa de entrega (diferença fundamental em relação ao TLS oportunista)
DANE vs TLS oportunista
| Aspeto | 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 registo TLSA encontrado
Causa: o domínio não configurou DANE, ou o registo está publicado na posição errada.
Solução: gere e publique um registo TLSA em _25._tcp.<host-mx>. O nosso guia de instalação DANE TLSA para Postfix, BIND e Let's Encrypt cobre o deploy passo a passo.
DNSSEC em falta ou quebrado
Causa: a zona não está assinada, ou os DS não foram enviados ao registrar.
Solução: ative o DNSSEC no seu fornecedor de DNS, exporte os DS e publique-os no seu registrar. 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 registo invariante à renovação. Caso contrário, atualize o hash imediatamente e adote a estratégia de registo duplo para as próximas rotações.
TLSA na posição errada
Causa: registo 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 fornecedores não assinam as suas zonas DNS, portanto o DANE não é aplicável no lado de entrada.
Solução: implante MTA-STS em vez do DANE para esses fornecedores. O MTA-STS apoia-se 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 + registo 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 alojados 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 registo ANTES da publicação DNS |
| Gerador DANE TLSA | Criar um registo TLSA a partir de um certificado ou de uma chave |
| MTA-STS Checker | Verificar a política MTA-STS complementar |
| TLS-RPT Checker | Monitorizar 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)