Como verificar se um e-mail é válido sem enviar nada

Dá para saber se um endereço de e-mail é real sem enviar nada para ele. O método não é truque nenhum: é a conversa normal de entrega de e-mail, interrompida um passo antes da entrega.

Abaixo estão as quatro checagens, na ordem em que devem ser feitas, e o que cada uma realmente consegue provar.

1. Sintaxe

O endereço segue as regras de formato de um e-mail? Essa checagem pega erros de digitação, @ faltando e caracteres inválidos.

É barata e instantânea, e não prova quase nada. asdkjhaslkdjh@gmail.com tem sintaxe perfeitamente válida e com certeza não é uma caixa postal real. Qualquer ferramenta que pare aqui é só um corretor ortográfico.

2. Domínio e registros MX

Todo domínio que recebe e-mail publica registros MX no DNS, indicando os servidores que aceitam mensagens para ele. Se um domínio não tem nenhum, ele não pode receber e-mail e todos os endereços nele estão mortos.

Você pode conferir à mão:

$ dig +short MX gmail.com
5 gmail-smtp-in.l.google.com.
10 alt1.gmail-smtp-in.l.google.com.

Sem registro MX e sem registro A de reserva, o domínio não consegue receber e-mail. A RFC 5321 diz que o remetente recorre ao registro A do domínio quando não existe MX, então a falta de MX sozinha é um sinal forte, não uma prova. Um null MX (MX 0 .) é definitivo: o domínio declarou que não aceita e-mail nenhum. De qualquer forma, esta é a checagem mais barata que existe, e ela pega domínios digitados errado e abandonados.

3. Checagem de descartáveis e de endereços de função

Duas coisas que vale saber antes de enviar qualquer coisa:

Domínios descartáveis (Mailinator, Guerrilla Mail e milhares de outros) são caixas de entrada temporárias. Tecnicamente a caixa postal existe, mas a pessoa por trás dela nunca vai ver a mensagem.

Endereços de função (info@, sales@, admin@) são lidos por várias pessoas ou por ninguém, atraem denúncias de spam e às vezes são reciclados como armadilhas de spam (spam traps).

Nenhum dos dois é uma falha definitiva. Os dois são decisões que você deve tomar de propósito, e não descobrir depois.

4. A checagem SMTP da caixa postal

Esta é a que de fato responde à pergunta.

Você se conecta ao servidor de e-mail do domínio e inicia a mesma conversa que iniciaria para entregar uma mensagem, mas para antes de enviar qualquer coisa:

$ telnet gmail-smtp-in.l.google.com 25

> HELO yourdomain.com
< 250 mx.google.com at your service

> MAIL FROM: <you@yourdomain.com>
< 250 2.1.0 OK

> RCPT TO: <someone@gmail.com>
< 250 2.1.5 OK                    ← a caixa postal existe

Se a caixa postal não existe:

> RCPT TO: <definitely-not-real-xyz9987661@gmail.com>
< 550-5.1.1 The email account that you tried to reach does not exist

Depois, QUIT. Nenhuma mensagem é enviada e nada aparece na caixa de entrada de ninguém. O comando DATA, que é o que realmente transmite uma mensagem, nunca é emitido.

Essa diferença entre 250 e 550 é tudo o que a verificação de e-mail é.

Por que você provavelmente não consegue fazer isso sozinho

Tente esse comando telnet do seu notebook e ele provavelmente vai travar. Quase todo provedor de internet residencial e de nuvem bloqueia a porta 25 de saída para evitar spam. Medimos isso em dois grandes provedores de hospedagem:

Provedor	Porta 25 de saída
Railway	Bloqueada
DigitalOcean	Bloqueada

Esse é o único motivo de a verificação de e-mail existir como serviço pago. A checagem em si é simples; o difícil é estar numa rede que permite fazê-la, a partir de um IP com boa reputação e DNS reverso correspondente.

Também vale saber disso por causa de como algumas ferramentas lidam com o problema. Se a checagem SMTP de um verificador falha e o código recorre a classificar o endereço como válido, então todo endereço em um domínio ativo passa e nada foi realmente verificado. Conhecemos esse defeito de perto: nosso próprio motor fazia isso até descobrirmos.

O que não tem resposta

Dois casos derrubam o método por completo:

Domínios catch-all aceitam qualquer endereço do domínio, real ou não. A aceitação não prova nada, então nada pode ser confirmado. Escrevemos sobre isso aqui.

Provedores que não respondem com clareza. Yahoo e iCloud muitas vezes se recusam a confirmar ou negar uma caixa postal na etapa RCPT, então a sondagem fica inconclusiva. Já o Outlook.com e o Microsoft 365 rejeitam destinatários desconhecidos durante a conversa.

Um verificador honesto classifica os dois casos como arriscado. Um verificador que os classifica como válidos está chutando e torcendo para você nunca conferir.

Resumindo

1. Sintaxe: pega erros de digitação, prova pouco
2. Registros MX: mostra se o domínio consegue receber e-mail
3. Sinalização de descartáveis e de função: decisões, não falhas
4. Checagem SMTP da caixa postal: a resposta de verdade, quando a rede permite

Tudo o que não puder ser confirmado deve voltar como arriscado. As ferramentas que valem o seu dinheiro são as que admitem quando não sabem.