Consulta MX — Verificar Registros MX de Domínio

Faça a consulta MX de qualquer domínio: os servidores de e-mail na ordem de entrega, quem os opera, os endereços IPv4 e IPv6 deles e se respondem com STARTTLS. Direto dos próprios servidores de nomes do domínio, ao lado das cópias em cache do Google e da Cloudflare.

Fontes: os servidores de nomes do domínio, alcançados a partir de um servidor raiz · Google Public DNS · Cloudflare 1.1.1.1 · Team Cymru · servidores de e-mail testados a partir do nosso servidor em Mumbai

O que é um registro MX?

Um registro MX (mail exchange, ou troca de e-mail) nomeia os servidores que recebem os e-mails de um domínio, cada um com um número de prioridade: os remetentes tentam primeiro o número mais baixo.

Quando alguém escreve para name@airbnb.com, o servidor de e-mail dessa pessoa pergunta ao DNS os registros MX de airbnb.com, escolhe o servidor com o número mais baixo e entrega por SMTP na porta 25. O registro contém um nome de host, nunca um endereço IP, e esse nome precisa ter o próprio registro A ou AAAA: ele não pode ser um apelido (um CNAME, RFC 2181 §10.3).

Uma consulta MX lê esses registros e segue cada servidor até os endereços, a rede e o provedor por trás dele. O MX só direciona os e-mails recebidos: quem pode enviar pelo domínio é assunto do SPF, do DKIM e do DMARC.

Anatomia de um registro MXairbnb.com, do próprio servidor de nomes
airbnb.com.Nome300TTLINClasseMXTipo1Prioridadeaspmx.l.google.com.Servidor de e-mail (exchange)
Nome · TTLO domínio que recebe os e-mails, e por quanto tempo os caches podem guardar esta resposta: 300 s = 5 min.
PrioridadeO menor é tentado primeiro. airbnb.com tem 1, 5, 5, 10, 10.
Servidor de e-mailUm nome de host com os próprios registros A e AAAA: 192.178.211.27 e 2404:6800:4000:1025::1b.
1 aspmx.l.google.com.Um nome de host com registros A e AAAA
1 192.0.2.25Um endereço IP não é um exchange válido
1 mail → CNAMEO exchange não pode ser um apelido (RFC 2181 §10.3)
Cada campo como vem do próprio servidor de nomes de airbnb.com. A ferramenta sinaliza um MX que aponta para um endereço IP, um CNAME ou um nome sem endereço.

Como consultar os registros MX

Digite o domínio acima e clique em Consultar MX, ou pergunte ao DNS pelo terminal: dig example.com MX no macOS e no Linux, nslookup -type=mx example.com em qualquer sistema, ou Resolve-DnsName example.com -Type MX no PowerShell do Windows.

Cada linha da resposta é um servidor: a prioridade, depois o nome do host. O número antes de IN é o TTL, os segundos durante os quais um resolvedor pode continuar entregando esta cópia. Acrescente @ e um servidor de nomes (dig @dns1.p08.nsone.net airbnb.com MX) para ler a resposta da própria zona em vez de um cache.

dig example.com MX +short

Cada linha: a prioridade, depois o servidor de e-mail. Acrescente @ e um servidor de nomes para pular os caches.

Como ler a resposta do digobtida em 2026-10-23
bash · zsh
$ dig airbnb.com MX
;; ->>HEADER<<- opcode: QUERY, status: NOERROR1
;; flags: qr rd ra; QUERY: 1, ANSWER: 5

;; ANSWER SECTION:
airbnb.com.    3002  IN  MX   13 aspmx.l.google.com.4
airbnb.com.    300   IN  MX   5 alt1.aspmx.l.google.com.
airbnb.com.    300   IN  MX   5 alt2.aspmx.l.google.com.
airbnb.com.    300   IN  MX  10 alt3.aspmx.l.google.com.
airbnb.com.    300   IN  MX  10 alt4.aspmx.l.google.com.

;; SERVER: 8.8.8.8#53(8.8.8.8)5
  1. Status. NOERROR com respostas. NXDOMAIN significa que o nome não existe; NOERROR sem resposta significa que não há MX.
  2. TTL. Os segundos durante os quais esta cópia ainda pode ser entregue: 300 na origem, em contagem regressiva nos caches.
  3. Prioridade. A ordem em que os remetentes tentam, a mais baixa primeiro.
  4. Servidor de e-mail. O host ao qual se conectar na porta 25; o ponto final encerra o nome.
  5. Quem respondeu. 8.8.8.8 é um cache. @dns1.p08.nsone.net pergunta à própria zona.
As mesmas cinco linhas aparecem na visualização Servidores da ferramenta, ordenadas e agrupadas por prioridade, com os endereços de cada servidor ao lado.

Como ler o resultado

O topo diz numa frase quem recebe os e-mails do domínio e quantos servidores estão por trás, com a marca do provedor; as linhas coloridas abaixo são as constatações que importam.

A visualização Servidores lista cada host MX por prioridade com os endereços, a rede e o DNS reverso; o primeiro servidor é testado na porta 25 automaticamente e os outros sob demanda. À direita, o caminho de entrega desenha o que um remetente faz com essas respostas.

Consulta MX: cinco registros MX no Google Workspace, os endereços e o teste STARTTLS de cada servidor e o caminho de entregaConsulta MX: cinco registros MX no Google Workspace, os endereços e o teste STARTTLS de cada servidor e o caminho de entregaO vereditoQuem recebe os e-mails, os servidores e os níveis, a rede, o TTL e qual servidor de nomes respondeu.Os servidoresCada host MX por prioridade com os endereços IPv4 e IPv6, o número AS e o PTR com confirmação direta.O teste SMTPSTARTTLS e a versão do TLS a partir do nosso servidor na porta 25; abra uma linha para ver a conversa completa.O caminho de entregaO remetente, as proteções no primeiro salto, cada nível de prioridade e, por fim, as caixas de e-mail e as evidências.
Uma consulta MX de airbnb.com: o veredito, os servidores em ordem de prioridade com os endereços e o teste STARTTLS, e o caminho que os e-mails percorrem. Selecione um número para ver o que cada parte mostra.

O que significa a prioridade do MX?

A prioridade (a RFC 5321 a chama de preferência) define a ordem: um remetente tenta primeiro o número mais baixo e só passa ao seguinte quando esse servidor não responde ou adia a mensagem com uma resposta temporária 4xx.

Servidores com o mesmo número dividem a carga: o remetente escolhe um ao acaso. Só a ordem conta, não os intervalos, e 0 é um número válido. Um registro MX basta quando o nome por trás dele se distribui por muitos servidores, como os do Microsoft 365 e da Mimecast.

Nossa recomendação sobre MX de reserva: um servidor de reserva em outra empresa que filtra menos que o seu principal é uma rota de spam conhecida, e os provedores hospedados já mantêm servidores redundantes por trás de um único nome MX. Se você mantiver um, ele precisa aplicar as mesmas verificações de SPF e de spam que o principal (RFC 7208, Apêndice F).

Como um remetente percorre os cinco servidores de airbnb.comprioridades 1 · 5 · 10
Tentativa 1prioridade 1
aspmx.l.google.comtentado primeiro, sempre
250 OK

só se ele não responder ou responder 4xx

Tentativa 2prioridade 5
alt1.aspmx.l.google.comescolhido ao acaso · ½alt2.aspmx.l.google.comou este · ½
números iguais dividem a carga

depois

Tentativa 3prioridade 10
alt3.aspmx.l.google.com½alt4.aspmx.l.google.com½
todos falham: fila, novas tentativas por dias
0 é válidogithub.com publica a prioridade 0 no seu único MX.
1, 5, 10 ≡ 10, 20, 30Só a ordem conta, não os intervalos.
Um MX pode bastarO único host MX de hp.com representa 6 endereços.
Os remetentes só descem na lista quando um servidor não responde ou responde com um erro temporário; quando todos os servidores falham, a mensagem espera na fila e é reenviada por 4 a 5 dias (RFC 5321).

Registros MX do Google Workspace

Domínios novos do Google Workspace precisam de um único registro MX: smtp.google.com com prioridade 1. Domínios configurados antes de 2023 muitas vezes ainda publicam o conjunto de cinco registros que começa por aspmx.l.google.com; o Google diz que os dois funcionam e que uma configuração que funciona não precisa de mudança.

A ferramenta identifica o Google Workspace em qualquer um dos conjuntos e marca o mais antigo como legado, nunca como erro. Combine o MX com o SPF include:_spf.google.com e com o DKIM do Admin Console; o Google prevê até 72 horas para que novos registros MX sejam vistos em todo lugar.

As duas configurações do Google Workspace, lado a ladoMX ativo, 2026-10-23
Atualum registrorecomendada
1 smtp.google.com.
Visto em google.comsendgrid.com
Legadocinco registrosainda válido
1 aspmx.l.google.com.5 alt1.aspmx.l.google.com.5 alt2.aspmx.l.google.com.10 alt3.aspmx.l.google.com.10 alt4.aspmx.l.google.com.
Visto em airbnb.comnytimes.comuber.comspotify.com
a própria política MTA-STS de google.com aceita os dois:smtp.google.comaspmx.l.google.com*.aspmx.l.google.com
spotify.com ainda lista os hosts mais antigos aspmx2–aspmx5.googlemail.com na prioridade 10, sete registros ao todo: nomes legados a mais não fazem mal.

Registros MX do Microsoft 365

O Microsoft 365 dá a cada domínio um registro MX sob mail.protection.outlook.com, como microsoft-com.mail.protection.outlook.com, geralmente com prioridade 0. A primeira parte é um token que você copia do centro de administração do Microsoft 365: muitas vezes parece o domínio com hífens, mas nem sempre.

Os domínios que ativam o SMTP DANE de entrada recebem um host sob mx.microsoft, como siemens-com.h-v1.mx.microsoft: essa zona é assinada com DNSSEC, então os remetentes podem verificar o certificado do servidor com DANE. Durante a mudança, os dois registros ficam ativos, o novo primeiro atrás do antigo, depois na frente dele, até que o antigo seja removido. A Microsoft não tem planos de assinar mail.protection.outlook.com, então o host legado não está obsoleto.

Como ler um host MX do Microsoft 365microsoft.com · siemens.com
Exchange Onlinea forma comum
microsoft-comtoken do centro de administração.mail.protection.outlook.comExchange Online Protection
Visto em microsoft.comgithub.comunilever.com
Com DANEzona assinada com DNSSECDANE
siemens-comtoken do centro de administração.h-v1um shard.mx.microsoftzona assinada
Visto em siemens.comshell.com
Durante a mudança para o novo hostos dois registros ativos; o número mais baixo vence
0contoso-com.o-v1.mx.microsoft.novo · tentado primeiro
30contoso-com.mail.protection.outlook.com.antigo · até ser removido
Um host legado e um host mx.microsoft com prioridades diferentes é uma migração em andamento, seguindo as etapas documentadas pela Microsoft, não um erro: a ferramenta diz isso em vez de emitir um alerta.

Sem registro MX ou null MX: o que acontece?

Um domínio sem registros MX ainda pode receber e-mail: os remetentes recorrem ao próprio endereço A ou AAAA do domínio (RFC 5321 §5.1). Só um null MX (MX nulo), o registro único 0 ., avisa a todos os remetentes que o domínio não aceita e-mail (RFC 7505).

Isso faz do null MX o registro certo para um domínio que nunca recebe e-mail: os remetentes devolvem a mensagem na hora, com 556 5.1.10, em vez de tentar de novo por dias. Acrescente v=spf1 -all e DMARC p=reject para que ninguém possa enviar se passando por ele também, como faz example.com. Os registros MX pertencem a um único nome: www.example.com não herda os de example.com.

Quatro respostas, quatro desfechoso que um remetente faz com cada uma
Registros MXairbnb.comEntrega aos servidores em ordem de prioridade.entregue250 OK
Sem MX, com A/AAAAwww.google.comEntrega no próprio endereço do nome: os registros A e AAAA dele. Se a porta 25 não responder ali, os e-mails esperam e depois voltam.MX implícitoRFC 5321 §5.1
Null MX: 0 .example.comNem tenta. O remetente devolve a mensagem na hora.recusado556 5.1.10
O nome não existeairbnb.cmoDevolve: a raiz não tem .cmo, então nada abaixo dele existe.devolvido5.1.2

Um domínio que não envia nem recebe e-mail:MX 0 .v=spf1 -all_dmarc p=reject

Cada linha é o próprio veredito da ferramenta para aquele exemplo: abra-o pelos exemplos acima da ferramenta.

E-mail não chega? Onde o MX entra na solução de problemas

Leia primeiro a mensagem de devolução: o código de status diz qual etapa falhou. Problemas de MX aparecem como "host not found" ou longos atrasos; uma caixa de e-mail inexistente é 5.1.1; falhas de autenticação são rejeições 5.7.x.

Siga a lista de cima para baixo: o domínio precisa existir, o MX dele precisa nomear o provedor que você usa, cada host MX precisa resolver e responder na porta 25, e só então o SPF, o DKIM, o DMARC e as blacklists decidem onde a mensagem cai.

Da devolução à correçãocódigos de status estendidos, RFC 3463
Host ou domínio não encontrado5.1.2 · NXDOMAINO domínio ou o host MX dele não existe. Confira a grafia e os servidores de nomes.Consulta DNS
Os e-mails ainda vão para o provedor antigodepois de uma mudança de MXOs caches guardam o MX antigo até o TTL dele acabar. Compare a zona com as cópias do Google e da Cloudflare.Visualização Cópias
Atrasado, depois devolvido4.4.1 · sem resposta do hostO host MX está fora do ar, não tem endereço ou a porta 25 está bloqueada. Teste os servidores a partir do nosso lado.Testar servidores
Usuário desconhecido5.1.1O MX funciona; a caixa de e-mail não existe no provedor.Verificador de e-mail
Rejeitado: não autenticado5.7.1O servidor de destino recusou o remetente. Corrija SPF, DKIM e DMARC no domínio que envia.Verificador de SPF
Bloqueado pelo endereço, ou cai no spamlistadoO IP do servidor que envia está numa blacklist.Verificar blacklist
As duas etapas em destaque são visualizações desta ferramenta; as outras abrem a ferramenta correspondente.

MTA-STS, DANE e TLS para servidores de e-mail

Os servidores de e-mail só criptografam com STARTTLS quando os dois lados oferecem, então alguém no caminho pode remover a oferta e ler a mensagem. O MTA-STS e o DANE permitem que um domínio exija TLS dos remetentes.

O MTA-STS publica uma política por HTTPS (https://mta-sts.<domain>/.well-known/mta-sts.txt) que lista os hosts MX permitidos e um modo; com enforce, os remetentes só entregam por TLS válido a esses hosts (RFC 8461). O DANE coloca a chave do servidor num registro TLSA em _25._tcp.<mx host>, que só vale onde o DNSSEC assina essa zona (RFC 7672). O TLS-RPT pede aos remetentes que relatem as falhas (RFC 8460). A ferramenta verifica se cada MX ativo corresponde a uma linha mx: da política.

Três travas em um saltoum remetente → proton.me, ao vivo
remetentequalquer servidor de e-mail
STARTTLS · oferecido, TLS 1.3Sozinho, o STARTTLS pode ser removido no caminho: o 250-STARTTLS simplesmente some da resposta.
MTA-STS · modo enforcemx: mail.protonmail.ch · mx: mailsec.protonmail.ch · max_age: 604800 ✓ os dois hosts MX ativos correspondem
DANE · TLSA 3 1 1_25._tcp.mail.protonmail.ch, assinado por DNSSEC (protonmail.ch) ✓
mail.protonmail.chprioridade 10
O TLS-RPT também está ativo: v=TLSRPTv1; rua=https://reports.proton.me/reports/smtptls. A ferramenta testa o STARTTLS a partir do nosso servidor; o MTA-STS e o DANE vêm do DNS e do arquivo de política.

Hosts MX dos provedores mais usados

A maioria dos domínios aponta o MX para um entre poucas dezenas de provedores, e cada um publica nomes de host reconhecíveis. É assim que a ferramenta identifica o provedor de e-mail de um domínio, e é assim que você pode conferir uma configuração com os valores do próprio provedor.

Gateways como Mimecast, Proofpoint e Barracuda ficam na frente do host das caixas de e-mail; a ferramenta então lê o SPF e o Autodiscover para nomear as prováveis caixas de e-mail por trás deles.

Hosts MX e includes de SPF por provedor16 dos mais de 110 provedores que a ferramenta reconhece
ProvedorMX (prioridade host)SPF
Google Workspace1smtp.google.comou 1 aspmx.l.google.com + 4 altinclude:_spf.google.com
Microsoft 3650<token>.mail.protection.outlook.comou <token>.<x>-v1.mx.microsoftinclude:spf.protection.outlook.com
Zoho Mailregião no TLD10mx.zoho.com20mx2.zoho.com · 50 mx3.zoho.cominclude:zohomail.com
Proton Mail10mail.protonmail.ch20mailsec.protonmail.chinclude:_spf.protonmail.ch
iCloud Mail10mx01.mail.icloud.com10mx02.mail.icloud.cominclude:icloud.com
Fastmail10in1-smtp.messagingengine.com20in2-smtp.messagingengine.cominclude:spf.messagingengine.com
Yandex 36010mx.yandex.netredirect=_spf.yandex.net
Titan Email10mx1.titan.email20mx2.titan.emailinclude:spf.titan.email
GoDaddy Professional Email0smtp.secureserver.net10mailstore1.secureserver.netinclude:secureserver.net
Namecheap Private Email10mx1.privateemail.com10mx2.privateemail.cominclude:spf.privateemail.com
Cloudflare Email Routingencaminhamentoroute1/2/3.mx.cloudflare.netprioridades definidas por domínioinclude:_spf.mx.cloudflare.net
Amazon SEScompartilhado com o WorkMail10inbound-smtp.<region>.amazonaws.cominclude:amazonses.com
Mimecastgateway de e-mail10<region>-smtp-inbound-1.mimecast.com10<region>-smtp-inbound-2.mimecast.cominclude:<region>._netblocks.mimecast.com
Proofpointgateway de e-mailmx0a-<id>.pphosted.com · mx0b-<id>ou mx1-us1.ppe-hosted.com (Essentials)a:dispatch-us.ppe-hosted.com (Essentials)
Barracudagateway de e-mail1<id>.ess.barracudanetworks.com10<id>.ess.barracudanetworks.cominclude:spf.ess.barracudanetworks.com
NAVER WORKSCoreia10kr1-aspmx1.worksmobile.com20kr1-aspmx2.worksmobile.cominclude:spf.worksmobile.com

Consulta MX: perguntas frequentes

Para que serve uma consulta MX?

Uma consulta de registros MX mostra quais servidores recebem os e-mails de um domínio e quem os opera. Use-a para ver o provedor de e-mail de uma empresa, confirmar uma alteração de MX depois de trocar de provedor, investigar devoluções e atrasos ou verificar um domínio antes de enviar para ele. Esta ferramenta também testa o STARTTLS de cada servidor de e-mail a partir do nosso servidor e lê o SPF, o DMARC e o MTA-STS do domínio.

Como consultar registros MX com o nslookup?

Rode nslookup -type=mx example.com. Cada linha da resposta mostra a prioridade como "MX preference" e o servidor como "mail exchanger". Acrescente um servidor no final, como em nslookup -type=mx example.com 8.8.8.8, para perguntar a um resolvedor específico, ou indique o próprio servidor de nomes do domínio para pular qualquer cache. No macOS e no Linux, dig example.com MX dá a mesma resposta.

Um domínio pode ter mais de um registro MX?

Sim. Cada registro MX nomeia um servidor de e-mail com uma prioridade. Os remetentes tentam primeiro o número mais baixo, só passam ao seguinte quando um servidor não responde ou adia a entrega e escolhem ao acaso entre servidores com o mesmo número, o que divide a carga. gmail.com publica cinco registros MX em cinco prioridades; yahoo.com publica três com a mesma prioridade.

Um registro MX pode apontar para um endereço IP ou um CNAME?

Não. O valor do MX precisa ser um nome de host com o próprio registro A ou AAAA. Um endereço IP não é um valor válido, e a RFC 2181 proíbe um host MX que seja um apelido (um CNAME). Alguns remetentes ainda seguem um CNAME ou se conectam a um IP, enquanto outros recusam, então os e-mails podem chegar de alguns remetentes e voltar de outros. A ferramenta sinaliza os dois casos.

Quanto tempo leva uma alteração de registro MX?

O tempo do TTL do registro antigo. Os resolvedores que guardaram o MX antigo em cache o usam até a cópia expirar e depois perguntam de novo aos servidores de nomes do domínio; uma resposta "sem MX" em cache expira igualmente. Reduza o TTL um dia antes de trocar de provedor. Os provedores citam margens de segurança (o Google prevê até 72 horas), e a visualização Cópias mostra quando as cópias do Google e da Cloudflare são atualizadas.

O que é um registro null MX?

Um null MX é um único registro MX com prioridade 0 e um ponto sozinho como host: 0 . (RFC 7505). Ele diz que o domínio não aceita e-mail, então os remetentes devolvem a mensagem na hora, com 556 5.1.10, em vez de tentar de novo por dias. Ele precisa ser o único registro MX. example.com publica um, com SPF -all e DMARC p=reject ao lado.

O que acontece se um domínio não tem registro MX?

Os e-mails ainda são tentados. Sem registro MX, os remetentes entregam no próprio endereço A ou AAAA do domínio, o MX implícito (RFC 5321, seção 5.1). Se nada responder na porta 25 ali, a mensagem espera na fila do remetente, é reenviada por quatro a cinco dias e depois volta. Um domínio que não deve receber e-mail deve publicar um null MX.

Ter um único registro MX é um problema?

Não. Um registro MX é uma configuração completa quando o nome por trás dele tem balanceamento de carga: o smtp.google.com do Google Workspace e os hosts mail.protection.outlook.com do Microsoft 365 respondem, cada um, a partir de muitos servidores. A RFC 5321 não exige um número mínimo de registros MX. A ferramenta mostra quantos endereços IPv4 e IPv6 estão por trás de cada host MX, para você ver a redundância.

Por que o MX mostra um provedor diferente do que eu esperava?

Um gateway pode ficar na frente das caixas de e-mail. Mimecast, Proofpoint, Barracuda e Cloudflare Email Security filtram os e-mails primeiro, então o MX nomeia o gateway, enquanto as caixas de e-mail ficam no Microsoft 365, no Google Workspace ou em outro provedor por trás dele. A ferramenta lê o include do SPF e o registro Autodiscover do domínio para nomear o provável provedor das caixas de e-mail, e mostra essa evidência.

Os registros MX são públicos?

Sim. Os registros MX são dados públicos do DNS por definição: qualquer servidor de e-mail do mundo precisa conseguir consultá-los para entregar ao seu domínio. Eles mostram quais servidores recebem os e-mails e quem os opera, não quem envia nem o que há nas caixas de e-mail. Escondê-los impediria a chegada dos seus e-mails.

Os registros MX afetam o envio de e-mails?

Não. Os registros MX só direcionam os e-mails recebidos para os seus servidores. Quais servidores podem enviar pelo seu domínio é decidido pelo SPF, pelo DKIM e pelo DMARC, que os servidores de destino verificam em cada mensagem. Você pode enviar por um provedor e receber em outro; nesse caso, os dois aparecem no SPF, enquanto só o que recebe está no MX.

Por que não consigo me conectar à porta 25 do meu computador?

A maioria das redes domésticas e móveis, e nuvens como AWS, Google Cloud e Azure, bloqueia conexões de saída para a porta 25 para conter spam, então um telnet ou openssl para um servidor de e-mail estoura o tempo limite. Isso não diz nada sobre o servidor. Esta ferramenta testa cada servidor de e-mail a partir do nosso próprio servidor em Mumbai, que consegue alcançar a porta 25, e mostra a conversa completa.

Sentiu falta de algo?Sugira um recurso ou uma nova ferramenta