“0 .” — o domínio recusa e-mails
Definido na RFC 7505 para domínios que nunca recebem e-mail. Os remetentes falham na hora em vez de tentar de novo durante dias. Útil para domínios estacionados e domínios só de envio.
Descubra quais servidores recebem os e-mails de um domínio, em que ordem e qual provedor os opera — Google Workspace, Microsoft 365, Zoho, Proofpoint e outros. Também apontamos domínios sem registro MX ou com um Null MX, que recusa qualquer e-mail.
Servidores de e-mail de
Provedor de e-mail:
| Prioridade | Servidor de e-mail | Função | Provedor |
|---|
Registros perfeitos não evitam bounces. Enviar para endereços inválidos, descartáveis ou abandonados prejudica a sua reputação de remetente e pode colocar o seu IP em blacklists. Valide a lista antes da próxima campanha.
Um registro MX (mail exchanger) informa ao resto da internet quais servidores aceitam e-mails de um domínio. Quando alguém escreve para [email protected], o servidor de e-mail dessa pessoa consulta os registros MX de exemplo.com.br e entrega a mensagem a um dos hosts listados ali.
Cada registro MX tem duas partes: uma prioridade (um número) e um nome de host, por exemplo “10 mx1.exemplo.net”. O nome de host precisa ter o próprio registro A ou AAAA: um MX não pode conter um endereço IP, e as RFC 2181 e RFC 5321 proíbem apontá-lo para um alias CNAME.
Os remetentes tentam primeiro o host com o menor número. Se ele não responder, passam para o próximo. Hosts com a mesma prioridade dividem a carga, escolhidos em ordem aleatória.
Os números em si não significam nada além da ordem — 1/5/10 e 10/20/30 funcionam igual. Servidores MX de reserva, com número maior, devem aplicar as mesmas regras antispam do principal; caso contrário, os spammers passam a mirar neles de propósito.
Definido na RFC 7505 para domínios que nunca recebem e-mail. Os remetentes falham na hora em vez de tentar de novo durante dias. Útil para domínios estacionados e domínios só de envio.
Sem registro MX, a RFC 5321 manda os remetentes tentarem o endereço A/AAAA do próprio domínio. É um comportamento legado: publique registros MX de verdade — ou um Null MX — em vez de depender dele.
Não existe nenhum registro de nenhum tipo para o nome. Endereços nesses domínios não recebem e-mail e devem ser removidos das suas listas.
Os nomes dos hosts MX revelam o provedor: *.mail.protection.outlook.com é Microsoft 365, smtp.google.com e aspmx.l.google.com são Google, *.pphosted.com é Proofpoint, e assim por diante.
Como os registros MX costumam ser nos provedores mais comuns. Sempre copie os valores exatos do painel de administração do seu provedor.
| Provedor | Hosts MX típicos |
|---|---|
| Google Workspace | smtp.google.com · aspmx.l.google.com, alt1–alt4.aspmx.l.google.com |
| Microsoft 365 | yourdomain-com.mail.protection.outlook.com |
| Zoho Mail | mx.zoho.com, mx2.zoho.com, mx3.zoho.com · mx.zoho.eu … |
| Proton Mail | mail.protonmail.ch, mailsec.protonmail.ch |
| Fastmail | in1-smtp.messagingengine.com, in2-smtp.messagingengine.com |
| iCloud Mail | mx01.mail.icloud.com, mx02.mail.icloud.com |
| Hostinger | mx1.hostinger.com, mx2.hostinger.com |
| Locaweb | mx.*.locaweb.com.br |
| KingHost | *.kinghost.net |
| GoDaddy | smtp.secureserver.net, mailstore1.secureserver.net |
| IONOS | mx00.ionos.com, mx01.ionos.com · mx00.kundenserver.de |
| OVHcloud | mx1.mail.ovh.net … |
| Cloudflare Email Routing | route1.mx.cloudflare.net, route2…, route3… |
| Proofpoint | mx0a-XXXXXXXX.pphosted.com |
| Mimecast | us-smtp-inbound-1.mimecast.com, eu-smtp-inbound-1.mimecast.com … |
| Barracuda | dXXXXXXa.ess.barracudanetworks.com |
| Amazon SES (inbound) | inbound-smtp.<region>.amazonaws.com |
Sim. Você pode fazer 100 consultas por dia sem conta (compartilhadas com a consulta DNS). A ferramenta só lê registros DNS públicos e não envia nenhum e-mail.
É a ordem em que os remetentes tentam os servidores: o menor número primeiro. Números iguais dividem a carga. Um número maior geralmente indica um servidor de reserva.
Os remetentes recorrem ao endereço A ou AAAA do domínio (“MX implícito”, RFC 5321). Se nenhum servidor de e-mail estiver escutando ali, a mensagem volta. Domínios que não devem receber e-mail fazem melhor em publicar um Null MX.
Um único registro MX com prioridade 0 e host “.” (RFC 7505). Ele declara que o domínio não aceita e-mail nenhum, então os remetentes desistem na hora em vez de tentar de novo.
Não. Um MX deve apontar para um nome de host que tenha o próprio registro A ou AAAA. Alguns servidores toleram um CNAME, mas isso quebra o padrão e pode causar falhas de entrega intermitentes.
Olhe os nomes dos hosts MX — esta ferramenta faz isso por você. Por exemplo, *.mail.protection.outlook.com significa Microsoft 365, e aspmx.l.google.com ou smtp.google.com significam Google. Um gateway de segurança como Proofpoint ou Mimecast pode esconder o provedor de caixas postais por trás dele.
Não. Ele só prova que o domínio pode receber e-mails. Se uma caixa postal específica existe é outra verificação — use o validador de e-mail grátis para um endereço, ou valide uma lista inteira com uma conta grátis.
O mesmo que o TTL do registro anterior — muitas vezes 1 hora, às vezes até 24 horas ou mais. Durante a troca, algumas mensagens ainda podem chegar aos servidores antigos, então mantenha-os funcionando por um ou dois dias.
Uma conta grátis traz 200 créditos (10 para e-mails de provedores gratuitos) para validar listas em lote, pela API REST ou em tempo real nos seus formulários.
Criar conta grátis — 200 créditosSem cartão de crédito. Os créditos não expiram.