Ir para o conteudo principal

Pesquisa registo MX

Identifique os servidores de email do seu domínio

Os seus emails não estão a ser entregues? Verifique se os seus registos MX apontam para os servidores de email corretos. Compare as respostas de múltiplos resolvedores para detetar problemas de configuração.

No modo de rastreamento iterativo, o resolvedor é ignorado.
Consulta vários resolvedores públicos para comparar as respostas.

Servidores e prioridades

Mostre todos os servidores MX com as suas prioridades. O servidor com a prioridade mais baixa recebe o correio primeiro.

Validação de destinos

Verifique que cada servidor MX resolva para um registo A ou AAAA válido. Um MX sem IP impede a entrega.

Comparação multi-resolvedor

Compare as respostas do Google, Cloudflare, Quad9 para detetar inconsistências de propagação.

Diagnóstico completo

Identifique registos MX órfãos, prioridades mal configuradas ou servidores inalcançáveis.

Gratuito e sem registo

Teste quantos domínios precisar. Nenhuma conta necessária.

Como utilizar corretamente as diferentes opções do motor de pesquisa DNS?

O que é a traçado iterativa?

A traçado executa a resolução passo a passo. O resolvedor consulta primeiro os servidores raiz, depois os do TLD (.com, .br, .pt) e, por fim, os servidores autoritativos da zona pretendida. Em cada etapa, a página mostra o servidor consultado, a resposta, o RCODE e a latência.

  1. 1. Raiz

    Descoberta dos servidores do TLD para o nome solicitado.

  2. 2. TLD

    Referência aos NS da zona (delegação).

  3. 3. Autoritativos

    Resposta final (ou erro) com TTL e latência.

Para que serve?

  • Comparar respostas entre resolvedores e regiões
  • Detetar um cache quente, um TTL demasiado longo ou uma delegação incompleta
  • Explicar diferenças de latência ou um RCODE inesperado

Dica: deixe a traçado desativada para verificações rápidas; ative-a durante investigações ou para preparar um ticket/post-mortem.

O que é a traçado clássica?

A traçado clássica consulta apenas o resolvedor selecionado (UDP ou DoH) e mostra a resposta tal como é percecionada a partir desse ponto da rede. Obtém o RCODE, as secções da resposta e a latência do percurso cliente → resolvedor.

  1. 1. Resolvedor escolhido

    Use o preset ou a configuração personalizada para lançar a consulta exatamente como o seu serviço faria.

  2. 2. Protocolo preservado

    Respeita o transporte selecionado (UDP, TCP ou DoH) para reproduzir o comportamento real.

  3. 3. Resposta detalhada

    Mostra as secções question, answer e authority/additional quando existirem, com TTL e metadados úteis.

Porque utilizá-la?

  • Verificar a visão de um resolvedor específico antes de suspeitar de delegação
  • Confirmar valores em cache e o impacto de um TTL ou de um flush
  • Documentar uma resolução tal como a vê um cliente ou microserviço

Dica: mantenha a traçado iterativa desativada quando auditar um resolvedor específico; ative-a depois para comparar com o percurso raiz → TLD → autoritativo.

Como funciona o teste de propagação?

O teste consulta em paralelo um conjunto de resolvedores públicos (Google, Cloudflare, Quad9, OpenDNS, ISP…) e agrupa as respostas por conteúdo e RCODE. Vê imediatamente quem já aplicou a atualização.

  1. 1. Resolvedores multiponto

    Ative os presets de propagação para consultar vários atores distribuídos pelo mundo.

  2. 2. Comparação automática

    Agrupa respostas idênticas e assinala divergências ou erros específicos de cada resolvedor.

  3. 3. Resumo acionável

    Apresenta um resumo claro, a lista de resolvedores, latências e estado de cada grupo.

Quando usar?

  • Acompanhar a difusão de uma alteração DNS à escala global
  • Identificar caches ainda antigos e decidir um flush direcionado
  • Partilhar um estado de propagação num ticket ou post-mortem

Dica: durante o teste de propagação, a seleção de resolvedor fica bloqueada. Desative o modo para voltar ao diagnóstico unitário.

O que é um registo MX?

Um registo MX (Mail Exchange) indica quais servidores recebem os emails de um domínio. Quando alguém envia um email para user@captaindns.com, o servidor remetente consulta o MX de captaindns.com para saber onde entregar a mensagem.

Estrutura de um registo MX:

CampoDescriçãoExemplo
NomeO domínio (@ para o apex)@
TipoSempre MXMX
PrioridadeOrdem de preferência (menor = primeiro)10
DestinoNome do servidor de emailmail.captaindns.com.
TTLDuração da cache em segundos3600

Exemplo concreto:

captaindns.com.  3600  IN  MX  10 mail.captaindns.com.
captaindns.com.  3600  IN  MX  20 backup.captaindns.com.

O servidor com prioridade 10 recebe o correio primeiro. Se não estiver disponível, o servidor com prioridade 20 assume.


Configuração para fornecedores comuns

Google Workspace

@  MX  1   ASPMX.L.GOOGLE.COM.
@  MX  5   ALT1.ASPMX.L.GOOGLE.COM.
@  MX  5   ALT2.ASPMX.L.GOOGLE.COM.
@  MX  10  ALT3.ASPMX.L.GOOGLE.COM.
@  MX  10  ALT4.ASPMX.L.GOOGLE.COM.

Microsoft 365

@  MX  0  captaindns-com.mail.protection.outlook.com.

O nome exato depende do seu tenant Microsoft.

Servidor dedicado

@  MX  10  mail.captaindns.com.

Certifique-se de que mail.captaindns.com tem um registo A válido.


Boas práticas

Redundância

  • Configure pelo menos 2 servidores MX com prioridades diferentes
  • O servidor de backup deve poder armazenar emails temporariamente (store-and-forward)
  • Teste regularmente a mudança parando o servidor principal

Configuração correta

RegraExplicação
MX → hostnameUm MX aponta para um nome, nunca para um IP
Hostname → A/AAAAO destino do MX deve ter um registo A ou AAAA
Sem CNAMEO destino não deve ser um CNAME
Reverse DNSO IP do servidor de email deve ter um PTR correspondente

Evitar

  • MX para IP: MX 10 203.0.113.25 (inválido)
  • MX para CNAME: MX deve apontar para um A/AAAA direto
  • Prioridades idênticas sem intenção: Pode causar distribuição não pretendida
  • MX órfão: Um MX cujo destino não resolve para nenhum IP

Diagnóstico de problemas comuns

Emails não entregues (bounce)

  1. Verifique que o MX existe e aponta para um nome válido
  2. Confirme que o destino do MX tem um registo A/AAAA
  3. Teste a acessibilidade do servidor na porta 25
  4. Verifique o reverse DNS (PTR) do IP do servidor

Emails entregues ao servidor errado

  1. Verifique as prioridades: a mais baixa é contactada primeiro
  2. Remova os MX antigos após uma migração
  3. Aguarde a expiração do TTL após alterações

Atraso na entrega

  1. Verifique que o servidor principal (prioridade baixa) está acessível
  2. Se o backup recebe os emails, o principal tem um problema
  3. Consulte os logs SMTP para identificar retentativas

Verificar por linha de comandos

Windows (nslookup)

nslookup
set q=mx
captaindns.com

Linux/Mac (dig)

dig MX captaindns.com

Resultado típico:

captaindns.com.  3600  IN  MX  10 mail.captaindns.com.
captaindns.com.  3600  IN  MX  20 backup.captaindns.com.

Verificar que o destino resolve:

dig A mail.captaindns.com

Ferramentas complementares

FerramentaUtilidade
Testador de emailTestar entregabilidade e autenticação
Inspetor SPFVerificar registo SPF
Inspetor DKIMValidar assinatura DKIM
Pesquisa AVerificar que o destino MX resolve
Pesquisa PTRVerificar o reverse DNS do servidor

Recursos úteis