20 de dez. de 2025·6 min
Checklist de validação de sintaxe de email compatível com RFC para cadastros
Use este checklist de validação de sintaxe de email compatível com RFC para capturar casos extremos como strings entre aspas, plus addressing e subdomínios complicados antes do lançamento.
Por que a validação da sintaxe de email causa tantos bugs
Endereços de email parecem simples até você tentar validá-los. Muitos bugs em produção vêm de tratar um email como “algumas letras, um @ e um ponto” e depois confiar em uma regex rápida. Endereços reais permitem mais variação do que a maioria dos formulários espera, e pequenas escolhas de parsing podem transformar um endereço válido em um erro “inválido”.
Uma confusão comum é confundir duas perguntas diferentes:
- O que os padrões permitem (regras de sintaxe)
- O que seu produto quer aceitar (sua política)
Se você quer reduzir cadastros arriscados, pode bloquear certos padrões. Se seu objetivo é evitar rejeitar usuários reais, primeiro precisa acertar a sintaxe e depois aplicar a política por cima. Separar essas camadas é a diferença entre um validador confiável e outro que silenciosamente perde cadastros.
Rejeitar emails válidos quebra coisas reais. Alguém insere um endereço perfeitamente válido com plus addressing ou um subdomínio, seu formulário diz “inválido” e a pessoa vai embora. Você perde o cadastro e nem reúne dados suficientes para depurar o que aconteceu.
Aceitar emails ruins quebra outras coisas. Endereços inválidos aumentam bounces, o que pode prejudicar reputação do remetente e entregabilidade. Eles também atraem cadastros de baixa qualidade e fraude quando atacantes enchem formulários com lixo.
A maioria das falhas em produção se resume a alguns padrões: regexes que são muito restritas (ou frouxas demais), divisão incorreta ao redor de @, trimming ou “normalização” excessiva, e misturar checagens de sintaxe com checagens de entregabilidade.
Exemplo: alguém se cadastra com [email protected]. Um validador simplista o rejeita porque espera apenas um ponto no domínio. O endereço pode estar perfeitamente certo, mas o usuário nunca chega à confirmação.
Este post foca na sintaxe: se um endereço está escrito em um formato válido. Não prova que a caixa existe ou que o domínio pode receber mail. Essas checagens pertencem a camadas posteriores.
O que significa compatível com RFC (e o que não significa)
“Compatível com RFC” é principalmente sobre sintaxe: essa string pode ser parseada como um endereço de email segundo as regras da RFC 5322? Isso é útil, mas é só o primeiro portão. Um endereço sintaticamente válido ainda pode ser não entregável, inseguro ou de baixa qualidade.
Sintaxe vs checagem de domínio vs existência da caixa
Pense na validação em camadas:
- Sintaxe: O endereço está formatado corretamente (caracteres, separadores, regras de aspas)?
- Domínio: O domínio pode receber email (DNS, registros MX)?
- Existência da caixa: Essa caixa específica existe? Esta é a camada mais difícil, pois muitos servidores não confirmam.
Um pipeline prático se parece com: parsear sintaxe, verificar o básico do domínio e então aplicar sua política (bloquear domínios descartáveis conhecidos, armadilhas de spam e outros sinais de risco). Sintaxe sozinha nunca deve fingir que garante entregabilidade.
O que “compatível com RFC” significa na prática
Para formulários de cadastro, “compatível com RFC” geralmente significa aceitar formatos reais comuns (tags com +, subdomínios, TLDs mais longos) e evitar rejeitar endereços válidos só porque são incomuns.
Algumas equipes intencionalmente endurecem regras. Isso pode ser razoável, mas deve ser uma escolha deliberada, documentada e testada. Por exemplo, você ainda pode rejeitar:
- Ausência de
@ou falta da parte local ou do domínio - Caracteres de controle, espaços invisíveis ou quebras de linha coladas
- Rótulos de domínio que começam ou terminam com hífen
- Unicode que você não suporta fim-a-fim
- Entradas extremamente longas (defina um tamanho máximo para prevenir abuso)
Cenário: [email protected] pode ser sintaticamente válido. Se o domínio não tem registros MX, você pega isso na camada de domínio. Se for um provedor descartável conhecido, isso é política.
Conheça as partes de um endereço antes de validar
A maioria dos bugs de validação de email acontece porque o validador está chutando. Antes de pegar uma regex, mantenha a estrutura clara: uma parte local, exatamente um @ e uma parte de domínio.
- A parte local é tudo antes do
@. É aí que moram os casos complicados: tags com +, pontos e às vezes strings entre aspas. - A parte de domínio é tudo depois do
@. Segue regras de rótulos de domínio e pode ser internacionalizada.
Manter essas peças separadas torna a lógica mais fácil de entender e muito mais simples de testar.
ASCII vs endereços internacionalizados (visão geral)
Endereços reais podem incluir caracteres não ASCII na parte local (EAI) e domínios não ASCII (IDN). Decida desde o início o que você suporta.
Se aceitar apenas ASCII, rejeite não-ASCII cedo com uma mensagem clara. Se aceitar IDNs, normalmente você vai validar o domínio em sua forma compatível com ASCII (punycode) internamente.
Limites de comprimento para impor
Limites de comprimento ajudam a evitar casos extremos e protegem seus formulários contra abuso. Limites comuns usados na prática:
- Comprimento total: 254 caracteres
- Parte local: 64 caracteres
- Parte de domínio: 253 caracteres
- Cada rótulo de domínio: 63 caracteres
Faça uma limpeza básica antes de parsear: remova espaços em branco no início e no fim, e rejeite endereços com espaços internos a menos que você suporte intencionalmente local parts entre aspas. Não transforme a parte local para minúsculas (ela pode ser sensível a maiúsculas), mas lowercasing o domínio geralmente é seguro.
Plus addressing e pontos: casos comuns para suportar
Plus addressing é quando alguém adiciona uma tag após um sinal de mais, como [email protected]. Pessoas usam isso para filtrar email e rastrear cadastros, então rejeitá-lo adiciona atrito sem benefício.
Trate + como um caractere normal na parte local (fora de strings entre aspas). Mesmo que alguns provedores ignorem a tag para entrega, ainda faz parte do endereço como escrito.
Caracteres na parte local: subconjunto seguro vs conjunto completo
Muitas equipes aceitam um “subconjunto seguro” na parte local (letras, dígitos e alguns separadores como ., _, -, +). Isso cobre a maioria dos endereços reais e deixa a implementação mais simples.
As regras da RFC permitem mais pontuação, mas ampliar o conjunto aceito só ajuda se você fizer isso corretamente e mantiver testes sólidos.
Pontos: o que a sintaxe permite (e o que os provedores fazem)
Na forma comum não entre aspas, pontos são permitidos na parte local, mas não em qualquer posição:
- Sem ponto inicial:
[email protected]é inválido - Sem ponto final
- Sem pontos consecutivos:
[email protected]é inválido
Não incorpore comportamento específico de provedores na sintaxe. Alguns provedores tratam firstlast e first.last como a mesma caixa, mas isso não é uma regra de sintaxe.
Alguns casos rápidos que valem testar:
[email protected](tag com +)[email protected](ponto)[email protected](ponto inicial)[email protected](ponto duplo)[email protected](tag + com subdomínio)
Strings entre aspas: o caso limite que a maioria dos parsers perde
Pare com bugs em regex de email
Substitua regexes frágeis por validação consciente das RFCs, além de verificações de domínio e MX.
Strings entre aspas existem porque as regras de email precisaram cobrir sistemas antigos e nomes de caixa incomuns. Elas aparecem na parte local quando o endereço precisa de caracteres que seriam ilegais ou ambíguos de outra forma.
Uma parte local entre aspas é envolvida por aspas duplas, como \"john smith\"@example.com. Dentro das aspas, espaços são permitidos. Se você precisa de uma aspa dupla literal ou de uma barra invertida dentro das aspas, ela deve ser escapada com uma barra invertida.
A parte confusa é que as regras mudam dentro das aspas. Dois pontos em sequência são normalmente inválidos em uma parte local não entre aspas, mas são permitidos dentro de uma string entre aspas. Isso significa que \"a..b\"@example.com pode ser válido mesmo que [email protected] seja inválido.
Para cadastros, você tem uma escolha real:
- Suportar completamente strings entre aspas (e testá-las a fundo), ou
- Rejeitá-las de propósito porque são raras e podem quebrar sistemas a jusante
Ambas são defensáveis. O que causa bugs é rejeitá-las acidentalmente com uma regex que você não quis depender.
Casos de teste sintaticamente válidos:
\"john smith\"@example.com\"a..b\"@example.com\"john\\\"smith\"@example.com\"back\\\\slash\"@example.com\"weird()[],:;\u003c\u003e@\"@example.com
Strings entre aspas afetam apenas a parte local. Você ainda precisa validar o domínio separadamente.
Domínios e subdomínios: o que permitir e o que bloquear
Muitos validadores erram no domínio. Subdomínios são normais e comuns. [email protected] não deve surpreender seu parser.
Uma abordagem simples é validar o domínio como rótulos separados por pontos e então aplicar algumas regras fáceis.
O que permitir (e por quê)
Para a maioria dos cadastros de consumidor, estas regras funcionam bem:
- Vários rótulos (subdomínios) são aceitáveis.
- Rótulos podem conter letras e dígitos, e podem incluir hífens no meio (não nas bordas).
- Rótulos têm de 1 a 63 caracteres, e o domínio completo não é absurdamente longo (muitos sistemas limitam a 253).
Exigir “pelo menos um ponto” frequentemente é um bom filtro contra erros de digitação para endereços públicos, mas pode ser uma decisão de política se você suportar domínios internos.
O que bloquear (falhas que parecem corretas)
A colocação de pontos é onde bugs se escondem. Estes devem ser falhas duras:
- Pontos consecutivos:
[email protected] - Ponto no início ou no fim:
[email protected],[email protected]. - Rótulos vazios por divisão ruim:
[email protected] - Rótulo que começa ou termina com hífen:
[email protected],[email protected] - Caracteres inválidos em um rótulo (underscores são um erro comum):
a@sub_domain.example
Erros comuns de parsing que criam rejeições falsas
Torne regras de sintaxe previsíveis
Use checagem de sintaxe compatível com RFC em vez de chutar com padrões muito rígidos ou muito frouxos.
A maioria dos erros “email inválido” vem de validadores que fazem suposições em vez de seguir regras consistentes.
Espaços em branco são um grande problema. Copiar/colar pode adicionar espaços iniciais, finais, tabs, espaços sem quebra ou uma newline oculta. Se você validar antes de trimar, rejeita um endereço válido. Se “normalizar” demais (como remover todos os espaços onde quer que sejam), você pode mudar o significado do endereço.
Outro erro é dividir ao redor de @ de forma ingênua. Você quer uma regra clara: exatamente um separador @, com pelo menos um caractere em cada lado. Não aceite lixo dividindo no primeiro @ e ignorando o resto, e não trave ou gere erros confusos dividindo em todos os @.
Algumas bibliotecas também suportam parcialmente features da RFC como comentários (por exemplo john.smith(comment)@example.com). Suporte parcial pode ser pior do que rejeição consistente porque cria divergências entre frontend e backend.
Sinais de alerta:
- Trimar apenas espaços ASCII, mas não tabs, espaços sem quebra ou quebras de linha finais
- Dividir em
@sem impor “exatamente um” - Aceitar com uma regex permissiva e depois falhar mais tarde com um erro vago
- Resultados diferentes entre ambientes (web vs mobile vs backend)
- Ignorar parecidos Unicode (por exemplo um “а” cirílico que parece “a” latino)
Parecidos Unicode são complicados. Mesmo que você suporte endereços internacionalizados, ajuda registrar casos suspeitos e mostrar uma mensagem clara quando algo parece estranho.
Passo a passo: construa um validador de sintaxe confiável
Um validador confiável não é um padrão esperto. É um pequeno conjunto de regras aplicadas na ordem certa.
1) Limpe a entrada
Remova espaços em branco no início e no fim, então rejeite caracteres de controle (tabs, quebras de linha, null bytes). Decida como tratar espaços Unicode não usuais. Seja explícito se suporta ou não não-ASCII.
2) Faça o parse com um parser atento à RFC (não só regex)
Uma abordagem só com regex frequentemente rejeita endereços válidos ou aceita quebrados. Use um parser que entenda parte local vs domínio, e saiba lidar com strings entre aspas se você decidir suportá-las.
Mantenha parsing separado de política. Parsing responde “é sintaticamente válido?” Política responde “permitimos no produto?”
3) Aplique limites e regras de rótulo de domínio
Depois do parse, aplique limites rígidos e checagens básicas de sanidade do domínio (limites de comprimento, sem rótulos vazios, sem hífens nas bordas, subdomínios permitidos quando bem formados). Isso pega entradas que podem tecnicamente parsear mas que vão causar problemas depois.
4) Escolha sua política de rigidez e documente
Decida intencionalmente sobre casos extremos como partes locais entre aspas. Se bloquear, diga e mostre uma mensagem clara. Se permitir, adicione testes para caracteres escapados e espaços.
O mais importante é manter as mesmas regras na web, mobile e backend para que os usuários não vejam erros inconsistentes.
5) Registre falhas com códigos de motivo
Quando o suporte perguntar por que um email foi rejeitado, “inválido” não ajuda. Registre um pequeno conjunto de códigos de motivo (por exemplo: CONTROL_CHAR, PARSE_FAIL, LENGTH, DOMAIN_LABEL). Isso facilita diagnosticar picos e ajuda a encontrar problemas como um teclado iOS que insere uma newline oculta.
Casos de teste para incluir na sua suíte de validação
Trate casos extremos com segurança
Valide formatos complicados como subdomínios e plus addressing com resultados consistentes.
Um validador é tão bom quanto os testes que garantem seu comportamento. Mantenha um conjunto pequeno de “deve passar” baseado em cadastros reais, um conjunto “deve falhar” para rejeições universais e um conjunto de casos extremos para armadilhas do parser.
Exemplos que devem passar:
Exemplos que devem falhar:
- `` (string vazia)
plainaddress(sem@)alex@(sem domínio)@example.com(sem parte local)[email protected](ponto duplo na parte local)
Se decidir suportar strings entre aspas, adicione testes explícitos como \"john..doe\"@example.com e \"john\\\"doe\"@example.com. Se decidir não suportá-las, mantenha os testes igualmente, mas marque-os como rejeições por política para que a escolha fique visível.
Não pare em apenas passar/falhar. Armazene códigos de motivo esperados para que falhas sejam acionáveis.
{ "input": "[email protected]", "expected": "fail", "reason": "LOCALPART_DOT_SEQUENCE" }
Execute a mesma suíte em todos os lugares que você valida: web, mobile, backend e qualquer fluxo de autenticação de terceiros. É aí que as divergências geralmente aparecem.
Checklist rápido e próximos passos
Se quiser menos bugs de cadastro e menos tickets “por que este email não funciona?”, mantenha suas regras de sintaxe curtas e consistentes. Um limite prático fica assim:
- Exatamente um
@, com pelo menos um caractere em cada lado - Sem espaços ou caracteres de controle (a menos que você suporte intencionalmente partes locais entre aspas)
- Comprimento dentro dos limites comuns (parte local até 64, endereço total até 254)
- Domínio bem formado (sem pontos consecutivos, sem rótulos vazios, sem hífen inicial/final em rótulos)
- Tags com + e subdomínios são permitidos por padrão
Decida uma vez e documente: se aceita partes locais entre aspas como \"john smith\"@example.com. Elas são válidas segundo a RFC 5322, mas raras em cadastros e frequentemente maltratadas por sistemas a jusante.
Depois da sintaxe, adicione as checagens que a sintaxe não cobre: verifique se o domínio existe, cheque registros MX e filtre provedores descartáveis e armadilhas conhecidas. Se preferir não manter essas camadas internamente, Verimail (verimail.co) é uma API de validação de email que executa checagens de sintaxe junto com verificação de domínio, lookup MX e correspondência de descartáveis e blocklists, para que você mantenha a lógica do cadastro consistente sem colocar tudo em uma única regex.
Perguntas Frequentes
Por que validar email com regex é tão propenso a erros?
Use um parser dedicado quando possível. Regexes normalmente perdem casos extremos como local parts entre aspas, tags com + e domínios com múltiplos rótulos, então ou rejeitam usuários reais ou aceitam entradas inválidas.
Qual é a diferença entre validação de sintaxe e política de aceitação?
Sintaxe pergunta: “Isto está escrito em um formato de email válido?” Política pergunta: “Queremos permitir isso no nosso produto?” Separe-as para não bloquear endereços válidos enquanto tenta reduzir cadastros de risco.
“Compatível com RFC” significa que um email é entregue?
Não. “Compatível com RFC” significa principalmente que a string pode ser parseada como endereço de email. Não prova que o domínio existe, que tem registros MX ou que a caixa postal recebe mensagens.
Que limpeza de entrada devo fazer antes de validar um email?
Primeiro remova espaços em branco no início e no fim, depois rejeite caracteres de controle como tabs e quebras de linha. Não “normalize” removendo caracteres internos, porque isso pode alterar o endereço que o usuário digitou.
Meu formulário de cadastro deve permitir plus addressing (como [email protected])?
Permita por padrão. [email protected] é um formato normal e amplamente usado; bloqueá-lo costuma criar atrito desnecessário no cadastro sem melhorar a segurança por si só.
Subdomínios como [email protected] são válidos?
Sim. Subdomínios são comuns, e domínios podem ter múltiplos pontos como sub.example.co.uk. Um validador que assume “apenas um ponto” no domínio vai rejeitar muitos endereços reais.
Como devo tratar múltiplos sinais @ em um campo de email?
Exija “exatamente um @”, com pelo menos um caractere em cada lado. Não divida no primeiro @ e ignore o resto, e não aceite entradas que contenham múltiplos @ como estão.
Preciso suportar local parts entre aspas como "john smith"@example.com?
Decida intencionalmente. Eles são válidos segundo a norma, mas são raros e podem quebrar sistemas a jusante que assumem formatos mais simples. Se você os rejeitar, trate como uma escolha de política e mostre uma mensagem clara.
Que limites de tamanho devo impor para endereços de email?
Eles ajudam a evitar entradas abusivas ou perigosas e reduzem casos extremos estranhos. Limites práticos comuns: 254 caracteres no total, 64 para o local part, 253 para o domínio e 63 por rótulo de domínio.
Como posso registrar falhas de validação para que sejam realmente úteis?
Use códigos de motivo que mapeiem falhas específicas, como CONTROL_CHAR, PARSE_FAIL, LENGTH ou DOMAIN_LABEL. Isso torna tickets de suporte e debugging muito mais fáceis do que um genérico “email inválido”.