Diagnóstico Completo de Site

O que é um diagnóstico de site

Um site raramente falha de um jeito só. Ele pode carregar rápido e mesmo assim ter o e-mail do domínio caindo na caixa de spam; pode ter o e-mail impecável e estar apontado para um servidor que demora demais a responder; pode estar tudo funcionando e o domínio vencer no mês seguinte sem ninguém perceber. Um diagnóstico serve justamente para olhar essas camadas ao mesmo tempo, em vez de tratar cada uma como um assunto isolado.

Esta página reúne quatro famílias de verificação em um relatório único. A primeira é o DNS: quais endereços o domínio publica, para onde ele aponta e quais serviços dependem desses apontamentos. A segunda é o e-mail: os registros MX, que dizem quem recebe mensagens, e os três mecanismos de autenticação de remetente, SPF, DKIM e DMARC. A terceira são os dados de registro do domínio, obtidos por RDAP, o sucessor moderno do WHOIS: quem é o registro responsável pelo domínio e as informações que ele publica a respeito dele. A quarta é o tempo de resposta do servidor, medido a partir do seu próprio navegador.

Todas essas informações são públicas. O DNS existe para ser consultado por qualquer pessoa, os dados de registro são publicados pelos próprios registros de domínio e o tempo de resposta é medido com requisições iguais às que qualquer visitante faria. O valor da ferramenta não está em descobrir segredos, e sim em juntar dados espalhados, traduzi-los para uma linguagem que não exige experiência prévia com administração de servidores e apontar o que costuma dar problema. Se você quiser explorar outros utilitários no mesmo espírito, a página de ferramentas gratuitas da sysINFO reúne todos eles.

Registros DNS, em linguagem simples

O DNS é a lista telefônica da internet. Quando alguém digita o seu domínio, o navegador precisa descobrir o endereço numérico do servidor que responde por ele, e essa tradução vem do DNS. O registro A guarda um endereço IPv4; o AAAA guarda um endereço IPv6; o CNAME diz que aquele nome é apelido de outro nome, muito comum quando o site está atrás de uma rede de distribuição de conteúdo ou hospedado em uma plataforma gerenciada.

Os registros NS indicam quais servidores mandam nas respostas do domínio, ou seja, onde a configuração realmente mora. Se você comprou o domínio em um registrador mas usa o painel de DNS de outra empresa, são os NS que contam essa história. Já os registros TXT são caixas de texto livre, e é dentro deles que vivem coisas bem diferentes entre si: verificação de propriedade exigida por serviços de terceiros, política de SPF, política de DMARC e chaves DKIM.

Cada resposta de DNS carrega um TTL, o tempo em segundos que outros servidores podem guardar aquela informação em cache antes de perguntar de novo. Um TTL alto reduz consultas e deixa o domínio mais estável; um TTL baixo faz mudanças se espalharem mais rápido. Por isso quem vai migrar de servidor costuma baixar o TTL alguns dias antes e só depois trocar o apontamento. Quando o relatório mostra que um registro não existe, isso não significa erro automático: significa apenas que aquele nome específico não foi encontrado no DNS no momento da consulta.

SPF: quem pode enviar e-mail pelo seu domínio

O protocolo de e-mail nasceu sem autenticação: qualquer servidor do mundo pode escrever o seu domínio no remetente de uma mensagem. O SPF é a primeira camada criada para conter isso. Trata-se de um registro TXT publicado na raiz do domínio, começando por v=spf1, no qual você lista quais servidores estão autorizados a enviar mensagens em seu nome. Quem recebe consulta essa lista e compara com o servidor que efetivamente entregou a mensagem.

A lista é montada com mecanismos. O include importa a lista de outro provedor, como o do seu serviço de e-mail corporativo ou o da plataforma de marketing. O ip4 e o ip6 autorizam endereços específicos, úteis quando um sistema interno dispara notificações. O final do registro define o veredito para tudo que não estiver na lista: -all pede rejeição, ~all pede tratamento suspeito e ?all não pede nada, o que enfraquece bastante a proteção.

Dois erros aparecem com frequência. O primeiro é publicar mais de um registro SPF no mesmo domínio: a especificação considera isso inválido e vários receptores simplesmente ignoram os dois. O segundo é estourar o limite de dez consultas de DNS geradas pelos mecanismos, o que costuma acontecer quando a empresa vai acumulando include de serviços que já nem usa mais. Revisar o SPF de tempos em tempos, removendo o que saiu de operação, é manutenção barata e evita dor de cabeça.

DKIM: a assinatura das mensagens

Enquanto o SPF fala sobre servidores, o DKIM fala sobre a mensagem. O servidor de envio assina digitalmente partes do cabeçalho e do corpo com uma chave privada, e publica a chave pública correspondente no DNS. Quem recebe busca essa chave pública, confere a assinatura e sabe duas coisas: que a mensagem saiu mesmo de quem diz ter enviado e que ela não foi alterada no caminho. É por isso que o DKIM sobrevive a encaminhamentos que quebram o SPF.

A chave pública fica em um endereço no formato seletor._domainkey.seudominio. O seletor é um rótulo escolhido por quem configurou o serviço, e existe justamente para permitir várias chaves simultâneas: uma para o e-mail corporativo, outra para a ferramenta de newsletter, outra para o sistema que envia notas fiscais. Trocar de chave sem interromper envios também depende desse mecanismo, publicando o novo seletor antes de aposentar o antigo.

Aqui está o motivo de a ferramenta pedir o seletor em vez de descobri-lo sozinha: o DNS não permite listar os nomes existentes sob um domínio. Só é possível perguntar por um nome exato e receber a resposta. Sem o seletor, não existe caminho técnico honesto até a chave, e varrer uma lista de palpites comuns produziria um resultado enganoso, porque a ausência de resposta significaria apenas que aquele palpite estava errado. Preferimos deixar o campo em branco e dizer que a informação não está disponível a fingir uma conclusão.

DMARC: o que fazer quando a verificação falha

SPF e DKIM verificam. O DMARC decide. É um registro TXT publicado em _dmarc.seudominio que instrui o servidor receptor sobre como tratar mensagens que não passam na verificação e que também exige alinhamento: não basta o SPF passar, o domínio verificado precisa combinar com o domínio que aparece para o leitor no campo De.

A política fica no parâmetro p. Com p=none nada é feito além de coletar relatórios, o que serve como fase de observação. Com p=quarantine as mensagens suspeitas vão para a caixa de spam. Com p=reject elas são recusadas antes da entrega, que é a proteção mais forte contra alguém falsificar o seu domínio. O parâmetro rua indica o endereço que receberá os relatórios agregados, e é ele que permite enxergar quem anda enviando em nome do domínio antes de apertar a política.

O caminho recomendado é gradual: publique p=none com rua configurado, leia os relatórios por algumas semanas até reconhecer todos os remetentes legítimos, corrija SPF e DKIM dos que faltarem e só então avance para quarentena e rejeição. Pular etapas costuma derrubar envios legítimos que ninguém lembrava que existiam, como o formulário de contato do site ou o sistema de cobrança. Se o assunto interessa, a editoria de cibersegurança da sysINFO acompanha de perto fraudes que exploram exatamente domínios mal autenticados.

Como interpretar as notas

O relatório apresenta uma nota geral e notas por área. Elas são indicadores técnicos calculados a partir dos itens que esta página consegue verificar, com os pesos declarados no próprio relatório, e nada além disso. Não medem autoridade de domínio, popularidade, qualidade editorial nem chance de aparecer bem posicionado em um buscador. Um site pode tirar nota alta aqui e ter pouquíssimo tráfego, assim como um site muito visitado pode tirar nota baixa.

A leitura mais produtiva é comparativa e temporal. Rode a análise, corrija o que estiver apontado, rode de novo e observe o que mudou. O tempo de resposta, em particular, oscila entre execuções por causa de variações de rede e de carga do servidor no momento do teste, então diferenças pequenas entre duas medições próximas não indicam nada. Tendências consistentes, sim.

Vale também separar o que é gravidade do que é apenas ausência. Um SPF com dois registros publicados é um defeito concreto, que quebra a verificação. Já um DKIM não verificado porque você não informou o seletor não é defeito nenhum: é uma verificação que não foi realizada. O relatório procura deixar essa diferença explícita, e onde a informação não existir o texto padrão é: informação não disponível para esta análise.

O que medimos de velocidade, e o que não medimos

A parte de velocidade deste relatório é uma medida só, e bem específica: o tempo de resposta do servidor. O seu navegador faz três requisições ao endereço analisado e a ferramenta fica com a mediana das três, descartando assim o efeito de uma tentativa isolada que tenha caído numa oscilação de rede. É uma medição feita do lugar onde você está, com a conexão que você tem, e não de um servidor nosso ou de um datacenter em outro país.

O que esse número junta, na prática, é a ida e a volta inteira até o servidor: resolver o nome no DNS, abrir a conexão, negociar o TLS e esperar o servidor começar a responder. Quando ele está alto, o culpado pode estar em qualquer uma dessas etapas, e vale investigar em ordem: um servidor sobrecarregado, uma hospedagem geograficamente distante, um certificado com cadeia longa demais ou simplesmente uma conexão ruim de quem mediu. Como a sua própria rede entra na conta, o valor não é comparável entre pessoas diferentes: faz sentido acompanhar o seu site ao longo do tempo, sempre medindo do mesmo lugar, e não usar o número como placar contra concorrentes.

Ao lado dele existe uma segunda medida, de natureza diferente: LCP, CLS, tempo de bloqueio e FCP, apurados abrindo a página num Chrome que roda na rede da Cloudflare, dentro da conta da própria sysINFO. Esses números não estão escritos em lugar nenhum do HTML; eles só existem enquanto a página é desenhada na tela, e por isso exigem um navegador de verdade carregando o site. Os limiares de bom, aceitável e ruim são os públicos do Core Web Vitals.

Essa medição é de laboratório, e a diferença importa. Ela descreve a página numa máquina de datacenter, com rede de datacenter, sem afunilamento artificial de processador nem de banda. Não descreve o que os visitantes reais daquele site experimentam, porque isso depende do aparelho e da conexão de cada um, e só aparece em medição de campo, coletada dos próprios visitantes ao longo do tempo. As duas coisas são úteis e não se substituem.

Como abrir um navegador custa tempo de máquina, a medição tem freios: o resultado de cada endereço fica guardado por algumas horas, cada domínio pode ser medido um número limitado de vezes por dia e existe um teto diário para a ferramenta inteira. Quando algum desses limites é atingido, o relatório diz exatamente qual foi, em vez de esconder a seção ou preencher com estimativa.

O que continua de fora: não há Speed Index, não há nota do Lighthouse nem tentativa de reproduzi-la, e não há dados de campo de visitantes reais.

O que esta ferramenta não faz

Ser útil também significa dizer com clareza onde a análise termina. Esta página não abre conexão SMTP com o seu servidor de e-mail, não testa se portas estão abertas ou fechadas e não analisa o certificado TLS do site, nem sua validade, sua cadeia ou seu emissor. Ela também não descobre automaticamente o seletor DKIM, pelo motivo técnico já explicado, e não consulta listas de bloqueio para saber se o seu IP ou o seu domínio foi incluído em alguma blacklist.

Na parte de velocidade, não há Speed Index e não há dados de campo de visitantes reais: o que medimos é laboratório, feito uma vez, de uma máquina só. As checagens de acessibilidade que aparecem no relatório são estáticas, tiradas do HTML - campo sem rótulo, botão sem nome, quadro sem título, viewport que bloqueia ampliação. Elas não substituem uma auditoria de acessibilidade, porque coisas como contraste e ordem de foco dependem do CSS aplicado e do uso real, e não do documento.

Do lado de SEO, o recorte é a própria página. Verificamos título, meta description, canonical, meta robots, hierarquia de cabeçalhos, imagens sem texto alternativo, links sem nome acessível, Open Graph e dados estruturados. O que não existe aqui, e não vai existir, é métrica de reputação: não há levantamento de backlinks, não há autoridade de domínio, não há volume de busca de palavra-chave e não há verificação de posição no Google para termo nenhum. Esses números ou dependem de bases proprietárias que não temos, ou são estimativas apresentadas como fato.

Por fim, não existe histórico nem vigilância contínua. Cada análise é um retrato de um instante, feito no momento em que você clica no botão. Não guardamos execuções anteriores, não comparamos com medições passadas, não há monitoramento agendado e não enviamos alerta quando algo muda ou quando o site sai do ar. Se você precisa de acompanhamento permanente de disponibilidade, o caminho é um serviço dedicado a isso, não esta página.

Privacidade desta análise

A sysINFO não armazena o domínio consultado. Não há banco de dados de análises, não há histórico associado a você e o resultado desaparece assim que a aba é fechada. As verificações são montadas e interpretadas pelo código que roda no seu navegador, e não por um servidor nosso intermediando o pedido.

Isso não torna a análise privada em sentido absoluto, e seria desonesto sugerir o contrário. Para que as consultas sejam respondidas, elas precisam sair do seu navegador. As perguntas de DNS vão para o Google Public DNS, por DNS sobre HTTPS, e o Google recebe o domínio consultado. Os dados de registro são buscados por RDAP através do rdap.org, que redireciona o pedido para o registro responsável pela terminação do domínio, como o registro.br ou a Verisign; esses serviços também recebem o domínio. E a medição de tempo de resposta faz o seu navegador contatar diretamente o site analisado, que enxerga esse acesso como enxergaria qualquer visita, com o seu endereço IP e os cabeçalhos que qualquer requisição HTTP carrega. Todos esses serviços aplicam as próprias políticas de registro, que estão fora do controle da sysINFO. O endereço IP exibido no relatório, por sua vez, vem de um recurso da própria sysINFO, sem terceiros no caminho.

O tratamento que a sysINFO dá a dados de navegação, cookies e medição de audiência está descrito na política de privacidade. Se o domínio que você pretende analisar for sensível a ponto de você não querer que ele apareça em registros de terceiros, prefira executar as consultas por conta própria, a partir de um resolvedor de DNS que você mesmo controle.