Verificador de registros DANE/TLSA

Consulta os registros TLSA publicados pelos servidores de e-mail (hosts MX) de um domínio em vários resolvedores DNS públicos para verificar se o DANE está configurado.

Última atualização: 2026-09-20

Diagnosticar a validação de certificados mediante DANE (registros TLSA)

DANE é o arranjo pelo qual o certificado que um servidor de correio apresenta **se valida contra um registro TLSA colocado no DNS.** Esta ferramenta consulta os registros TLSA publicados pelos hosts MX de um domínio contra vários resolvedores públicos e comunica se estão configurados.

**A premissa que aqui não cabe omitir jamais é que o DANE se sustenta unicamente sobre o DNSSEC.** O que garante que um registro TLSA não foi manipulado é o próprio DNSSEC, de modo que **colocar registros TLSA num domínio sem DNSSEC habilitado não equivale a proteção alguma.** Esta é a diferença capital em relação ao MTA-STS: onde o MTA-STS deposita a sua confiança nos certificados web, **o DANE a deposita no DNSSEC.** O outro ponto que exige cuidado na operação é a renovação de certificados, pois **substituir o certificado de um servidor sem atualizar ao mesmo tempo o registro TLSA faz falhar a validação e detém a chegada do correio.** A ordem requerida é acrescentar primeiro a nova impressão, comutar, e só depois retirar a antiga.

Como se usa

Insira o domínio Indique unicamente o domínio, na forma `example.com`.
Olhe o resultado de cada host MX **Os registros TLSA residem em `_25._tcp.nomedohost` de cada host MX.**
Confirme se o DNSSEC está no seu lugar **Sem DNSSEC, um registro TLSA não oferece proteção alguma.**
Planeje o procedimento de renovação **Deixe coexistir um tempo a impressão antiga e a nova antes de comutar.**

Dicas para aproveitar melhor

Os registros TLSA não ficam sob o nome de domínio comum — eles são publicados sob um nome especial, `_25._tcp.{host MX}`. Por isso, consultar o TLSA apenas no domínio nunca encontra nada.
"DANE não configurado" não é um erro. O DANE é uma camada adicional de defesa para a criptografia de e-mail, e a maioria dos servidores de e-mail ainda não o utiliza.
O DANE só é confiável se o próprio registro TLSA do domínio estiver protegido pela cadeia de assinaturas do DNSSEC. Mesmo que um registro TLSA seja encontrado, use também a ferramenta irmã "Verificador DNSSEC" para confirmar que o domínio tem o DNSSEC habilitado.
Quando um domínio tem vários hosts MX, esta ferramenta verifica até 3 hosts, começando pelo de menor número de preferência (maior prioridade).
Se os resolvedores divergirem, o registro pode ter sido atualizado recentemente e os caches ainda não sincronizaram. Aguarde um pouco e verifique novamente.

Quando é útil

Inspecionar os seus próprios servidores de correio

Você pode achar a discrepância em que se cria colocado um TLSA que falta no host MX.

Conferir antes de renovar um certificado

**Errar a ordem detém o correio, o que faz com que conferir de antemão compense de sobra.**

Pesar DANE contra MTA-STS

**Escolha conforme onde prefira depositar a confiança, no DNSSEC ou nos certificados web; ambos podem ser adotados juntos.**

Saber até onde chegou um correspondente

Você pode ver se ele usa DANE sequer.

Termos de DANE

Registro TLSA: **O registro que coloca no DNS a impressão de um certificado ou de uma chave pública.** Reside num nome como `_25._tcp.mail.example.com`.
DNSSEC: **A premissa do DANE.** Sem ele, o próprio registro TLSA poderia ser manipulado e não se sustenta proteção alguma.
Campo de uso: O primeiro número de um registro TLSA, que declara se se refere ao certificado mesmo ou a uma autoridade de certificação.
DANE-EE: A abordagem que registra a impressão do próprio certificado do servidor. **Permite validar sem depender de autoridade alguma.**
Rotação: A tarefa de substituir um certificado e o seu registro TLSA. **Acrescente primeiro a nova impressão e retire a antiga depois.**
TLS oportunista: A abordagem antiga e optativa de cifrar ali onde a outra parte o admita. **DANE e MTA-STS a elevam a requisito.**

Perguntas frequentes

"DANE não configurado" por si só não é perigoso — a grande maioria dos servidores de e-mail ainda opera sem ele. Ainda assim, habilitá-lo vale a pena como defesa contra ataques man-in-the-middle ao STARTTLS, se essa opção estiver disponível.

Ambos visam forçar a criptografia TLS no transporte de e-mail, mas baseiam sua confiança de forma diferente: o MTA-STS depende da cadeia de validação de uma autoridade certificadora, enquanto o DANE depende da cadeia de assinaturas do DNSSEC. Se o DNSSEC já está habilitado, o DANE é uma escolha natural; caso contrário, o MTA-STS é o ponto de partida mais prático. Os dois também podem ser usados juntos.

Usage especifica o modelo de validação (se ainda é necessária a validação por CA ou se o certificado em si é fixado diretamente), Selector especifica se o hash é aplicado ao certificado completo ou apenas à chave pública, e Matching Type especifica o algoritmo de hash (como SHA-256 ou SHA-512). Combinações diferentes atendem a padrões operacionais diferentes.

Para proteção completa, todo host MX que possa ser escolhido como destino de entrega deveria ter um registro TLSA. Se apenas alguns hosts tiverem um, o e-mail entregue a um host sem registro não fica protegido.

Esta ferramenta verifica apenas um estado superficial: se um registro TLSA foi publicado. Ela não verifica se os dados de associação do certificado realmente correspondem ao certificado real do servidor, portanto use também uma ferramenta especializada se precisar de uma verificação rigorosa.

Curiosidade — Proteger a criptografia de e-mail com certificados, não apenas "evitar espionagem"

A criptografia de e-mail via SMTP (STARTTLS) tem uma fraqueza de longa data. A maioria dos servidores de e-mail usa TLS oportunista — voltando ao texto simples caso o outro lado não suporte criptografia —, o que abriu espaço para os "ataques STRIPTLS", nos quais um atacante man-in-the-middle remove silenciosamente o comando STARTTLS, fazendo a conexão ser rebaixada para texto simples sem que nenhum dos lados perceba.

O DANE (DNS-based Authentication of Named Entities, RFC 6698) responde a isso publicando registros TLSA no DNS. Ao fixar previamente no DNS o certificado de um servidor de e-mail (ou o hash de sua chave pública), o servidor remetente pode verificar se o host ao qual está se conectando realmente apresenta o certificado esperado. Diferentemente da validação comum de certificados SSL/TLS, o DANE não depende em nada da cadeia de confiança de uma autoridade certificadora — ele confia apenas na cadeia de assinaturas do DNSSEC.

A fraqueza do DANE é que ele só funciona se o próprio domínio estiver assinado com DNSSEC. Sem o DNSSEC, nada impede que o registro TLSA seja adulterado em trânsito, o que torna a garantia do DANE sem sentido. Por isso, a adoção do DANE acompanha de perto a do DNSSEC, tendo avançado mais cedo em alguns registros europeus (como .nl e .cz).

Ver todas as curiosidades