Validador de Endereço de E-mail e Registro MX

Valide um endereço de e-mail e verifique se o domínio consegue receber mensagens.

email-validator

🌐 The domain is resolved server-side over DNS-over-HTTPS. Only the part after @ is looked up — the local part is never sent to a resolver, and no mail is sent.

§01 SOBRE ESTA FERRAMENTA

Visão geral

Duas perguntas distintas são confundidas. «Este endereço está bem formado?» responde-se a partir da cadeia de caracteres. «O correio enviado para aqui chegará?» responde-se em parte a partir do DNS. «Esta caixa de correio existe?» não se responde de forma alguma sem enviar correio, e tudo o que afirme o contrário está a adivinhar.

Esta ferramenta responde às duas primeiras e di-lo com clareza quanto à terceira. Verifica a sintaxe com as regras que os servidores aplicam na prática e depois resolve o domínio para os registos MX, A/AAAA, SPF e DMARC — o suficiente para distinguir um erro de escrita de um domínio que não pode receber correio e de um domínio cuja autenticação está avariada.

Como usar

Escreva ou cole um endereço.
Leia os dois resultados principais: Syntax e Domain accepts mail.
Leia as observações. Nomeiam o problema concreto em vez de dar um veredicto.

O que a verificação de sintaxe impõe

A RFC 5322 permite muito mais do que os sistemas de correio aceitam. Comentários entre parênteses, partes locais entre aspas com espaços e espaços de dobra aninhados são gramática legal que uma parte considerável dos servidores reais rejeita. Um verificador que aceite tudo o que é legal diz-lhe que um endereço está bem quando ele vai devolver.

Por isso as regras aplicadas aqui são as práticas:

A parte local pode conter letras, dígitos e !#$%&'*+-/=?^_`{|}~. — o que inclui o apóstrofo, porque nomes como o'[email protected] existem, e +, porque o subendereçamento ao estilo do Gmail é de uso diário.
Sem ponto inicial, sem ponto final, sem pontos consecutivos.
A parte local está limitada a 64 caracteres e o domínio a 255, segundo a RFC 5321. Cada etiqueta do domínio está limitada a 63.
O domínio tem de ser um nome de anfitrião válido com um TLD de pelo menos duas letras. user@localhost é recusado; só tem sentido dentro de uma única máquina.
O não-ASCII tem de estar em Punycode. user@日本語.jp é rejeitado a favor da sua forma xn--, porque a entrega à forma Unicode exige suporte de SMTPUTF8 em todos os saltos.

Como ler o resultado do DNS

Os registos MX são listados por prioridade, do menor para o maior. Ter vários é normal — são alternativas, e prioridades iguais distribuem a carga.

O null MX (RFC 7505) é um único registo com prioridade 0 e anfitrião vazio. Significa que o domínio não aceita correio de forma deliberada, e suprime o recurso ao MX implícito. É a configuração correta para um domínio usado apenas para um sítio web, e o example.com utiliza-a.

O MX implícito é a situação oposta: não existe registo MX algum, pelo que os remetentes recorrem ao endereço A ou AAAA. O domínio é tecnicamente alcançável e o resultado é normalmente acidental. O correio chega ao que estiver na porta 25 do servidor web, isto é, a nenhum lugar útil.

O SPF é examinado à procura das falhas que quebram a entrega, não de questões de estilo. Mais de dez mecanismos com resolução DNS (include, a, mx, ptr, exists, redirect) provoca um erro permanente segundo a RFC 7208 §4.6.4 e a autenticação falha sem mais — um limite fácil de atravessar acrescentando um fornecedor. +all autoriza todos os remetentes da Internet e anula o SPF por completo. ptr está desaconselhado. Um registo sem mecanismo all fica aberto, exceto se usar redirect=, caso em que omitir all é o correto.

Dois registos SPF num domínio também são um erro permanente, e é relatado porque se apresenta como uma falha de entrega intermitente e inexplicada. Acontece sempre que se acrescenta o registo de um segundo fornecedor ao lado do primeiro em vez de o integrar com include:.

O DMARC é lido de _dmarc.<domínio>. p=none é assinalado: apenas recolhe relatórios, pelo que as falhas são registadas e entregues de igual modo. É o ponto de partida correto e o lugar errado para parar.

Exemplos

Um formulário de registo que rejeita endereços reais — compare a sua validação com o que é aplicado aqui. As expressões regulares copiadas da Internet rejeitam habitualmente etiquetas +, apóstrofos e TLD longos.
«Nunca receberam o meu correio» — verifique primeiro o domínio do destinatário. Um null MX ou um MX ausente explica-o de imediato e retira a conversa do seu servidor.
Auditar o seu próprio domínio de envio — o número de resoluções de SPF, +all e um DMARC parado em p=none são os três achados que mais vezes explicam o correio acabar no lixo.
Depois de acrescentar um fornecedor de correio — os fornecedores dão-lhe um include: e raramente mencionam o tecto de dez resoluções. Verifique o total, não a linha nova.
Investigar uma mensagem específica — o analisador de cabeçalhos de e-mail mostra o percurso de entrega e os veredictos SPF, DKIM e DMARC tal como o destinatário os registou, e o visualizador .eml abre uma mensagem guardada. Esta ferramenta responde à pergunta antes do envio; essas duas respondem depois.

Observações

O DNS é resolvido por DNS-over-HTTPS com um tempo de espera de cinco segundos por consulta. Se uma consulta falhar, os campos que ela teria preenchido são relatados como ausentes e não como erro, pelo que uma resolução TXT lenta não descarta um resultado MX correto.

O domínio só é consultado se for um nome de anfitrião válido. Um endereço que falhe a verificação estrutural não gera tráfego DNS algum.

A lista de domínios descartáveis cobre fornecedores bem conhecidos a título de aviso e não como autoridade — aparecem novos domínios constantemente e não estar na lista não significa nada. A verificação de contas de função é igualmente informativa: info@ e admin@ são endereços perfeitamente válidos que simplesmente não pertencem a uma pessoa.

Nenhum correio é enviado, nenhuma ligação SMTP é aberta, e a parte local do endereço nunca é incluída numa consulta DNS. Ver a política de privacidade.

FAQ

Isto diz-me se a caixa de correio existe?

Não, e nenhuma ferramenta o consegue dizer de forma fiável. O comando VRFY do SMTP está desativado em quase todo o lado, e sondar com RCPT TO é recolha de endereços: é o que fazem os remetentes de spam, provoca limitações ou bloqueios, e os fornecedores com endereço genérico respondem sim a tudo. O que é possível responder é se a sintaxe é válida e se o domínio aceita correio, e é isso que é relatado.

O endereço que escrevo é enviado para algum lado?

O domínio é resolvido por DNS-over-HTTPS. A parte local — tudo o que precede o @ — não é necessária para resolver nada, pelo que nunca é incluída numa consulta DNS. Nenhum correio é enviado e nada é guardado.

Porque é que o meu endereço válido aparece como sintaxe incorreta?

O mais frequente são pontos consecutivos, um ponto no início ou no fim da parte local, ou um carácter não ASCII. Os domínios internacionalizados têm de ser indicados em Punycode (xn--…), porque um remetente sem suporte de SMTPUTF8 não consegue entregar à forma Unicode. Partes locais entre aspas como "a b"@example.com também são recusadas: são legais na RFC 5322 e rejeitadas por uma parte considerável dos sistemas de correio reais.

O que é um null MX?

Um único registo MX de prioridade 0 a apontar para a raiz (apenas um ponto), definido na RFC 7505. É o titular do domínio a declarar explicitamente que esse domínio não recebe correio, e impede que os remetentes recorram ao registo A. O example.com publica um, e por isso é relatado como «não aceita correio» e não como «sem MX».

O domínio não tem MX mas aparece como alcançável. Porquê?

É a regra do MX implícito: sem registo MX, os remetentes recorrem ao endereço A ou AAAA. É válido e quase nunca é intencional, daí o aviso. Se esse anfitrião for um servidor web e não um servidor de correio, o correio está a ser entregue num local que ninguém lê.

Uma conta de função ou um domínio descartável são um problema?

Nenhum é inválido — ambos são contexto. info@ e support@ chegam a uma caixa partilhada que várias pessoas ou ninguém lê, o que importa para a recuperação de contas. Um domínio descartável sugere que o endereço foi criado para ser abandonado. A verificação é informativa, e a lista de descartáveis cobre apenas fornecedores bem conhecidos, pelo que não estar nela não prova nada.