Como funciona a prioridade MX?

A prioridade é um número (tipicamente 10, 20, 30...). O servidor com o valor de prioridade mais baixo recebe o correio primeiro. Se dois MX tiverem a mesma prioridade, o tráfego é distribuído entre eles.

Porque é que o meu MX aponta para um nome em vez de um IP?

Por design DNS, um MX deve apontar para um hostname, nunca diretamente para um IP. Esse hostname deve depois ter um registo A ou AAAA para resolver para um IP.

Posso usar um CNAME como destino MX?

Não, é proibido pelas RFC. Um MX deve apontar para um nome canónico (A/AAAA), não para um alias CNAME. Muitos servidores recusarão entregar se o MX for um CNAME.

Como adiciono um MX de backup?

Publique múltiplos registos MX com prioridades diferentes. Por exemplo: prioridade 10 para o servidor principal, prioridade 20 para o backup. O backup recebe emails se o principal não estiver disponível.

Os meus emails vão para o spam, está relacionado com o MX?

O MX apenas diz respeito à receção de email. Para problemas de envio e spam, verifique SPF, DKIM e DMARC. No entanto, o servidor MX deve ter reverse DNS (PTR) correto para a entregabilidade.

Quantos servidores MX devo ter?

Mínimo um, mas dois são recomendados para redundância. Os grandes fornecedores como Google Workspace ou Microsoft 365 tipicamente configuram de 2 a 5.

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.

Tipo de registocada tipo é uma página dedicada

A AAAA MX TXT CNAME NS SOA SVCB CAA HTTPS PTR

O resultado é apresentado automaticamente mais abaixo

Modo de resolução

Testar a propagação DNS

Simples = uma consulta ao resolvedor · Trace = descida a partir da raiz

opçõesOpções avançadas

Resolvedor

Protocolo

Servidores e prioridades

Mostre todos os servidores MX com as suas prioridades. O servidor com o valor de prioridade mais baixo 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 da ferramenta de consulta DNS?

O que é o traçado iterativo?

O 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 o traçado desativado para verificações rápidas; ative-o durante investigações ou para preparar um ticket/post-mortem.

O que é o traçado clássico?

O traçado clássico 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 o traçado iterativo desativado quando auditar um resolvedor específico; ative-o 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
A ferramenta consulta em paralelo vários resolvedores 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: o teste de propagação é uma ferramenta dedicada. Use-a para acompanhar uma alteração à escala global; para uma consulta unitária, utilize o DNS Lookup (Simples ou traçado iterativo).

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:

Campo	Descrição	Exemplo
Nome	O domínio (@ para o apex)	`@`
Tipo	Sempre `MX`	`MX`
Prioridade	Ordem de preferência (menor = primeiro)	`10`
Destino	Nome do servidor de email	`mail.captaindns.com.`
TTL	Duração da cache em segundos	`3600`

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

Configuração atual desde 2023, um registo único:

@  MX  1   SMTP.GOOGLE.COM.

Os domínios criados antes de 2023 publicam o conjunto histórico, que o Google continua a suportar:

@  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

Regra	Explicação
MX → hostname	Um MX aponta para um nome, nunca para um IP
Hostname → A/AAAA	O destino do MX deve ter um registo A ou AAAA
Sem CNAME	O destino não deve ser um CNAME
Reverse DNS	O 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)

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

Emails entregues ao servidor errado

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

Atraso na entrega

Verifique que o servidor principal (prioridade baixa) está acessível
Se o backup recebe os emails, o principal tem um problema
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

Ferramenta	Utilidade
Testador de email	Testar entregabilidade e autenticação
Inspetor SPF	Verificar registo SPF
Inspetor DKIM	Validar assinatura DKIM
Pesquisa A	Verificar que o destino MX resolve
Pesquisa PTR	Verificar o reverse DNS do servidor

Recursos úteis

RFC 5321 - Simple Mail Transfer Protocol (especificação SMTP)
RFC 7505 - Null MX Record (como indicar que um domínio não recebe email)
Google Workspace - Configurar MX (guia oficial)
Microsoft 365 - Configurar MX (guia oficial)