1. A Parte Local (Nome de Usuário)

A parte local aparece antes do símbolo @ e identifica a caixa de correio específica em um domínio. De acordo com a RFC 5322, a parte local pode conter:

Caracteres permitidos:

• Letras maiúsculas e minúsculas (A-Z, a-z)
• Dígitos (0-9)
• Caracteres especiais: ! # $ % & ‘ * + – / = ? ^ _ ` { | } ~
• Ponto (.) mas NÃO no início, fim ou consecutivamente

Regras principais:

• Comprimento máximo: 64 caracteres
• Sensível a maiúsculas/minúsculas em teoria, embora a maioria dos servidores de e-mail os trate como insensíveis
• Strings entre aspas permitem caracteres adicionais: `”joao..silva”@exemplo.com`

Exemplos válidos comuns:

• `joao.silva` (letras e ponto)
• `usuario+tag` (sinal de mais para filtragem)
• `admin_2024` (sublinhado e dígitos)
• `primeiro-ultimo` (hífen)

Erros comuns a evitar:

• Começar ou terminar com ponto: `.joao@` ou `joao.@`
• Pontos consecutivos: `joao..silva@`
• Espaços sem aspas: `joao silva@`
• Apenas caracteres especiais: `@@@@@@@`

2. O Símbolo @

O símbolo @ (arroba) serve como o separador obrigatório entre a parte local e o nome de domínio. Cada endereço de e-mail válido contém exatamente um símbolo @ (a menos que esteja dentro de uma string entre aspas).

Regras críticas:

• Exatamente um @ é necessário
• Não pode aparecer no início ou no fim
• Não pode ser escapado ou substituído

A posição do símbolo @ determina onde a parte local termina e o nome de domínio começa. Os sistemas de validação de e-mail primeiro localizam o símbolo @ e, em seguida, validam separadamente as partes antes e depois dele.

3. O Nome de Domínio

O nome de domínio segue o símbolo @ e identifica o servidor de e-mail que recebe mensagens para este endereço. Os nomes de domínio devem cumprir os padrões do DNS (Domain Name System).

Requisitos de estrutura de domínio:

• Contém um ou mais rótulos (labels) separados por pontos
• Cada rótulo: 1-63 caracteres
• Comprimento total do domínio: máximo de 253 caracteres
• Deve ter registros MX ou registros A válidos para entrega de e-mail

Caracteres permitidos em nomes de domínio:

• Letras (A-Z, a-z)
• Dígitos (0-9)
• Hífens (-) mas NÃO no início ou fim dos rótulos

Exemplos de domínios válidos:

• `exemplo.com` (domínio básico)
• `mail.empresa.co.uk` (subdomínio com código de país)
• `servidor-01.interno.org` (hífens e dígitos)

Exemplos de domínios inválidos:

• `-exemplo.com` (começa com hífen)
• `exemplo-.com` (rótulo termina com hífen)
• `exemplo` (sem TLD)
• `exemplo..com` (pontos consecutivos)

Para que um e-mail realmente receba mensagens, o domínio deve ter registros MX adequados configurados no DNS. Esses registros informam aos servidores de envio quais servidores de e-mail gerenciam o e-mail para esse domínio.

4. O Domínio de Nível Superior (TLD)

O TLD é o segmento final do nome de domínio após o último ponto. Os TLDs se enquadram em várias categorias:

TLDs Genéricos (gTLDs):

• Originais: .com, .org, .net, .edu, .gov
• Novos gTLDs: .app, .dev, .io, .tech, .shop (mais de 1000 disponíveis)

TLDs de Código de País (ccTLDs):

• Códigos de duas letras: .uk, .de, .jp, .au, .ca
• Frequentemente usados localmente, mas acessíveis globalmente

Requisitos de TLDs válidos:

• Mínimo de 2 caracteres (historicamente)
• Novos gTLDs podem ser mais longos: .technology, .international
• Deve ser registrado na IANA
• Não pode conter apenas dígitos (na maioria dos contextos)

A validação moderna deve aceitar qualquer TLD registrado na IANA em vez de manter uma lista codificada, pois novos TLDs são introduzidos regularmente.

Endereços de E-mail Válidos

Endereços de E-mail Inválidos

Distinção importante: Estes exemplos mostram validade de sintaxe. Um endereço pode ser sintaticamente válido, mas ainda assim falhar em receber e-mails se o domínio não existir ou não tiver servidores de e-mail.

Validação de E-mail (Verificação de Sintaxe)

O que é: Verificar se um endereço de e-mail segue as regras de formato adequadas sem contatar nenhum servidor.

O que verifica:

• Estrutura correta ([email protected])
• Apenas caracteres permitidos
• Posição correta do ponto
• Limites de comprimento
• Formato básico do domínio

Métodos:

• Correspondência de padrões Regex
• Analisadores de formato
• Validação JavaScript no lado do cliente
• Verificação de sintaxe no lado do servidor

Velocidade: Instantânea (milissegundos)

Resultado: “Este endereço está formatado corretamente” ou “Este endereço viola as regras de formato”

Limitação: Não pode determinar se o endereço realmente existe ou recebe e-mail.

Verificação de E-mail (Verificação de Existência)

O que é: Confirmar que um endereço de e-mail realmente existe e pode receber mensagens.

O que verifica:

• Domínio tem registros MX válidos
• Servidor de e-mail responde
• Caixa de correio existe (quando possível)
• Não é um endereço descartável/temporário conhecido
• Não está em listas de bloqueio

Métodos:

• Consultas de registros MX do DNS
• Conexões com servidor SMTP
• Protocolos de verificação de caixa de correio
• Verificações de banco de dados de entregabilidade

Velocidade: Mais lenta (1-5 segundos por endereço)

Resultado: “Entregável”, “Não entregável”, “Desconhecido” ou “Arriscado”

Limitação: Alguns servidores de e-mail bloqueiam tentativas de verificação; os resultados nem sempre são 100% precisos.

Por Que Você Precisa de Ambos

Sistemas de e-mail inteligentes usam primeiro a validação (rápida, elimina erros óbvios) seguida pela verificação para endereços que passam nas verificações de sintaxe. Essa abordagem de duas etapas:

• Previne erros de digitação na submissão do formulário (validação)
• Reduz a taxa de rejeição (verificação)
• Mantém a higiene da lista (verificação)
• Melhora a reputação do remetente (ambos)
• Aumenta a entregabilidade (ambos)

Para empresas que coletam endereços de e-mail, implementar ambos os processos através de ferramentas de verificação e validação de e-mail melhora significativamente a qualidade dos dados.

1. Validação de Formulário Excessivamente Restritiva

Problema: Muitos sites usam regras de validação desatualizadas que rejeitam endereços legítimos.

Restrições comuns:

• Bloqueio de sinais de mais (+) usados para filtragem de e-mail
• Rejeição de novos TLDs como .io, .app ou .dev
• Exigência de pelo menos um ponto na parte local
• Bloqueio de sublinhados ou hífens

Solução: Atualize os padrões regex de validação para aceitar todos os formatos compatíveis com RFC. Use um analisador de sintaxe de e-mail abrangente em vez de regex excessivamente simplificado.

2. Filtragem de Caracteres Especiais

Problema: Formulários com foco em segurança às vezes bloqueiam caracteres especiais que são legítimos em endereços de e-mail.

Comumente rejeitados:

• `[email protected]` (filtragem de sinal de mais)
• `usuario%[email protected]` (porcentagem)
• `[email protected]` (sublinhado, raramente)

Solução: Distinga entre validação de e-mail e sanitização geral de entrada. Endereços de e-mail precisam de suas próprias regras de validação especializadas.

3. Restrições de TLD

Problema: Formulários que mantêm listas de TLD codificadas rejeitam domínios de nível superior recém-introduzidos ou menos comuns.

Exemplos rejeitados:

• `[email protected]`
• `[email protected]`
• `[email protected]`

Solução: Aceite qualquer domínio com uma estrutura de TLD válida em vez de manter uma lista de permissões. Verifique a validade do TLD através de consulta de domínio em vez de correspondência de padrões.

4. Limitações de Comprimento

Problema: Campos de banco de dados ou formulários com limites de comprimento arbitrários rejeitam endereços válidos mais longos.

Problema: Definir um máximo de 50 caracteres rejeita endereços como:

• `[email protected]` (55 caracteres)

Solução: Suporte o máximo de 320 caracteres (64 local + @ + 255 domínio). Campos de banco de dados devem usar VARCHAR(320) ou equivalente.

5. Padrões Regex Incorretos

Problema: Padrões regex simplificados perdem casos extremos ou rejeitam formatos válidos.

Problemas comuns de regex:

• Exigir pelo menos um ponto: `^[^@]+@[^@]+\.[^@]+$` (muito simples)
• Bloquear pontos consecutivos em strings entre aspas
• Não lidar corretamente com subdomínios
• Definições incorretas de classes de caracteres

Solução: Use bibliotecas de validação de e-mail estabelecidas e compatíveis com RFC em vez de escrever regex personalizados. Para referência, um padrão regex totalmente compatível abrange centenas de caracteres.

6. Tratamento de Unicode/Caracteres Internacionais

Problema: Formulários que não suportam endereços de e-mail internacionalizados rejeitam endereços com caracteres não ASCII.

Exemplos:

• `mü[email protected]`
• `用户@dominio.cn`

Solução: Implemente suporte à RFC 6531 ou comunique claramente as limitações apenas ASCII aos usuários.

Solução Prática para Usuários

Quando seu e-mail válido for rejeitado:

1. Tente sem endereçamento com sinal de mais: Mude `[email protected]` para `[email protected]`
2. Use um TLD mais comum: Se possível, tente um endereço .com ou .net
3. Remova caracteres especiais: Use apenas letras, dígitos e pontos
4. Verifique erros de digitação: Pontos consecutivos, pontos no início/fim, @ faltando
5. Entre em contato com o suporte: Relate o problema de validação ao site

Métodos Manuais

1. Verificação Visual de Sintaxe

Examine o endereço em busca de erros óbvios:

• Um símbolo @ presente?
• Caracteres antes e depois do @?
• Domínio tem pelo menos um ponto?
• Sem espaços ou caracteres obviamente inválidos?

Útil para verificações rápidas, mas propenso a erros para problemas sutis.

2. Enviar E-mail de Teste

O teste definitivo: envie uma mensagem e confirme o recebimento.

Processo:

• Envie um e-mail para o endereço
• Inclua um link ou código de confirmação
• Aguarde a ação do destinatário
• Confirme a entregabilidade

Prós: 100% preciso para entregabilidade real
Contras: Lento, requer cooperação do destinatário, risco de reclamações de spam

3. Truque de Recuperação de Senha

Verificação indireta inteligente:

• Acesse um serviço que a pessoa provavelmente usa (Gmail, LinkedIn, etc.)
• Insira o e-mail no fluxo “Esqueci a senha”
• O sistema indica “E-mail enviado” ou “E-mail não encontrado”

Observação: Isso só funciona quando os serviços revelam se um e-mail existe em seu banco de dados. Muitos agora retornam mensagens genéricas por segurança.

Métodos Automatizados

1. Validação por Padrão Regex

Expressões regulares verificam a sintaxe sem chamadas externas.

Padrão básico (simplificado):

“`regex

^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$

“`

Padrão mais abrangente (ainda simplificado):

“`regex

^[a-zA-Z0-9!#$%&’+/=?^_`{|}~-]+(?:\.[a-zA-Z0-9!#$%&’+/=?^_`{|}~-]+)@(?:[a-zA-Z0-9](?:[a-zA-Z0-9-][a-zA-Z0-9])?\.)+[a-zA-Z0-9](?:[a-zA-Z0-9-]*[a-zA-Z0-9])?$

“`

Prós: Rápido, funciona offline, sem dependências externas
Contras: Padrões complexos difíceis de manter, não pode verificar a entregabilidade, casos extremos complicados

Melhor prática: Use bibliotecas estabelecidas em vez de escrever padrões regex personalizados.

2. Serviços de API

APIs de verificação de e-mail verificam tanto a sintaxe quanto a entregabilidade.

Serviços populares:

• ZeroBounce
• NeverBounce
• Kickbox
• Clearout
• EmailListVerify

Recursos típicos da API:

• Validação de sintaxe
• Verificação de domínio
• Verificação de registros MX
• Detecção de e-mail descartável
• Identificação de armadilhas de spam
• Verificação de existência de caixa de correio

Prós: Verificações abrangentes, alta precisão, rápido (1-3 segundos)
Contras: Custa dinheiro em escala, requer conexão com a internet

3. Widgets de Validação em Tempo Real

Bibliotecas JavaScript que validam enquanto o usuário digita.

Recursos:

• Feedback de sintaxe instantâneo
• Detecção de erro de digitação no domínio (“gmial.com” → “gmail.com”)
• Avisos de e-mail descartável
• Indicadores visuais (check/X)

Bibliotecas populares:

• Mailcheck.js (detecção de erro de digitação)
• Email-validator (apenas sintaxe)
• Validator.js (inclui validação de e-mail)

Prós: Ótima UX, previne erros antes da submissão
Contras: Apenas sintaxe (sem verificação de entregabilidade), limitações do lado do cliente

4. Ferramentas de Verificação em Massa

Para validar grandes listas de e-mail (milhares a milhões).

Processo:

1. Carregue um arquivo CSV/texto de endereços
2. O sistema processa em paralelo
3. Baixe os resultados com o status de verificação

Resultados geralmente incluem:

• Status Válido/Inválido
• Pontuação de entregabilidade
• Nível de risco (seguro/arriscado/desconhecido)
• Motivo da invalidade

Casos de uso:

• Manutenção da higiene da lista de e-mail
• Limpeza de lista pré-campanha
• Deduplicação de banco de dados
• Validação de importação

A verificação em massa é essencial para manter a higiene da lista de e-mail e garantir altas taxas de entregabilidade.

Para Empresas

1. Aceite Todos os Formatos Válidos

Não rejeite endereços de e-mail apenas porque são incomuns:

• Permita o endereçamento com sinal de mais (`[email protected]`)
• Aceite todos os TLDs válidos
• Suporte a subdomínios
• Permita pontos, hífens, sublinhados de acordo com as regras RFC

Implementação: Use uma biblioteca de validação abrangente que siga os padrões RFC 5322 em vez de regex personalizados.

2. UX de Validação em Tempo Real

Forneça feedback imediato sem frustrar os usuários:

Boas práticas:

• Valide enquanto o usuário digita (com um pequeno atraso)
• Mostre mensagens de erro claras explicando os problemas
• Sugira correções para erros de digitação comuns
• Use indicadores visuais (cores, ícones)
• Não bloqueie a submissão por atrasos na verificação

Más práticas:

• Validação apenas após a submissão do formulário
• Erros genéricos: “E-mail inválido”
• Bloqueio do endereçamento com sinal de mais sem explicação
• Falsos positivos rejeitando endereços válidos

3. Implementação de Confirmação Dupla (Double Opt-In)

Confirme se os endereços de e-mail realmente pertencem aos usuários:

Processo:

1. Usuário envia o e-mail
2. Sistema envia e-mail de confirmação
3. Usuário clica no link de confirmação
4. Endereço marcado como verificado

Benefícios:

• Previne que erros de digitação cheguem ao seu banco de dados
• Confirma a entregabilidade
• Reduz reclamações de spam
• Melhora as métricas de engajamento
• Conformidade legal (consentimento GDPR)

4. Mantenha a Higiene da Lista

Limpe regularmente seu banco de dados de e-mail:

Ações:

• Remova hard bounces imediatamente
• Marque endereços com múltiplos soft bounces
• Identifique e segmente usuários inativos
• Reverifique endereços antigos periodicamente
• Remova endereços de função (role-based) quando apropriado

Frequência: Revise a lista completa a cada 6-12 meses; contatos críticos trimestralmente.

Para Usuários

1. Escolha Endereços Memoráveis

Seu e-mail serve como sua identidade online:

Dicas:

• Use o formato nome.sobrenome para contextos profissionais
• Mantenha-o simples para compartilhamento verbal
• Evite números excessivos ou caracteres especiais
• Considere a longevidade (endereços escolares expiram)

2. Considerações de Segurança

Melhores práticas:

• Use e-mail único para contas financeiras
• Considere endereços separados para compras/newsletters
• Não compartilhe e-mail publicamente (bots de coleta)
• Ative a autenticação de dois fatores
• Use aliases de e-mail quando preocupado com privacidade

3. Endereçamento com Sinal de Mais para Filtragem

Gmail e a maioria dos provedores suportam endereçamento com sinal de mais:

Formato: `[email protected]`

Casos de uso:

• `[email protected]` (filtrar por etiqueta)
• `[email protected]` (fácil de cancelar inscrição)
• `[email protected]` (rastrear quem compartilha/vende dados)

Todas as variantes entregam em `[email protected]`, mas permitem regras de filtragem automáticas.

4. Gerenciando Múltiplos Endereços

Abordagem estratégica de múltiplos endereços:

Estrutura:

• Profissional: [email protected]
• Pessoal: [email protected]
• Compras: [email protected]
• Testes: serviços descartáveis para sites não confiáveis

Use clientes de e-mail ou encaminhamento para gerenciar múltiplos endereços de uma única caixa de entrada.

Endereços de E-mail Internacionalizados

A RFC 6531 (2012) introduziu suporte a Unicode em endereços de e-mail, permitindo caracteres não ASCII tanto na parte local quanto no domínio.

Exemplos:

• `用户@例え.jp` (Chinês/Japonês)
• `Dörte@Sörensen.com` (Umlauts alemães)
• `χρήστης@παράδειγμα.gr` (Grego)
• `अजय@डाटा.भारत` (Hindi)

Status atual:

• Suporte: Crescente, mas inconsistente
• Principais provedores: Gmail, Outlook suportam recebimento; envio varia
• Desafios: Compatibilidade com sistemas legados, limitações de DNS

Recomendação: Endereços ASCII permanecem mais universalmente compatíveis. Endereços internacionalizados funcionam melhor dentro de sistemas regionais que compartilham conjuntos de caracteres/idiomas.

Sub-endereçamento e Filtragem

Além do endereçamento com sinal de mais (+), alguns sistemas suportam outros delimitadores:

Variações:

• Mais: `[email protected]` (Gmail, Outlook, a maioria dos provedores)
• Hífen: `[email protected]` (Yahoo, alguns provedores)
• Sublinhado: Às vezes funciona, mas não é padronizado

Filtragem avançada:

1. Crie sub-endereços para diferentes finalidades
2. Configure filtros/regras automáticas
3. Rastreie quais serviços compartilham seu e-mail
4. Identifique facilmente fontes de spam
5. Exclua em massa por filtro

Limitação: Spammers sofisticados removem o endereçamento com sinal de mais antes de vender listas.

Endereços de E-mail Descartáveis

Serviços de e-mail temporários fornecem endereços de curta duração para situações que exigem e-mail sem compromisso.

Serviços populares:

• 10 Minute Mail
• Guerrilla Mail
• Temp Mail
• Mailinator

Casos de uso válidos:

• Testar funcionalidade de e-mail
• Evitar spam em sites não confiáveis
• Downloads únicos que exigem registro
• Proteger a privacidade para serviços não críticos

Considerações para empresas:

E-mails descartáveis são sintaticamente válidos, mas representam leads de baixa qualidade. Muitos serviços de verificação sinalizam domínios descartáveis, permitindo que as empresas:

• Bloqueiem descartáveis no cadastro
• Exijam e-mail alternativo para contas importantes
• Segmentem descartáveis para tratamento diferente

Endereços Baseados em Função (Role-Based)

Endereços baseados em função representam funções em vez de indivíduos:

Exemplos comuns:

• `[email protected]`
• `[email protected]`
• `[email protected]`
• `[email protected]`
• `[email protected]`

Características:

• Caixas de correio frequentemente compartilhadas
• Taxas de engajamento mais baixas
• Necessários para operações comerciais
• Sujeitos a regras anti-spam diferentes

Perspectiva empresarial:

Algumas regulamentações de marketing por e-mail desencorajam o envio de conteúdo promocional para endereços baseados em função sem opt-in explícito.

Domínios Catch-All

Configurações catch-all aceitam e-mails para QUALQUER endereço em um domínio, mesmo os inexistentes.

Como funciona:

• Domínio configurado para aceitar todo o e-mail: `*@exemplo.com`
• `[email protected]` → entregue à caixa de correio catch-all
• Frequentemente usado por pequenas empresas para nunca perder e-mails

Desafio de verificação:

Catch-alls sempre relatam endereços como “válidos” durante a verificação, pois o servidor aceita todos os destinatários. Serviços de verificação geralmente sinalizam esses como status “desconhecido”, pois a entregabilidade real não pode ser confirmada.

Erros “Endereço de e-mail não é válido”

Quando você vê isso:

Seu e-mail rejeitado, apesar de você saber que ele funciona.

Soluções:

1. Verifique erros de digitação (pontos consecutivos, @ faltando, espaços finais)
2. Remova temporariamente o endereçamento com sinal de mais
3. Tente um e-mail alternativo se estiver usando um TLD incomum
4. Entre em contato com o suporte do site citando a conformidade com a RFC 5322
5. Use um e-mail diferente como solução alternativa

Se você é um desenvolvedor:

Revise a validação regex em relação aos padrões RFC 5322. Considere usar bibliotecas estabelecidas como `validator.js` ou `email-validator` em vez de padrões personalizados.

Por Que o Gmail Ignora Pontos

Pergunta: Por que `[email protected]` e `[email protected]` entregam na mesma caixa de correio?

Resposta: O Gmail intencionalmente ignora pontos na parte local para usabilidade. Todos estes chegam à mesma caixa de entrada:

• `[email protected]`
• `[email protected]`
• `[email protected]`

Implicação: Você pode fornecer diferentes “versões” do seu endereço e filtrar por campo de destinatário, mas isso não é um recurso de segurança — todos chegam ao mesmo lugar.

Sinal de Mais Não Funciona

Problema: Usando `[email protected]`, mas é rejeitado ou não filtra corretamente.

Causas:

1. Site bloqueia sinais de mais: Comum, mas não compatível com RFC
2. Seu provedor não o suporta: Menos comum; Gmail/Outlook suportam
3. Filtro não configurado: É necessário criar regras de filtro manualmente

Soluções:

• Solução alternativa: Use hífen se o provedor suportar
• Entre em contato com o site para corrigir a validação
• Crie manualmente um filtro para e-mails recebidos

Problemas com Caracteres Internacionais

Problema: Caracteres acentuados ou não latinos rejeitados.

Realidade:

• RFC 6531 suporta caracteres internacionais
• Muitos sistemas não implementaram suporte
• ASCII permanece o mais compatível

Soluções:

• Use o equivalente ASCII se disponível
• Pergunte ao provedor sobre suporte internacional
• Use um e-mail diferente para serviços que exigem ASCII
• Relate a limitação ao provedor de serviços

“Este e-mail já existe”

Problema: Não é possível se inscrever porque o e-mail já está registrado.

Causas possíveis:

1. Você tem uma conta antiga esquecida
2. Alguém digitou incorretamente seu e-mail (o seu)
3. Vazamento de dados levou a contas pré-registradas
4. Variante de endereçamento com sinal de mais já em uso

Soluções:

• Use a recuperação de senha para recuperar o acesso
• Tente uma variante de endereçamento com sinal de mais: `[email protected]`
• Entre em contato com o suporte para verificar/remover conta antiga
• Use um endereço de e-mail diferente

E-mail funciona, mas a verificação falha

Problema: Você recebe e-mails normalmente, mas as ferramentas de verificação relatam “inválido”.

Causas:

1. Problemas temporários no servidor: Registros MX temporariamente inacessíveis
2. Bloqueio de verificação: Servidor de e-mail bloqueia tentativas de verificação
3. Domínio catch-all: Servidor aceita todos os endereços, verificação incerta
4. Greylisting: Rejeição temporária que requer nova tentativa

Soluções:

• Tente verificar novamente após 24 horas
• Verifique a entregabilidade enviando um e-mail de teste
• Verifique os registros MX do DNS diretamente
• Aceite a incerteza da verificação para domínios catch-all

Serviços de Validação Recomendados

Para Validação em Tempo Real:

• Abstract API – API simples, sintaxe + entregabilidade
• Clearout – Widget em tempo real + API
• Kickbox – Detecção de descartáveis + verificação

Para Verificação em Massa:

• ZeroBounce – Limpeza de lista de e-mail + pontuação
• NeverBounce – Verificação de lista de alto volume
• BriteVerify – Opções em tempo real + em massa

Validadores Gratuitos para Testar

Ferramentas Apenas de Sintaxe:

• Email Regex Tester (regex101.com)
• Email Format Validator (freeformatter.com)
• Quick Email Verification (quickemailverification.com – plano gratuito limitado)

Verificação de E-mail Único:

• Email Checker (email-checker.net)
• Verify Email Address (verifalia.com – plano gratuito)
• Mail Tester (mail-tester.com)

Recursos para Desenvolvedores

Bibliotecas de Validação:

JavaScript:

“`javascript

// Usando validator.js

import validator from ‘validator’;

validator.isEmail(‘[email protected]’); // true

“`

Python:

“`python

Usando email-validator

from email_validator import validate_email, EmailNotValidError

try:

v = validate_email(“[email protected]”)

email = v[“email”] # forma normalizada

except EmailNotValidError as e:

print(str(e))

“`

PHP:

“`php

// Usando filtro nativo

if (filter_var($email, FILTER_VALIDATE_EMAIL)) {

// Sintaxe válida

}

“`

Ruby:

“`ruby

Usando a gem valid_email2

require ‘valid_email2’

ValidEmail2::Address.new(“[email protected]”).valid? # true

“`

Documentação RFC

RFCs principais:

• RFC 5321 – Simple Mail Transfer Protocol (SMTP)
• RFC 5322 – Internet Message Format (sintaxe de endereço de e-mail)
• RFC 6531 – Internationalized Email
• RFC 3696 – Application Techniques for Checking and Transformation

Acesso: Pesquise “[número RFC] ietf.org” ou visite tools.ietf.org/html/rfcXXXX

O que torna um endereço de e-mail inválido?

Um endereço de e-mail é inválido se violar as regras de formato da RFC 5322: símbolo @ ausente, sem parte local ou domínio, pontos consecutivos na parte local, caracteres proibidos, excede os limites de comprimento (320 caracteres totais), ou tem estrutura de domínio malformada. Exemplos inválidos comuns incluem endereços com espaços, múltiplos símbolos @ ou domínios de nível superior ausentes.

Endereços de e-mail podem ter espaços?

Não, endereços de e-mail não podem conter espaços na forma não entre aspas. Espaços na parte local (antes do @) exigem que toda a parte local seja envolvida por aspas duplas: `”nome do usuario”@exemplo.com`. No entanto, endereços com strings entre aspas raramente são suportados por sistemas modernos, e a maioria dos provedores de e-mail os rejeita, apesar da validade técnica de acordo com a RFC 5322.

Letras maiúsculas são permitidas em endereços de e-mail?

Sim, a RFC 5321 especifica tecnicamente que os endereços de e-mail são sensíveis a maiúsculas/minúsculas. No entanto, praticamente todos os provedores de e-mail modernos tratam os endereços como insensíveis a maiúsculas/minúsculas na prática. `[email protected]` e `[email protected]` entregam na mesma caixa de correio no Gmail, Outlook, Yahoo e na maioria dos outros serviços. Melhor prática: trate os endereços como insensíveis a maiúsculas/minúsculas.

Qual é o comprimento máximo de um endereço de e-mail?

O comprimento máximo de um endereço de e-mail é de 320 caracteres no total: até 64 caracteres para a parte local (antes do @), mais o símbolo @ (1 caractere), mais até 255 caracteres para o nome de domínio. Os nomes de domínio também têm restrições por rótulo (máximo de 63 caracteres por rótulo entre pontos).

Todos os domínios de e-mail aceitam todos os formatos válidos?

Não. Embora a RFC 5322 defina a sintaxe válida, servidores de e-mail individuais podem implementar regras mais rigorosas. Alguns provedores rejeitam o endereçamento com sinal de mais, strings entre aspas ou caracteres especiais incomuns, apesar de sua validade técnica. Além disso, alguns serviços bloqueiam domínios de e-mail descartáveis, endereços baseados em função ou implementam restrições personalizadas por motivos de segurança ou política.

Como posso verificar se um endereço de e-mail existe?

Envie um e-mail de teste e confirme o recebimento, ou use serviços de verificação de e-mail que verificam registros MX e consultam servidores de e-mail. APIs de verificação (ZeroBounce, NeverBounce, Kickbox) podem determinar o status de entregabilidade. Observe que alguns servidores de e-mail bloqueiam tentativas de verificação, e domínios catch-all aceitam todos os endereços, tornando a confirmação definitiva de existência impossível em alguns casos.

O que é validação de sintaxe de e-mail?

Validação de sintaxe de e-mail é o processo de verificar se um endereço de e-mail segue as regras de formato adequadas sem tentar a entrega. Ele verifica a estrutura correta ([email protected]), caracteres permitidos, posição correta do ponto e limites de comprimento. A validação de sintaxe ocorre instantaneamente e captura erros óbvios, mas não pode confirmar se o endereço realmente existe ou recebe e-mail.

Posso usar caracteres especiais no meu endereço de e-mail?

Sim, a parte local de endereços de e-mail pode conter estes caracteres especiais: `! # $ % & ‘ * + – / = ? ^ _ ` { | } ~` mais pontos (com restrições). A parte do domínio permite apenas letras, dígitos, hífens e pontos. No entanto, alguns sites rejeitam incorretamente caracteres especiais válidos, particularmente sinais de mais usados para filtragem de e-mail.

O que são endereços de e-mail descartáveis?

Endereços de e-mail descartáveis são endereços temporários fornecidos por serviços como 10 Minute Mail ou Guerrilla Mail que expiram automaticamente após um tempo determinado. Eles são sintaticamente válidos e recebem e-mail normalmente durante sua vida útil. Os usuários os utilizam para evitar spam em sites não confiáveis, enquanto as empresas frequentemente bloqueiam domínios descartáveis conhecidos para garantir informações de contato de qualidade.

Como validar endereços de e-mail em massa?

Use serviços de verificação de e-mail em massa (ZeroBounce, NeverBounce, EmailListVerify) que processam grandes listas. Carregue um arquivo CSV ou de texto contendo os endereços, e o serviço valida a sintaxe e verifica a entregabilidade de cada entrada, geralmente processando milhares por minuto. Os resultados incluem status de validade, pontuações de entregabilidade e níveis de risco. A verificação em massa regular mantém a higiene da lista e melhora a reputação do remetente.

Por que meu e-mail válido é rejeitado em alguns sites?

A maioria das rejeições de e-mails válidos ocorre devido a regras de validação de site excessivamente restritivas que não estão totalmente em conformidade com a RFC 5322. Causas comuns incluem o bloqueio de sinais de mais (+), rejeição de novos TLDs (.io, .app), exigência de pontos em partes locais ou o uso de padrões regex desatualizados. Tente remover caracteres especiais, usar um endereço .com temporariamente ou entrar em contato com o suporte do site para relatar o problema de validação.

Qual a diferença entre validação e verificação de e-mail?

A validação de e-mail verifica a sintaxe e as regras de formato (instantâneo, offline, gratuito), confirmando que o endereço está estruturado corretamente. A verificação de e-mail verifica a entregabilidade real consultando registros DNS e servidores de e-mail (mais lento, requer internet, geralmente pago), confirmando que o endereço existe e recebe e-mail. O gerenciamento eficaz de e-mail usa primeiro a validação para capturar erros óbvios, depois a verificação para endereços que passam nas verificações de sintaxe.