Checagem de sintaxe, de MX e verificação SMTP: o que cada uma detecta

Uma checagem de sintaxe confirma que um endereço está bem formado. Uma checagem de MX confirma que o domínio publica servidores de e-mail. Uma checagem SMTP pergunta a esse servidor se a caixa postal específica existe. Cada uma pega falhas que a anterior não enxerga, e só a última diz alguma coisa sobre a pessoa. As consultas reais abaixo mostram exatamente onde cada camada para.

A maioria das explicações sobre isso para em "sintaxe é fraca, MX é melhor, SMTP é o melhor". É verdade, mas esconde a parte interessante: cada camada tem casos-limite em que a leitura óbvia está errada. Fizemos as consultas DNS deste post em 1º de outubro de 2026 com dig, a partir de uma conexão comum. A saída bruta está nas nossas notas de pesquisa.

As três camadas num relance

Cada camada responde a uma pergunta diferente, e nenhuma consegue responder à pergunta da seguinte.

Camada	Pergunta que responde	Custo	Detecta	Não detecta
Sintaxe	Isto tem formato de endereço de e-mail?	Microssegundos, sem rede	@ ausente, espaços, pontos duplos, partes longas demais	Domínios com erro de digitação, domínios mortos, caixas postais mortas
MX / DNS	Este domínio pode receber e-mail?	Uma consulta DNS	Domínios inexistentes, null MX, a maioria dos domínios com erro de digitação	Caixas postais mortas em domínios ativos
SMTP RCPT TO	Este servidor aceita e-mail para esta caixa postal?	Uma conexão TCP na porta 25, alguns segundos	Caixas postais apagadas e que nunca existiram	Domínios catch-all, servidores que aceitam e depois devolvem

Camada 1: sintaxe

A checagem de sintaxe rejeita entradas que não podem ser um endereço, e nada mais. É a única camada que roda sem rede, o que a torna ideal para dar retorno instantâneo num formulário e inútil como veredito.

O que ela pega de forma legítima:

Entrada	Por que falha
jane.doe.example.com	Sem @
jane doe@example.com	Espaço fora de aspas
jane..doe@example.com	Pontos consecutivos numa parte local sem aspas
jane@	Sem domínio
Uma parte local de 70 caracteres	A seção 4.5.3.1.1 da RFC 5321 limita a parte local a 64 octetos

O que ela deixa passar, corretamente, porque tudo isto é sintaxe válida:

• asdkjhaslkdjh@gmail.com: bem formado, e certamente não é uma pessoa.
• jane@gmial.com: bem formado, domínio errado.
• jane+newsletter@gmail.com: bem formado e real. O endereçamento com sinal de mais (plus addressing) é legítimo, e uma regex rígida que o rejeita está recusando usuários reais.

O erro comum é ir para o outro lado e escrever uma regex tão rígida que rejeita endereços válidos. Explicamos o porquê em por que a regex de validação de e-mail falha. Num pipeline de verificação, a sintaxe só precisa ser rígida o bastante para barrar lixo antes que você gaste uma consulta DNS com ele.

Camada 2: MX e DNS

A camada de MX pergunta ao DNS quais servidores aceitam e-mail para o domínio, e a resposta tem mais de dois formatos possíveis. A maioria dos guias trata isso como sim ou não. Veja o que de fato recebemos para oito domínios:

Domínio	Status DNS	Resposta MX	O que significa
gmail.com	NOERROR	Cinco hosts MX do Google	Pode receber e-mail
outlook.com	NOERROR	outlook-com.olc.protection.outlook.com	Pode receber e-mail
nonexistent-domain-zz918273.com	NXDOMAIN	nenhuma	O domínio não existe. Inválido, com certeza
example.com	NOERROR	0 .	Null MX: declara explicitamente que não aceita e-mail
yahoo.co	NOERROR	0 .	Null MX. Um erro de digitação de yahoo.com que recusa e-mail
gmial.com	NOERROR	nenhuma, mas existe um registro A	Sem MX. Veja a regra do MX implícito abaixo
gmai.com	NOERROR	1 mail.h-email.net.	Um domínio com erro de digitação com MX funcionando
hotmial.com	SERVFAIL na primeira consulta, depois 5 mail.h-email.net.	Uma falha temporária de DNS, depois um MX funcionando	Tente de novo, nunca decida com base em SERVFAIL

Essa tabela traz quatro lições.

Null MX é um "não" definitivo

example.com e yahoo.co publicam um único registro MX apontando para . com preferência 0. Isso é um null MX, definido na RFC 7505: "Para indicar que um domínio não aceita e-mail, ele anuncia um único RR MX ... com ... número de preferência 0 e um rótulo de comprimento zero". Uma checagem ingênua que só pergunta "existe registro MX?" vê um registro e aprova o domínio. Uma checagem correta reconhece o ponto e reprova todo endereço naquele domínio. Você pode checar qualquer domínio com a ferramenta de consulta de MX.

Sem MX não é exatamente o mesmo que sem e-mail

gmial.com não tem registros MX, mas tem um registro A. Pela seção 5.1 da RFC 5321, "Se uma lista vazia de MXs for retornada, o endereço é tratado como se estivesse associado a um RR MX implícito ... apontando para aquele host." Ou seja, o servidor que envia deveria tentar o registro A.

Na prática, um domínio sem MX e só com uma página estacionada quase nunca roda um servidor de e-mail, então a tentativa de entrega falha. Mas o comportamento estritamente correto é tratar "sem MX, com A" como "tente o host na porta 25" e só reprovar se ninguém responder. Tratar como inválido na hora costuma estar certo e às vezes está errado.

Domínios com erro de digitação podem passar na checagem de MX

gmai.com e hotmial.com publicam um MX apontando para o mesmo host de terceiros, mail.h-email.net. O e-mail enviado para lá não vai para a pessoa que digitou errado o próprio endereço do Gmail. A camada de MX não consegue dizer isso. Ela informa, com precisão, que o domínio recebe e-mail. É por isso que a detecção de erros de digitação é uma checagem separada do DNS: ela compara o domínio com uma lista de grafias erradas conhecidas dos grandes provedores. Veja como pegar erros de digitação em e-mails no cadastro.

SERVFAIL não é NXDOMAIN

Nossa primeira consulta para hotmial.com retornou SERVFAIL. A segunda retornou um registro MX. A RFC 5321 é explícita: um domínio inexistente "DEVE ser informado como erro", enquanto "Se um erro temporário for retornado, a mensagem DEVE ser colocada na fila e reenviada mais tarde." Um verificador que marca SERVFAIL como inválido vai apagar endereços reais toda vez que um servidor DNS tiver um minuto ruim.

Camada 3: a checagem SMTP da caixa postal

A checagem SMTP é a única camada que pergunta sobre a caixa postal e não sobre o domínio. O verificador se conecta ao host MX de maior prioridade na porta 25, se apresenta, informa um remetente e depois informa o destinatário com RCPT TO. O código de resposta do servidor é a resposta, e a conexão é encerrada antes de qualquer mensagem ser enviada. A conversa completa aparece passo a passo em como checar um e-mail sem enviar.

O que ela pega e as camadas anteriores não:

Endereço	Sintaxe	MX	SMTP
former.employee@company.com (caixa postal apagada)	Passa	Passa	Rejeitado, 550 5.1.1
random-string-xyz@gmail.com	Passa	Passa	Rejeitado, 550 5.1.1
real.person@gmail.com	Passa	Passa	Aceito, 250

Esta é a camada que importa para hard bounces (devoluções permanentes) numa lista de pessoas reais. Quando as pessoas saem do emprego ou abandonam contas, o domínio continua funcionando e só a caixa postal morre, então só esta camada enxerga isso.

Onde o SMTP para

A camada SMTP tem os próprios limites, e é por causa deles que existe um quarto resultado, arriscado:

• Domínios catch-all respondem 250 a qualquer endereço, inclusive os que não podem existir. Um bom verificador testa antes um endereço aleatório para detectar isso. Veja o que é um domínio catch-all.
• Provedores que aceitam e depois devolvem dizem 250 no RCPT TO e devolvem a mensagem mais tarde. O Yahoo é o exemplo mais conhecido, tratado em por que endereços do Yahoo são difíceis de verificar.
• Greylisting e timeouts retornam um código temporário 4xx ou nada. Tente de novo mais tarde.
• Porta 25 bloqueada do lado do verificador. A checagem nem acontece. Medimos isso em hosts de nuvem no nosso texto sobre por que os provedores de nuvem bloqueiam a porta 25.

Em todos esses casos, a resposta honesta é arriscado ou desconhecido. Responder válido é um chute.

Quais camadas você precisa, por situação

Use quantas camadas o seu orçamento de latência permitir e nunca pare na sintaxe para nada que você pretenda enviar.

Situação	Camadas a rodar	Por quê
Campo de formulário ao vivo, enquanto o usuário digita	Só sintaxe	Retorno instantâneo, sem chamadas de rede
Envio do formulário	Sintaxe + MX + checagem de erro de digitação, SMTP se responder dentro do seu timeout	Veja verificação em tempo real em formulários de cadastro
Lista de cold email antes de uma campanha	As três, mais detecção de catch-all	Uma caixa postal morta custa reputação, não só um envio desperdiçado
Lista antiga de newsletter que vai receber envios de novo	As três	A deterioração está na camada da caixa postal, que sintaxe e MX não enxergam
Limpeza de dados num CRM, sem envio planejado	Sintaxe + MX	Barato, encontra os domínios mortos

Como o SimpleVerifier roda as camadas

Rodamos as três camadas em ordem e paramos assim que uma dá uma resposta definitiva: sintaxe quebrada ou um domínio sem servidor de e-mail retorna inválido sem abrir uma conexão SMTP. Domínios ativos seguem para a checagem RCPT TO. Tudo o que o servidor de e-mail não confirmaria, inclusive domínios catch-all, volta como arriscado, nunca como válido.

Na prática

Sintaxe é um filtro, MX é um teste do domínio, SMTP é o teste da caixa postal. Se uma ferramenta ou um script que você escreveu para no MX, ela está dizendo que o domínio funciona e nada sobre a pessoa. Antes de confiar em qualquer uma delas, leia direito a resposta do DNS: NXDOMAIN e null MX são falhas definitivas, SERVFAIL pede nova tentativa, e um domínio com erro de digitação e MX ativo é um problema que nenhuma consulta DNS vai sinalizar.

Para ver as três camadas rodando num único endereço, experimente a ferramenta gratuita de verificação de e-mail.