Pesquisa de registo MX

Host

Tipo

Resolvedor

Rastreamento iterativo

No modo de rastreamento iterativo, o resolvedor é ignorado.

Teste de propagação

Consulta vários resolvedores públicos para comparar as respostas.

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. Raiz
Descoberta dos servidores do TLD para o nome solicitado.
2. TLD
Referência aos NS da zona (delegação).
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. Resolvedor escolhido
Use o preset ou a configuração personalizada para lançar a consulta exatamente como o seu serviço faria.
2. Protocolo preservado
Respeita o transporte selecionado (UDP, TCP ou DoH) para reproduzir o comportamento real.
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. Resolvedores multiponto
Ative os presets de propagação para consultar vários atores distribuídos pelo mundo.
2. Comparação automática
Agrupa respostas idênticas e assinala divergências ou erros específicos de cada resolvedor.
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.

Informação adicional sobre registos DNS tipo MX

Um registo MX aponta que servidores recebem emails para um domínio. O destino é um hostname; o resolvedor segue-o para obter registos A ou AAAA e, assim, a morada IP do servidor de correio.
Inclui nome, tipo, prioridade, destino e TTL. O TTL controla o tempo em cache no resolvedor local.

Exemplo de registo MX

Nome	Tipo	Prioridade	Destino	TTL (s)
@	MX	10	mail.exemplo.net.	3600

O símbolo @ representa o ápice. O destino deve publicar A ou AAAA. Prioridade mais baixa é preferida. TTL 3600 equivale a uma hora.

Prioridades múltiplas

É comum declarar vários MX. O servidor remetente tenta primeiro a prioridade mais baixa; se falhar, tenta a seguinte.

Nome	Tipo	Prioridade	Destino	TTL (s)
@	MX	10	mx1.exemplo.net.	3600
@	MX	20	mx2.exemplo.net.	3600

Esta redundância ajuda a continuidade, mas não substitui monitorização ativa.

Regras essenciais

MX deve apontar para um nome (não IP). O destino não pode ser CNAME e tem de publicar A/AAAA alcançáveis na porta 25. MX pode existir no ápice ou num subdomínio se o endereço de email usar esse subdomínio.

TTL explicado

TTL curto torna mudanças visíveis rapidamente — útil ao migrar de fornecedor.
TTL médio/longo reduz consultas — adequado quando a configuração é estável.
Reduza o TTL antes do corte, aumente depois da validação.

Nota
MX gere receção. O envio depende de SPF, DKIM, DMARC e da configuração do relé de saída.

Onde usar MX

Publicar o MX no domínio que recebe correio (normalmente o ápice). Para um domínio dedicado, ex.: support.exemplo.com, publique o MX nesse subdomínio. Os hosts referenciados devem manter A/AAAA próprios.

Evite
Apontar MX para CNAME ou diretamente para IP.
Esquecer o registo A/AAAA correspondente.
Deixar MX antigos ativos após migração.

Verificar online

Lookup DNS mostra as prioridades, destinos e TTL observados. Depois teste localmente.

Windows

nslookup
set q=mx
exemplo.com

nslookup
set q=mx
server 1.1.1.1
exemplo.com

Linux/macOS

dig mx exemplo.com

dig mx exemplo.com @1.1.1.1

Leitura rápida

Várias linhas = vários servidores. Prioridade mais baixa é preferida; iguais partilham tentativas. TTL alto explica atrasos. Destino sem A/AAAA impede entrega.

Procedimento simples de migração

Preparar hosts de email com A/AAAA.
Reduzir TTL para 300 ou 60 segundos horas antes.
Adicionar novos MX com prioridades pretendidas mantendo os antigos durante transição.
Testar receção a partir de várias redes e verificar cabeçalhos.
Remover MX antigos e restaurar TTL confortável após estabilizar.

Dica prática
Registe lista completa de MX, prioridades, TTL e motivo antes da alteração para facilitar rollback.

Casos frequentes

Serviço externo

Publicar os MX fornecidos pelo parceiro; destinos pertencem ao domínio do fornecedor.

Filtragem antispam

Apontar MX para o serviço de filtragem que depois reenviará para os servidores internos. Monitorize latência e disponibilidade.

MX de redundância

Adicionar servidor secundário com prioridade maior para reter mensagens se o primário falhar.

Resolução rápida

Com bounce, verifique se o destino resolve em A/AAAA.
Teste conectividade na porta 25 para o destino.
Após migração, remova MX que ainda apontam para o fornecedor anterior.
Se o valor antigo persistir, aguarde TTL e limpe caches onde possível.

Em resumo, um registo MX indica o(s) servidor(es) de receção. Apoia-se em hostnames com A/AAAA válidos e prioridades controlam a ordem de tentativa. Ajustar o TTL facilita mudanças. Verifique com ferramentas online, nslookup e dig para garantir uma entrega fiável.