Tema

Ferramentas populares

Verificar email: verificador e validador

Para verificar um email e saber se o endereço é de verdade sem enviar nada, perguntamos ao servidor de email dele e mostramos a conversa. Ou envie o seu próprio email para um endereço de teste e receba um relatório completo de entregabilidade.

Fontes: DNS (MX, SPF, DMARC) · uma verificação SMTP ao vivo a partir do nosso servidor, parada antes do DATA · nosso próprio servidor de email para o email de teste (Cloudflare Email Routing como reserva) · SpamAssassin 4

Perguntamos ao servidor de email do endereço, como faria um remetente, e paramos antes de enviar qualquer coisa.

Experimente

Nada é enviado ao endereço. Registramos o domínio e o código de resposta; uma resposta fica guardada por até um dia sob um hash com chave, sem o endereço.

Como saber se um email existe sem enviar um email

Um servidor de email diz se conhece um endereço antes de qualquer mensagem ser enviada. Fazemos essa pergunta e desligamos.

Enviar um email é uma conversa curta entre dois servidores. O remetente cumprimenta (EHLO), informa um endereço de retorno (MAIL FROM), informa o destinatário (RCPT TO) e só então envia a mensagem (DATA). O servidor receptor responde cada linha com um código de três dígitos (RFC 5321).

Seguimos a conversa até o RCPT TO e lemos a resposta. Depois reiniciamos (RSET), perguntamos mais uma vez sobre um endereço inventado do mesmo domínio (o controle) e nos despedimos com QUIT. O DATA nunca é enviado, então nada chega à caixa de entrada de ninguém, e o endereço de retorno vazio significa que nada pode voltar.

probe.dnsrobot.netNosso servidor de verificação · Mumbai · 198.51.100.25mx-in.g.apple.comO servidor de email do domínio · Apple · 203.0.113.17
  1. 220 hfd-mx01.apple.com -- Server ESMTP (Oracle Communications Messaging Server 8.1.0.28.20250821 64bit (built Aug 21 2025))295 ms
  2. EHLO probe.dnsrobot.net
  3. 250 hfd-mx01.apple.com · 8BITMIME · PIPELINING · CHUNKING …140 ms
  4. MAIL FROM: <>remetente vazio: nada pode voltar
  5. 250 2.5.0 Address Ok157 ms
  6. RCPT TO: <postmaster@apple.com>1
  7. 250 2.1.5 postmaster@apple.com Ok1200 ms
  8. RSET · MAIL FROM:<> · RCPT TO: <5b1c71ed2e78ecf2@apple.com>2um endereço inventado do mesmo domínio
  9. 550 5.1.1 unknown or illegal alias: 5b1c71ed2e78ecf2@apple.com2145 ms
  10. DATA nunca enviado: paramos antes da mensagem
  11. QUIT
  1. Sintaxe1 ms
  2. Domínio e MX181 ms
  3. Listas< 1 ms
  4. Servidor de email1,5 s
Uma verificação real de postmaster@apple.com, o endereço de função que todo domínio de email deve ter (RFC 2142), a partir do nosso servidor em Mumbai: 7 respostas em 1,5 s. O servidor recusa o endereço inventado (550 5.1.1), e é isso que torna crível o sim dele ao endereço real.
Resultado do verificador de email para postmaster@apple.com: Entregável, com a conversa SMTP e o endereço de controleResultado do verificador de email para postmaster@apple.com: Entregável, com a conversa SMTP e o endereço de controleO vereditoEntregável, Não entregável, Aceita tudo, Arriscado ou Desconhecido, com os códigos de resposta que o decidiram e uma frase dizendo por quê.As quatro etapasSintaxe, os servidores de email do domínio, as listas de descartáveis e de endereços de função, e depois o próprio servidor de email, cada uma com o seu tempo.As respostas que decidiramO endereço e um endereço inventado do mesmo domínio: um sim ao primeiro e um não ao segundo torna o sim crível.A conversaCada comando que o nosso servidor enviou e cada resposta que o servidor de email deu, como aconteceu, com o código e o tempo de cada resposta.Nada enviadoO DATA nunca é enviado: a conversa para antes de existir uma mensagem, então nada chega à caixa de entrada e nada pode voltar.
Uma verificação real de postmaster@apple.com, o endereço de função que todo domínio de email deve ter: o veredito, as quatro etapas, as duas respostas que o decidiram e a conversa SMTP inteira, parada antes do DATA. Selecione um número para ver o que cada parte mostra.

O que cada resultado do verificador de email significa

Cinco respostas, cada uma ligada à resposta que a produziu.

Entregável exige duas coisas: um sim para o endereço e um não para um inventado do mesmo domínio (ou um provedor que, pelas nossas medições, confere cada endereço). Sem a segunda resposta, um sim é só o sim de um servidor que talvez diga sim a qualquer um.

Desconhecido é honesto, não uma falha: o servidor se recusou a falar com o nosso servidor de verificação, pediu que esperássemos ou não respondeu. Não diz nada sobre o endereço, então nunca o transformamos em “inválido”.

  • Entregável
    O endereço
    250
    Um inventado
    550

    O servidor conhece o endereço e recusa um desconhecido do mesmo domínio.

    Enviar.
  • Não entregável
    O endereço
    550 5.1.1
    Ou o domínio
    MX nuloo domínio não existe

    O servidor diz que a caixa de correio não existe, ou o domínio não recebe email de jeito nenhum.

    Não enviar: voltaria.
  • Aceita tudo
    O endereço
    250
    Um inventado
    250

    O servidor diz sim a qualquer coisa, então o sim dele não prova nada.

    Enviar só se você o recebeu da pessoa.
  • Arriscado
    O domínio
    lista de descartáveis
    Ou a caixa de correio
    552cheia

    Existe, mas não vai durar ou não consegue receber email agora.

    Evitar para qualquer coisa de que você precise depois.
  • Desconhecido
    O endereço
    451554sem resposta
    Ou o DNS
    SERVFAIL

    O servidor não quis responder ou pediu que voltássemos. Não é um não.

    Verificar de novo mais tarde, ou simplesmente enviar.
Todo resultado vem de um código de resposta (RFC 5321) ou de um fato sobre o domínio, nunca de um palpite. Endereços de função, gratuitos, de alias e antigos são marcas ao lado do resultado, nunca o resultado.

Quais provedores de email podem ser verificados

O que uma verificação consegue dizer depende do provedor. Medimos 65 domínios de email, operados por 53 provedores, a partir do nosso servidor.

A maioria dos provedores de email pessoal recusa endereços desconhecidos no RCPT, então a verificação ali é confiável. Alguns aceitam tudo e resolvem o email depois; o Outlook.com às vezes diz sim uma vez para impedir a coleta de endereços; uns poucos recusam servidores que não conhecem.

Nunca usamos páginas de recuperação de senha ou de cadastro para testar um endereço, como alguns verificadores fazem: isso viola os termos dos provedores e é justamente como atacantes encontram contas.

Medido a partir do nosso servidor22 de outubro de 2026 · 65 domínios, 10 deles de empresas
Confere cada endereço42 domíniosUm endereço desconhecido recebe um 5xx no RCPT, então um sim é um sim de verdade.
  • 163.com
  • au.com
  • biglobe.ne.jp
  • comcast.net
  • daum.net
  • docomo.ne.jp
  • ezweb.ne.jp
  • freenet.de
  • gmail.com
  • gmx.com
  • gmx.de
  • hanmail.net
  • hey.com
  • i.softbank.jp
  • icloud.com
  • kakao.com
  • laposte.net
  • libero.it
  • mail.com
  • mailbox.org
  • naver.com
  • o2.pl
  • ocn.ne.jp
  • orange.fr
  • posteo.de
  • proton.me
  • qq.com
  • rambler.ru
  • rediffmail.com
  • seznam.cz
  • sfr.fr
  • softbank.ne.jp
  • terra.com.br
  • tuta.io
  • uol.com.br
  • web.de
  • wp.pl
  • yandex.ru
  • zoho.com
  • apple.com
  • microsoft.com
  • salesforce.com
Diz sim a alguns endereços inventados2 domíniosOutlook.com: 2 de 12 endereços inventados receberam 250 uma vez. Perguntamos duas vezes.
  • hotmail.com
  • outlook.com
Aceita todos os endereços9 domíniosAqui um sim não prova nada: esses servidores aceitam primeiro e resolvem o email depois.
  • mail.ru
  • yahoo.co.jp
  • amazon.com
  • github.com
  • google.com
  • netflix.com
  • shopify.com
  • spotify.com
  • stripe.com
Recusam o nosso servidor por enquanto8 domíniosQuerem que o DNS reverso do nosso servidor confira, de ida e de volta. A própria lista de erros do Yahoo também mostra que mensagens para contas desconhecidas voltaram depois de enviadas.
  • aol.com
  • att.net
  • bol.com.br
  • cox.net
  • free.fr
  • nifty.com
  • verizon.net
  • yahoo.com
Greylisting ou adiamento3 domíniosUm 4xx. O Fastmail usa greylisting: a mesma pergunta um minuto depois recebe resposta. onet.pl e interia.pl adiam por uma regra com data de término ou um limite de entrega, que esperar não muda.
  • fastmail.com
  • interia.pl
  • onet.pl
Pedem para não ser verificados1 domínioDeutsche Telekom: não nos conectamos de jeito nenhum.
  • t-online.de
As empresas mostram a marca da plataforma de email delas (Microsoft 365, Google Workspace, Proofpoint, iCloud). A resposta de uma empresa é configuração dela, não regra da plataforma: o microsoft.com confere cada endereço, o github.com na mesma plataforma aceita qualquer um.

Catch-all, greylisting e recusas: quando um endereço não pode ser confirmado

Três jeitos de um servidor de email evitar responder, e como cada um aparece no resultado.

Um servidor que aceita tudo (catch-all) diz 250 a todo endereço, real ou não. Muitas empresas do Microsoft 365 funcionam assim sem saber: o Directory-Based Edge Blocking só recusa endereços desconhecidos quando o domínio está configurado como “Autoritativo”.

O greylisting responde 451 a remetentes que não conhece e aceita a mesma pergunta um minuto depois (RFC 6647). As recusas podem vir em qualquer etapa até o RCPT (a do bol.com.br veio no próprio RCPT), mas falam do nosso servidor, não do endereço, então o resultado é Desconhecido, nunca um não.

Aceita tudo
  • sam.example@example.org250
  • 9e2b7c41d0a8f365@example.org250

Os dois receberam um sim: o servidor não consegue distingui-los, então nós também não.

Um domínio do Microsoft 365 configurado comoRetransmissão interna250qualquer endereçoAutoritativo (Directory-Based Edge Blocking)550 5.4.1um endereço desconhecido
Greylisting
0 s451 4.7.1“Recipient address rejected: Temporary deferral, try again soon”
espere pelo menos um minuto: mesmo servidor, mesmo remetente, mesmo endereço (RFC 6647)
60+ s250550a resposta de verdade

O Fastmail fez isso conosco. O resultado oferece Verificar de novo depois de um minuto, nunca em repetição sem pausa. (onet.pl e interia.pl também responderam 450, mas com uma regra com data de término e um limite de entrega: são recusas, então não oferecemos a espera.)

Recusas: onde cada servidor nos barrou
conexãosaudaçãoEHLOMAILRCPT
nifty.com554
FCrDNS check failed: reverse DNS does not match the connecting IP
free.fr421
Refused. Your reverse DNS entry does not resolve to an IP.
t-online.de554
None/bad reputation … (NOWL)
yahoo.com550 5.7.25
Forward-confirmed reverse DNS failed
bol.com.br450 4.7.25
Client host rejected: cannot find your hostname

Uma recusa fala do nosso servidor, não do endereço, venha onde vier (a do bol.com.br veio no RCPT), então o resultado é Desconhecido, nunca “inválido”.

Códigos e textos como os servidores os enviaram ao nosso servidor de verificação em 22 de outubro de 2026. Quatro das cinco recusas são sobre o DNS reverso (PTR confirmado nos dois sentidos) e somem quando o registro PTR do nosso servidor conferir.

Endereços de email descartáveis, de função, gratuitos e de alias

As marcas descrevem o endereço; nunca decidem o resultado sozinhas.

Uma caixa de função (support@, sales@) é de verdade, mas compartilhada; um endereço gratuito é normal para pessoas; um alias encaminha para a caixa de verdade de alguém; e um endereço descartável é uma caixa pública que some em poucas horas.

As operadoras japonesas ainda têm endereços com dois pontos, ou um ponto antes do @. Eles quebram a RFC, mas recebem email, então perguntamos ao servidor de email sobre eles exatamente como foram digitados.

supportcaixa de função (RFC 2142)+orderssubendereço (RFC 5233)@example.como domínio decide: gratuito, descartável ou de alias
  • Caixa de funçãopostmaster@support@sales@

    A caixa de uma equipe: de verdade e muitas vezes lida, mas não é o endereço pessoal de ninguém. A RFC 2142 nomeia as que um domínio deveria ter.

  • Provedor gratuito

    Qualquer um pode se cadastrar. Normal para pessoas; incomum para a equipe de uma empresa.

  • Descartável@mailinator.comcerca de 9.900 domínios

    Caixas públicas que somem em poucas horas. Da lista disposable-email-domains (CC0), comparada com o domínio registrável.

  • Serviço de alias

    Encaminha para uma caixa de verdade que a pessoa mantém privada. Não é descartável: as respostas chegam a ela.

  • Endereço antigo de operadorataro..yamada@docomo.ne.jp

    Inválido pela RFC, mas em uso: docomo e au deixam as pessoas manterem endereços antigos com “..” ou “.@”. Perguntamos ao servidor exatamente como foi digitado.

As marcas nunca decidem o resultado sozinhas: uma caixa de função pode ser entregável, e um alias pode aceitar tudo.

Como funciona o teste de entregabilidade de email: um mail tester grátis

Envie um email de verdade para um endereço de uso único; o relatório se monta conforme cada parte é verificada.

O seu endereço de teste aceita uma mensagem por 2 horas. Nosso próprio servidor de email a recebe para mailtest.dnsrobot.net por TLS e vê a sessão SMTP em primeira mão: a versão do TLS, a saudação, como o servidor de envio conversa. O Cloudflare Email Routing é o caminho de reserva.

Tudo roda sobre o que de fato chegou: o endereço que se conectou, os cabeçalhos que o seu serviço acrescentou, o HTML que os seus leitores vão receber. Depois SPF, DKIM, DMARC, ARC, o formato, o conteúdo, os cabeçalhos de cancelamento de inscrição, o SpamAssassin e as regras dos provedores de caixa de entrada.

  1. Seu app de emailvocê aperta Enviar14:02:10
  2. Seu servidor de envioseu serviço de emailSendGrid · 198.51.100.24
    DNS reverso (PTR)Nome HELOListas de bloqueio
  3. Nosso servidor de emailrecebe por TLSmailprobe.dnsrobot.net · TLSv1.3
    a sessão SMTPVersão do TLSEHLO e pipeliningFins de linha
    a mensagemSPFDKIMDMARCARCFormatoConteúdoCancelar inscrição
  4. Seu relatórioas partes aparecem conforme são verificadas14:02:24
    SpamAssassinRegras do Gmail · Yahoo · Outlook.comNota
Reserva: Cloudflare Email Routingroute1–3.mx.cloudflare.netrecebe o email se o nosso servidor estiver fora do ar; não repassa os detalhes do TLS
O que acontece com a sua mensagem
0 schega ao nosso servidor de email11 sanálise feita: o corpo e os anexos são excluídos7 diascabeçalhos, links e a prévia excluídos (ou antes: Excluir relatório)
O exemplo desta página: uma newsletter enviada pelo SendGrid. Cada verificação acende onde acontece: a identidade do servidor de envio, a sessão SMTP que o nosso servidor viu, as assinaturas e o conteúdo da mensagem, e depois o SpamAssassin e as regras dos provedores de caixa de entrada.

Como o verificador de spam de email dá a nota da sua mensagem

Dez pontos, menos descontos que citam, cada um, a própria regra. Nada que não conseguimos verificar custa um ponto.

Uma nota só serve se dá para ver como foi feita, então a tabela inteira está aqui, gerada pelo mesmo código que dá a nota à sua mensagem. Cada desconto se apoia em uma RFC, na página de um provedor de caixa de correio ou em uma regra do SpamAssassin.

Regras só de email em massa, como o cancelamento de inscrição com um clique, descontam apenas quando a mensagem parece email em massa. O que uma só mensagem não consegue mostrar (taxas de reclamação, volume de envio) é “sem como saber” e não custa nada.

Um relatório inventado7,8

10 − 1,5 − 0,7 = 7,8

  1. 1Email em massa sem cancelamento de inscrição com um clique funcional (RFC 8058: os dois cabeçalhos, assinados por DKIM)
  2. 2SpamAssassin 3,4
O que encontramosPontos a menosParte
Nem o SPF passa nem alguma assinatura DKIM é verificada−3SPF
O DMARC falha: nenhum SPF ou DKIM alinhado passa, e o domínio do From publica uma política−2,5DMARC
O cabeçalho From não tem um único domínio ao qual o DMARC possa se aplicar−2DMARC
O domínio do From não publica registro DMARCsó email em massa−1DMARC
SPF fail: o registro diz que este servidor não pode enviar−1SPF
SPF softfail ou neutral−0,5SPF
Sem registro SPF para o domínio do MAIL FROM (ou do HELO)−1SPF
SPF permerror: um registro quebrado ou mais de 10 consultas DNS−1SPF
A mensagem não tem assinatura DKIMsó email em massa−1DKIM
Tem assinatura DKIM, mas todas falham (tratada como sem assinatura)só email em massa−1DKIM
Uma assinatura usa uma chave RSA com menos de 1 024 bits−1DKIM
O DKIM passa, mas nenhuma assinatura válida confere com o domínio do From−0,5DKIM
O endereço de envio está em uma lista de bloqueio importante−3Servidor de envio
O endereço de envio está em uma lista de bloqueio menor−1Servidor de envio
O endereço de envio não tem DNS reverso (PTR)−2,5Servidor de envio
O nome PTR não resolve de volta para o endereço de envio−1,5Servidor de envio
O HELO não é um nome de domínio completo−0,5Servidor de envio
O servidor enviou sem TLS−1,5Sessão SMTP
Fins de linha LF ou CR soltos na mensagem0um aviso, que não conta na nota (−0,5 quando uma fonte for citada)Sessão SMTP
O From está ausente, repetido, ilegível, ou lista várias caixas de correio sem Sender−2Formato
Date ausente ou ilegível−1Formato
Message-ID ausente ou malformado−1Formato
O Date está a mais de um dia do horário de chegada0um aviso, que não conta na nota (−0,5 quando uma fonte for citada)Formato
Um campo que só pode aparecer uma vez aparece duas−0,5Formato
Linhas com mais de 998 caracteres−0,25Formato
Imagens com quase nenhum texto0um aviso, que não conta na nota (−1 quando uma fonte for citada)Conteúdo
HTML sem versão em texto simples−0,5Conteúdo
HTML com mais de uns 102 KB: o Gmail pode cortá-lo0um aviso, que não conta na nota (−0,5 quando uma fonte for citada)Conteúdo
Links por encurtadores de URL0um aviso, que não conta na nota (−1 quando uma fonte for citada)Conteúdo
Links para um endereço IP direto0um aviso, que não conta na nota (−1 quando uma fonte for citada)Conteúdo
Links para um domínio que imita outro0um aviso, que não conta na nota (−2 quando uma fonte for citada)Conteúdo
Links javascript:, data: ou file:0um aviso, que não conta na nota (−2 quando uma fonte for citada)Conteúdo
O texto do link mostra um domínio e o link vai para outro0um aviso, que não conta na nota (−0,5 quando uma fonte for citada)Conteúdo
Um tipo de anexo que o Gmail bloqueia0um aviso, que não conta na nota (−2 quando uma fonte for citada)Conteúdo
Links para um host que o resolvedor de segurança da Cloudflare bloqueia (malware ou phishing)0um aviso, que não conta na nota (−2 quando uma fonte for citada)Conteúdo
Scripts, iframes, formulários ou objetos incorporados no HTML−1Conteúdo
1Email em massa sem cancelamento de inscrição com um clique funcional (RFC 8058: os dois cabeçalhos, assinados por DKIM)−1,5Cancelar inscrição
2Os pontos do SpamAssassin acima de 2,0metade dos pontos acima de 2,0, no máximo 3SpamAssassin
A nota do SpamAssassin chega ao limite de spam−2SpamAssassin
Não verificado, ou impossível saber com uma só mensagem0–
A tabela que a nota usa (versão 2026-10-31.1): 10 menos cada linha que vale, nunca abaixo de 0. Uma parte que não conseguimos verificar não desconta nada; as linhas de email em massa custam pontos só em email em massa; uma linha em 0 é um aviso que mostramos mas não contamos na nota.

Alinhamento de SPF, DKIM e DMARC em uma só imagem

O DMARC passa quando o SPF ou o DKIM passa para um domínio que confere com o endereço From que as pessoas veem.

Um email tem dois remetentes: o remetente oculto do envelope, para onde vão os emails devolvidos, e o endereço From que as pessoas leem. O SPF verifica o primeiro, o DKIM verifica uma assinatura, e o DMARC liga qualquer um dos dois ao segundo (RFC 9989).

Serviços de email costumam passar o DMARC pelo DKIM: assinam com o seu domínio (um registro que você adiciona) enquanto os emails devolvidos vão para um subdomínio deles.

Return-Path: bounces+48213-9f1c@em.example.orgo remetente do envelope (MAIL FROM): o SPF verifica este
DKIM-Signature: v=1; a=rsa-sha256; d=example.org; s=s1; …uma assinatura do domínio do From
DKIM-Signature: v=1; a=rsa-sha256; d=sendgrid.info; s=smtpapi; …a assinatura do próprio serviço de email
From: Example Weekly <news@example.org>o que o leitor vê: o DMARC protege este
  1. SPF pass198.51.100.24 pode enviar por em.example.orgalinhado: em.example.org pertence a example.org
  2. DKIM passa assinatura de example.org é verificadaalinhado: o mesmo domínio
  3. DKIM passa assinatura de sendgrid.info é verificadanão alinhado: outro domínio (tudo bem)
  4. DMARC passFrom example.org: pelo menos um pass está alinhadopolítica p=none · alinhamento relaxado
O SPF verifica o remetente oculto do envelope, o DKIM verifica uma assinatura, e o DMARC pergunta se algum dos dois pertence ao domínio do From que as pessoas veem. O alinhamento relaxado compara domínios organizacionais (em.example.org e example.org conferem); o estrito compara os nomes exatos.

Requisitos de remetente do Gmail, do Yahoo e do Outlook.com

Desde 2024 os maiores provedores de caixa de entrada publicam o que exigem. Aqui estão lado a lado.

Todo remetente precisa de SPF ou DKIM, DNS reverso funcionando e uma mensagem bem formada. Remetentes em massa também precisam de SPF e DKIM juntos, um registro DMARC alinhado com o endereço From, cancelamento de inscrição com um clique e uma taxa de reclamação baixa.

O nosso relatório verifica toda regra que uma mensagem consegue mostrar e diz “sem como saber” para o resto: as taxas de reclamação ficam no Google Postmaster Tools e no Sender Hub do Yahoo.

GmailYahooOutlook.com
Todos os remetentesRemetentes em massa5 000+ por diaTodos os remetentesRemetentes em massasem número informadoRemetentes em massa5 000+ por dia
SPF ou DKIM passa4.7.27 · 4.7.30–––
SPF e DKIM passam os dois4.7.27 · 4.7.30–––
SPF passa––––1
DKIM passa––––1
Um registro DMARC, p=none ou mais rígido4.7.40 · 5.7.40–––
From alinhado com SPF ou DKIM (o DMARC passa)4.7.32 · 5.7.32––1
DNS direto e reverso (PTR)4.7.23–––
TLS na conexão4.7.29––––
Formato de mensagem RFC 53222–––
Sem From: do Gmail vindo de outro lugar––––
Um endereço From ou Reply-To válido––––
Cancelamento de inscrição com um clique (RFC 8058)–––
List-Unsubscribe (mailto ou https)––––
Um link visível para cancelar a inscrição no corpo––
Reclamações de spam abaixo de 0,3%–––

obrigatóriarecomendada– não está nas regras desse provedor4.7.23o código com que o Gmail responde quando faltauma só mensagem não consegue mostrar: dizemos “sem como saber”

1 550 5.7.5152 O Gmail também pede um único endereço no From.

Gmail e Yahoo desde fevereiro de 2024 (o Gmail aplicando com mais rigor desde novembro de 2025), Outlook.com desde 5 de maio de 2025, rejeitando com 550 5.7.515. O relatório verifica cada linha que uma mensagem consegue mostrar.

Privacidade: o que guardamos e o que o servidor de email vê

O endereço que você verifica não é guardado: a resposta dele é, por até um dia, sob um hash com chave e sem o endereço. O corpo de uma mensagem de teste é excluído logo depois da análise.

Verificar um endereço envia ao servidor de email dele alguns comandos curtos e nada mais: EHLO, MAIL FROM:<>, RCPT TO para o endereço e para um endereço inventado (e mais uma vez para o Outlook.com), RSET, QUIT. O servidor vê o nome do nosso servidor, um remetente vazio e os endereços consultados: não você, nem uma mensagem.

Um relatório de teste guarda os cabeçalhos da mensagem, os links dela e uma prévia de 140 caracteres, com os achados, por 7 dias para que você possa compartilhar o link; o corpo completo e os anexos são excluídos logo depois da análise. Você pode excluir o relatório a qualquer momento, pelo próprio relatório.

Verificar um endereço
  1. Você digitaVai para o nosso servidor por HTTPS, só na requisição.
  2. O servidor de email vêEHLO probe.dnsrobot.net · MAIL FROM:<> · RCPT TO:<…> · RSET · MAIL FROM:<> · RCPT TO:<…> · QUITEstes poucos comandos e nada mais: o nome do nosso servidor, um remetente vazio, RCPT TO para o endereço e para um endereço inventado (e mais uma vez para o Outlook.com). Nenhuma mensagem, nenhum nome, nada sobre você.
  3. GuardamosO endereço não. Os logs guardam o domínio e o código de resposta; uma resposta definitiva fica guardada por até um dia sob um hash com chave, sem o endereço.
Teste seu email
  1. A mensagem em siO corpo e os anexos são excluídos logo depois da análise. O SpamAssassin a lê na memória do nosso servidor de email; nada é registrado.
  2. O relatórioOs cabeçalhos, os domínios para os quais a mensagem tem links (com um link de exemplo de cada um) e uma prévia de 140 caracteres: 7 dias, ou até você apertar Excluir relatório. Qualquer pessoa com o link dele pode abri-lo.
  3. Nuncaa encaminhamos, nem respondemos a ela, nem a lemos à mão.
Verificar um endereço é tratar dados pessoais segundo o GDPR mesmo que nada seja guardado, então guardamos o mínimo possível. A Spamhaus pede que os verificadores não ofereçam limpeza de listas: listas em massa não recebem verificação de caixa de correio.

Perguntas frequentes

Este verificador de email é grátis?

Sim, sem cadastro. Você pode verificar endereços avulsos (alguns por minuto), conferir listas de até 100 endereços e fazer testes de entregabilidade de email. Os limites existem porque cada verificação chega a um servidor de email de verdade: os servidores bloqueiam verificadores que perguntam com frequência demais, e isso deixaria a ferramenta fora do ar para todo mundo.

Como saber se um email existe sem enviar um email?

Digite o endereço acima. Buscamos os servidores de email do domínio, nos conectamos ao primeiro e perguntamos se ele aceitaria email para o endereço (RCPT TO). Depois perguntamos sobre um endereço inventado do mesmo domínio, para saber se o servidor os distingue, e desligamos antes de qualquer mensagem ser enviada.

Qual a precisão de um validador de email, e um endereço válido ainda pode voltar?

Tão preciso quanto o provedor de email permite. Gmail, iCloud e a maioria dos provedores de email pessoal respondem com clareza; em domínios que aceitam tudo e em provedores que recusam verificações, ninguém consegue confirmar. Uma caixa de correio cheia, ou uma mudança depois da verificação, ainda pode fazer um endereço válido voltar. Mostramos em qual caso você está, em vez de uma porcentagem inventada.

A pessoa vai saber que eu verifiquei o email dela?

Não. Nada chega à caixa de entrada dela, porque a conversa para antes de uma mensagem ser enviada. O servidor do provedor registra uma conexão do nosso servidor de verificação, como faz com todo remetente que bate à porta, mas não avisa o dono da caixa de correio, e não enviamos nada que ele possa ver.

Por que um endereço do Gmail, do Yahoo ou do Outlook.com dá este resultado?

O Gmail confere cada endereço, então as respostas dele são confiáveis. O Outlook.com às vezes diz sim uma vez a um endereço inventado, então perguntamos duas vezes e só confiamos nas respostas que coincidem. O Yahoo recusa servidores cujo DNS reverso não confere, o nosso incluído por enquanto, então endereços do Yahoo voltam como Desconhecido. A própria lista de erros do Yahoo também mostra que mensagens para contas desconhecidas voltaram depois de enviadas.

O que é um endereço de email catch-all (que aceita tudo)?

É um endereço de um domínio cujo servidor de email aceita email para todo endereço, exista ou não, e resolve depois. Uma verificação não distingue ali uma caixa de correio de verdade de uma inventada, então o resultado é Aceita tudo. Envie só se você recebeu o endereço da pessoa, e fique de olho nos emails devolvidos.

Por que o resultado da minha verificação de email é Desconhecido?

O servidor de email não respondeu sobre o endereço. Ele aplicou greylisting ao nosso servidor de verificação (tente de novo em um minuto), o recusou por uma regra sobre servidores, não respondeu a tempo, ou é de um provedor que pede para não ser verificado. Desconhecido nunca é um não: um endereço que lhe passaram provavelmente está certo.

Como testar a entregabilidade e a nota de spam do meu email?

Abra “Teste seu email” acima e copie o endereço de uso único. Envie para ele a sua mensagem de verdade, da mesma conta e do mesmo serviço que você usa normalmente. O relatório se monta conforme cada parte é verificada: o servidor de envio, SPF, DKIM, DMARC, o conteúdo, os cabeçalhos de cancelamento de inscrição, o SpamAssassin e as regras do Gmail, do Yahoo e do Outlook.com, com uma nota de 10.

Um 10/10 em um mail tester significa que meu email cai na caixa de entrada?

Nenhum teste pode prometer isso. Chegar à caixa de entrada também depende do seu histórico de envio e de quantas vezes as pessoas marcam seus emails como spam, algo que só os provedores de caixa de correio veem. Um 10/10 significa que nada do que conseguimos verificar em uma mensagem está errado. Não temos caixas de correio de teste, então nunca afirmamos medir a chegada à caixa de entrada.

Vocês guardam os endereços que eu verifico ou os emails que eu envio?

Os endereços não: nossos logs guardam o domínio e o código de resposta do servidor de email, e uma resposta definitiva fica guardada por até um dia sob um hash com chave, sem o endereço. O corpo completo e os anexos de uma mensagem de teste são excluídos logo depois da análise. O relatório dela guarda os cabeçalhos, os links e uma prévia de 140 caracteres por 7 dias, ou até você apertar Excluir relatório.

O que significa “verificar email”, em comparação com validar?

Validar confere a forma do endereço e o domínio dele: a sintaxe e se o domínio tem servidores de email. Verificar também pergunta ao servidor de email sobre a própria caixa de correio. Este verificador de email faz as duas coisas com endereços avulsos; o modo em massa valida cada linha e deixa você verificar a caixa de correio de qualquer uma quando precisar.

Posso verificar uma lista de endereços de email?

Sim, até 100 de uma vez, colados ou de um arquivo CSV, e você pode baixar os resultados em CSV. Cada linha recebe sintaxe, domínio, servidores de email e listas. As caixas de correio são verificadas uma de cada vez, quando você escolhe, porque perguntar a cem servidores de email de uma vez é limpeza de lista, que os servidores de email bloqueiam.

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

Ferramentas relacionadas