O que este inspetor DANE TLSA verifica?
Um registro TLSA dessincronizado pode bloquear seus emails sem aviso. Este checker detecta o problema antes dos seus remetentes.
A ferramenta realiza 5 verificações para cada domínio:
- Resolução MX: Identifica os servidores de email do domínio
- Pesquisa TLSA: Consulta
_25._tcp.hostnamepara os registros TLSA - Verificação DNSSEC: Controla que a cadeia de assinaturas está completa
- Validação de sintaxe: Verifica a conformidade RFC 6698/7672
- Correspondência de certificado: Compara os dados TLSA com o certificado atual do servidor
Digite seu domínio acima para iniciar a verificação.
Entendendo os registros DANE TLSA
Localização DNS
O local de publicação do TLSA depende do hostname do servidor MX, não do domínio em si:
_25._tcp.mail.captaindns.com. IN TLSA 3 1 1 2bb183af2e2b295b...
Importante: O hostname deve ser o do servidor MX, não o domínio. Se captaindns.com tem como MX mail.captaindns.com, o TLSA vai em _25._tcp.mail.captaindns.com.
Estrutura do registro
| Campo | Valores | Significado |
|---|---|---|
| Certificate Usage | 0 (PKIX-TA), 1 (PKIX-EE), 2 (DANE-TA), 3 (DANE-EE) | Tipo de restrição |
| Selector | 0 (Cert), 1 (SPKI) | Parte do certificado comparada |
| Matching Type | 0 (Full), 1 (SHA-256), 2 (SHA-512) | Método de comparação |
| Certificate Data | Hexadecimal | Hash ou dados completos |
Configuração recomendada para SMTP
3 1 1 <sha256-hash>
- Usage 3 (DANE-EE): Não precisa de validação PKIX
- Selector 1 (SPKI): Sobrevive às renovações com a mesma chave
- Matching Type 1 (SHA-256): Compacto e seguro
O papel do DNSSEC
DANE não funciona sem DNSSEC. Se você não ativar DNSSEC, seus registros TLSA serão ignorados por todos os MTA. Veja por quê:
Cadeia de confiança
Raiz DNS (.) → TLD (.com) → Domínio (captaindns.com) → TLSA record
DNSSEC DNSSEC DNSSEC Assinado
Cada nível da hierarquia DNS deve ser assinado. Se um elo estiver faltando, os registros TLSA são considerados não autenticados e ignorados. Verifique cada nível com nosso checker.
O que nossa ferramenta verifica
| Verificação | Descrição | Impacto se falhar |
|---|---|---|
| Zona assinada | O domínio tem chaves DNSSEC | TLSA records ignorados |
| Cadeia válida | As assinaturas são verificáveis | TLSA records ignorados |
| Assinatura não expirada | Os RRSIG ainda são válidos | TLSA records ignorados temporariamente |
Problemas comuns detectados
Nenhum registro TLSA encontrado
Causa: O domínio não configurou DANE Impacto: Sem proteção DANE para email de entrada Correção: Gere um registro DANE TLSA e publique no DNS
DNSSEC ausente
Causa: O domínio não está assinado por DNSSEC Impacto: Os registros TLSA são ignorados mesmo se existirem Correção: Ative DNSSEC no seu registrar e depois no seu provedor DNS
Hash de certificado dessincronizado
Causa: O certificado TLS foi renovado sem atualização do TLSA Impacto: Os MTA DANE-aware recusam a conexão ou voltam ao oportunista Correção: Atualize o hash TLSA com o novo certificado. Use DANE-TA (usage 2) ou SPKI selector (1) com reutilização de chave para evitar esse problema.
TLSA no local errado
Causa: Registro publicado para o domínio em vez do servidor MX
Impacto: Os servidores remetentes não encontram o registro
Correção: Publique em _25._tcp.<hostname-mx>, não em _25._tcp.<domínio>
Estratégia de rotação de certificado com DANE
A rotação de certificado é o principal desafio operacional com DANE. Escolha uma das três estratégias abaixo conforme seu caso:
Estratégia 1: DANE-TA (recomendado para Let's Encrypt)
Fixe o certificado CA em vez do certificado do servidor:
2 0 1 <sha256-do-certificado-CA>
Vantagem: O TLSA permanece válido enquanto a mesma CA assinar seus certificados. Desvantagem: Menos rigoroso que uma fixação direta.
Estratégia 2: DANE-EE com reutilização de chave
Mantenha a mesma chave privada entre renovações:
3 1 1 <sha256-da-chave-publica>
Vantagem: Fixação forte + sobrevive às renovações.
Desvantagem: Requer configurar a reutilização de chave (ex: --reuse-key no Certbot).
Estratégia 3: Registro duplo (rollover)
Publique ambos os TLSA antes da rotação:
_25._tcp.mail.captaindns.com. IN TLSA 3 1 1 <hash-certificado-atual>
_25._tcp.mail.captaindns.com. IN TLSA 3 1 1 <hash-certificado-futuro>
Após a rotação, remova o hash antigo. Use nosso DANE TLSA Checker para validar cada etapa.
DANE e SMTP: proteção do email em trânsito
Como DANE funciona para SMTP
Quando você envia um email para um domínio protegido por DANE, acontece o seguinte:
- O servidor remetente resolve o MX de
captaindns.com - Ele procura os registros TLSA para o servidor MX
- Ele verifica que a resposta TLSA é assinada por DNSSEC
- Ele conecta via STARTTLS e compara o certificado com os dados TLSA
- Se o certificado corresponder → conexão segura confirmada
- Se não corresponder → recusa entregar (ao contrário do TLS oportunista)
Diferença com o TLS oportunista
| Aspecto | TLS oportunista | DANE |
|---|---|---|
| Verificação de certificado | Nenhuma (aceita tudo) | Via registro TLSA |
| Proteção MITM | Não | Sim |
| Fallback não-TLS | Sim | Não (por padrão) |
| Pré-requisito | Nenhum | DNSSEC |
FAQ - Perguntas frequentes
P: O que o DANE TLSA Checker verifica?
R: Nosso checker realiza um lookup DNS dos registros TLSA no seu domínio, valida sua sintaxe, verifica o status da assinatura DNSSEC, controla a correspondência com o certificado do servidor de email, e sinaliza problemas de configuração.
P: Por que meu DANE TLSA check falha?
R: Causas comuns: DNSSEC ausente no domínio, registros TLSA não publicados no local correto (_25._tcp.mail.captaindns.com), hash de certificado dessincronizado após renovação, ou combinação usage/selector/matching type incorreta.
P: Qual é o nome DNS correto para os registros TLSA SMTP?
R: Os registros TLSA SMTP devem ser publicados em _porta._protocolo.hostname, tipicamente _25._tcp.mail.captaindns.com. O hostname deve ser o do servidor MX de destino, não o domínio em si.
P: Como DANE protege o email em trânsito?
R: DANE impede ataques man-in-the-middle nas conexões SMTP, permitindo que o servidor remetente verifique o certificado TLS via DNS/DNSSEC, em vez de depender unicamente das autoridades de certificação.
P: Com que frequência verificar meus registros DANE TLSA?
R: Verifique após cada renovação de certificado TLS, após qualquer alteração DNS, e mensalmente. A expiração de certificado é a causa número 1 das falhas DANE.
P: DANE funciona com certificados Let's Encrypt?
R: Sim, mas planeje as renovações de 90 dias. DANE-TA (usage 2) com o certificado CA do Let's Encrypt é mais fácil. DANE-EE (usage 3) com reutilização de chave (--reuse-key no Certbot) também funciona.
Ferramentas complementares
| Ferramenta | Utilidade |
|---|---|
| DANE TLSA Validator | Validar a sintaxe antes da publicação |
| DANE TLSA Generator | Criar um registro TLSA a partir de um certificado |
| Inspetor MTA-STS | Verificar a política MTA-STS (segurança TLS alternativa) |
| Inspetor TLS-RPT | Monitorar falhas TLS via relatórios |
| SMTP Check | Verificar a conexão STARTTLS que DANE protege |
| Auditoria de domínio de email | Auditoria completa da autenticação de email |
Recursos úteis
- RFC 6698 - DANE TLSA (especificação original)
- RFC 7671 - Updates to DANE (atualizações operacionais)
- RFC 7672 - SMTP Security via DANE (DANE para SMTP)
- Microsoft - DANE with DNSSEC (guia Exchange Online)
- Let's Encrypt - Using DANE (dicas DANE com LE)