Teste de Saúde do Domínio

O que “saúde do domínio” cobre de verdade

Saúde de domínio não é uma coisa só. São três camadas empilhadas, e um problema em qualquer uma delas aparece como um sintoma diferente. A camada de baixo é a resolução: o mundo consegue transformar seu nome em endereço? A do meio é a autenticação de email: quando seu domínio envia uma mensagem, o servidor que recebe consegue provar que foi você mesmo? A de cima é a segurança de transporte: o certificado TLS está certo pra o navegador não reclamar?

A maioria dos casos de “o site está no ar mas o email vai pro spam” mora na camada do meio — e é justamente onde ninguém olha, porque o site carrega normal. O teste existe pra mostrar as três de uma vez, pra você não ficar depurando um registro enquanto o culpado é outro.

DNS: o nome resolve, e pra onde

O scan puxa os registros A (os endereços IPv4 pra onde o domínio aponta) e os NS (os servidores de nome que respondem pela zona). Sem registro A, o domínio simplesmente não resolve — nada mais importa até isso ser resolvido. Um único nameserver é ponto único de falha: se ele cai, o domínio inteiro some. Por isso a prática do RFC 1034 e os próprios registradores esperam pelo menos dois, em infraestrutura separada.

Todo registro de DNS carrega um TTL — quantos segundos os resolvers podem guardar aquilo em cache. Um TTL alto (86400, um dia inteiro) faz uma mudança que você fez hoje só aparecer em todo lugar amanhã. Esse atraso é a “propagação”, e é por isso que um registro pode estar certo no painel do registrador e ainda assim resolver pro valor antigo por horas.

Autenticação de email: SPF, DKIM, DMARC

Esses três registros são o que o servidor que recebe usa pra decidir se o seu email é legítimo. O SPF é um registro TXT que lista quais servidores podem enviar pelo seu domínio. Ele tem um limite que derruba muita gente: no máximo 10 consultas de DNS durante a avaliação (RFC 7208 §4.6.4). Encadeie include: demais — efeito colateral comum de ir somando cada fornecedor de SaaS — e o SPF devolve permerror, que muito servidor trata como falha.

O DKIM assina cada mensagem com uma chave privada; quem recebe busca a chave pública correspondente no seu DNS e confere a assinatura, provando que o corpo não foi alterado no caminho. O DMARC amarra SPF e DKIM e diz ao receptor o que fazer quando a mensagem falha nos dois: p=none é “não faça nada, só me reporte”, p=quarantine é “manda pro spam”, p=reject é “devolve”. Um domínio parado em p=none publica uma política que não protege ninguém — é só monitoramento.

Desde fevereiro de 2024, Google e Yahoo exigem de quem envia em volume (grosso modo, 5.000+ mensagens por dia pros usuários deles) ter SPF, DKIM e um registro DMARC, senão o email é limitado ou rejeitado. Essa mudança sozinha transformou autenticação de “seria bom ter” em requisito duro — e é o motivo de um domínio que enviava bem ano passado ver a entrega despencar do nada.

TLS: o certificado e o relógio dele

O scan conecta na porta 443 e lê o certificado como um navegador leria: é válido pra esse hostname, quem emitiu e quantos dias faltam pra vencer. Certificado vencido é a falha mais barulhenta da lista — o navegador troca sua página por um aviso de tela cheia, e servidores de email negociando STARTTLS podem recusar a conexão.

A armadilha clássica é a automação que para calada. Certificado do Let’s Encrypt dura 90 dias e deveria renovar sozinho; quando o cron de renovação morre, ninguém percebe até os 90 dias acabarem. Por isso o teste mostra os dias exatos que faltam, e não só válido/inválido — um certificado com 6 dias de vida é tecnicamente válido e prestes a virar uma queda.