Endereços de e-mail internacionalizados: o que quebra em produção

Por que e-mails que parecem válidos quebram em produção

Um endereço de e-mail pode parecer normal e ainda assim falhar no momento em que chega a um sistema real. A maior razão é que o que as pessoas veem como um caractere pode ser armazenado como bytes diferentes, tratado de forma distinta por bibliotecas ou rejeitado por servidores de e-mail antigos.

Um exemplo comum é algo como søren@exämple.com. Pode ser um endereço legítimo, mas toca vários pontos frágeis ao mesmo tempo: Unicode na parte local, um nome de domínio internacionalizado e uma infraestrutura de e-mail que pode ou não suportar isso.

As falhas também aparecem longe do seu formulário de cadastro. Você pode aceitar o endereço e depois falhar ao enviar um reset de senha porque seu provedor de e-mail (ou um relay intermediário) não suporta SMTPUTF8. Ou sua regex aceita, mas o passo de "converter para minúsculas e aparar" o transforma em algo diferente do que o usuário pretendia.

Rejeições falsas são caras porque geralmente são silenciosas. Pessoas abandonam cadastros, tentam com outro e-mail ou abrem tickets de suporte difíceis de reproduzir. Se você tem audiência global, rejeitar endereços internacionalizados também pode parecer que você simplesmente não dá suporte ao idioma delas.

Aceitar por engano custa de outra forma. Endereços ruins geram bounces, pioram a entregabilidade e sujam suas listas. Algumas entradas com aparência válida são deliberadamente maliciosas: domínios descartáveis, contas de função usadas para abuso ou armadilhas de spam que prejudicam a reputação do remetente.

O objetivo não é "aceitar tudo" nem "bloquear tudo". É aceitar usuários reais enquanto para entradas obviamente ruins, usando checagens que reflitam como e-mail funciona de verdade: separar exibição de armazenamento, verificar alcançabilidade do domínio (não só a presença do @) e evitar transformações agressivas que reescrevem silenciosamente o que o usuário digitou.

O que conta como um endereço de e-mail internacionalizado

Um endereço de e-mail tem duas partes separadas por @: a parte local (antes do @) e o domínio (depois do @). Endereços internacionalizados podem incluir caracteres Unicode em qualquer uma das partes, e o suporte no mundo real varia conforme qual lado usa Unicode.

O caso mais comum é um nome de domínio internacionalizado (IDN). O usuário vê um domínio escrito no seu script, como maria@bücher.example ou li@例子.公司. Por baixo, muitos sistemas convertem esse domínio para uma forma ASCII (frequentemente chamada de punycode) para que consultas DNS e checagens de MX funcionem de forma confiável.

O caso mais complicado é Unicode na parte local, como jó[email protected] ou ユーザー@domain.com. Isso entra na Email Address Internationalization (EAI) e geralmente é entregue usando SMTPUTF8. Mesmo se o endereço for válido pelos padrões modernos, alguns servidores de e-mail, bibliotecas antigas e ferramentas a jusante ainda rejeitam. Isso significa que você pode aceitá-lo no cadastro e ainda falhar depois, ao tentar enviar.

Uma maneira prática de pensar sobre o suporte hoje:

• Domínios Unicode são amplamente utilizáveis porque podem ser representados em ASCII para DNS.
• Partes locais Unicode têm suporte menos consistente de ponta a ponta (formulário de cadastro, banco de dados, CRM, provedor de e-mail e caixa de entrada precisam todos lidar com elas).
• Scripts mistos e caracteres que se parecem aumentam o risco de fraude.
• Exibição e armazenamento quebram quando o software assume "um caractere equivale a um byte".

Por isso uma regex simples de sim/não não basta. Uma regex pode rejeitar usuários legítimos (por exemplo, bloqueando não-ASCII de forma indiscriminada) ou aceitar endereços que você na prática não consegue entregar.

Melhor validação trata cada lado separadamente. Para o domínio, normalize e converta para ASCII para checagens DNS. Para a parte local, você precisa de uma decisão de política: vocês suportam SMTPUTF8 totalmente, permitem com aviso ou bloqueiam porque sua pilha de e-mail não entrega de forma confiável?

IDNs e punycode: o lado do domínio

Um IDN (Internationalized Domain Name) é um domínio que usa caracteres não ASCII, como acentos ou scripts não latinos. Pessoas veem e digitam a forma Unicode, mas o DNS é construído em torno de ASCII. Esse desalinhamento é onde muitos bugs em produção começam.

Para buscar registros MX, verificar um domínio ou até fazer uma checagem DNS básica, geralmente você precisa da forma ASCII do domínio. Essa conversão é feita com regras IDNA e produz punycode, que frequentemente começa com xn--. Então um usuário pode digitar um domínio que parece normal para ele, mas seus logs, banco de dados ou provedor a montante podem mostrar uma versão xn--....

Punycode aparece em lugares que você deve prever e tratar:

• Consultas DNS e MX
• Chamadas de API para serviços de validação ou entregabilidade
• Logs e ferramentas de segurança (para que analistas possam copiar e colar com segurança)
• Armazenamento e deduplicação (para que o mesmo domínio não seja armazenado duas vezes em formas diferentes)

Dois erros comuns:

• Validar apenas o domínio em Unicode como string e nunca convertê-lo antes de checar o DNS.
• Rejeitar qualquer domínio com caracteres não ASCII, bloqueando usuários legítimos.

Há também um ângulo de segurança. Scripts mistos e caracteres confusíveis podem ser usados para criar domínios que se parecem visualmente com uma marca confiável. Geralmente você não deve bloquear todos os IDNs por causa disso, mas é razoável tratá-los como maior risco em contextos como pagamentos, resets de senha ou acesso administrativo.

Uma abordagem prática é aceitar o que o usuário digita e então normalizar internamente:

• Aceite o domínio Unicode no campo de entrada.
• Converta o domínio para ASCII (punycode) para checagens DNS e MX.
• Armazene ambas as formas quando possível: Unicode para exibição, ASCII para checagens técnicas e correspondência consistente.
• Alerte padrões suspeitos (scripts mistos, confusables) para revisão extra ou verificação adicional.

Normalização Unicode: por que o mesmo texto nem sempre é o mesmo

Unicode permite digitar nomes e palavras de muitas línguas, mas também significa que o "mesmo" caractere pode ser representado de mais de uma maneira. Se você comparar strings por bytes brutos, ou armazenar uma forma e depois receber outra, pode ter duplicados, logins falhos e confusos erros de "e-mail já em uso".

Um exemplo simples é caracteres acentuados. A letra "é" pode ser um único ponto de código (U+00E9) ou dois pontos de código: "e" (U+0065) mais um acento combinante (U+0301). Para uma pessoa parecem idênticos, mas seu banco de dados pode tratá-los como diferentes.

NFC vs NFKC (e por que importa)

Normalização converte texto para uma forma consistente.

• NFC (Normalization Form C) compõe caracteres quando possível. Geralmente mantém a intenção do usuário enquanto torna as comparações de igualdade mais confiáveis.
• NFKC vai além, convertendo caracteres de compatibilidade em equivalentes mais simples (por exemplo, algumas formas de largura total). Isso pode melhorar consistência, mas também pode alterar o significado e interagir mal com spoofing e confusíveis se aplicado sem critério.

Para o tratamento de e-mail, NFC costuma ser o padrão mais seguro para comparações de "tornar iguais".

Manipulação de caixa: o que transformar em minúsculas (e o que não)

Regras de caixa diferem entre os dois lados do endereço:

• Parte do domínio (à direita do @): é seguro tratar como insensível a maiúsculas; converter para minúsculas aqui é padrão.
• Parte local (à esquerda do @): é tecnicamente sensível a maiúsculas, embora muitos provedores ignorem a caixa. Converter para minúsculas pode mesclar dois endereços distintos em alguns sistemas.

Uma abordagem prática: normalize e converta para minúsculas o domínio; mantenha a parte local como o usuário a inseriu, mas armazene também uma forma canônica para comparações.

Quando normalizar (e quando preservar)

Normalize nos momentos em que a consistência importa:

• Na entrada: normalize para NFC antes da validação e antes de checar "já cadastrado".
• No armazenamento: mantenha a string original (para exibição e suporte) e uma forma canônica (para busca e dedupe).
• Na comparação: compare usando a forma canônica, não a entrada bruta.

Mesmo com um bom serviço de validação, seu app precisa de uma política clara de normalização e de caixa para que usuários legítimos não sejam bloqueados por diferenças invisíveis de caracteres.

Onde sistemas em produção geralmente falham

A maioria dos bugs com endereços internacionalizados acontece nas junções, onde um sistema assume algo diferente do próximo. O endereço parece bem para um usuário, mas algo na cadeia o altera, rejeita ou trata dois valores com aparência idêntica como diferentes.

Uma falha comum começa no formulário de cadastro. Regras no frontend frequentemente permitem apenas A-Z, 0-9 e alguns símbolos. Teclados móveis inserem pontuação inteligente e o preenchimento automático adiciona um espaço final que você não vê. Auto-conversão para minúsculas também pode se comportar de maneira estranha fora do ASCII básico.

No backend, pequenos passos de limpeza podem ser destrutivos. Aparar é bom, mas remover "caracteres não imprimíveis" pode deletar marcas Unicode válidas. Limites de comprimento são outro problema silencioso: domínios internacionalizados podem crescer quando convertidos para punycode, e você pode atingir um limite inesperado.

Bancos de dados adicionam suas próprias armadilhas. Collation e regras de comparação decidem se duas strings são iguais. Se um sistema armazena uma forma composta e outro mais tarde envia uma forma decomposta, checagens de unicidade podem falhar. Isso cria contas duplicadas ou bloqueia um usuário porque sua consulta de "já existe" não bate com o que foi armazenado.

Problemas aparecem com mais frequência em:

• Validação no cliente e widgets de entrada
• Sanitização no servidor, aparagem e limites de tamanho
• Colation do banco de dados e índices únicos
• Integrações (CRMs, analytics, ferramentas de suporte, processadores de logs)
• Sistemas de e-mail de saída que não suportam SMTPUTF8

E-mail de saída é onde se torna inevitável. Se seu servidor de e-mail ou um relay a jusante não suporta SMTPUTF8, ele pode recusar enviar para uma caixa com caracteres não ASCII na parte local. Usuários conseguem se cadastrar, mas nunca recebem e-mails de verificação.

Uma cadeia de falha realista é assim: um usuário se registra com um domínio Unicode, seu app o armazena, seu CRM normaliza de forma diferente e seu provedor de e-mail recusa SMTPUTF8. Agora você tem um usuário, duas strings que não batem e um e-mail de boas-vindas que nunca chega.

Passo a passo: um fluxo de validação mais seguro

Um fluxo mais seguro começa separando dois objetivos: não bloquear pessoas reais no cadastro e armazenar algo que você possa comparar, enviar e dar suporte depois.

1. Preserve a entrada do usuário. Mantenha o endereço exatamente como foi digitado, e remova apenas espaços óbvios nas extremidades. Evite edições "úteis" como mudar caixa, remover acentos, deletar pontos ou tirar tags de mais. Essas mudanças podem transformar silenciosamente um endereço em outro.

2. Faça uma checagem real de sintaxe. Trate como "isso é estruturalmente possível?", não como "o e-mail definitivamente vai funcionar". Regras modernas são mais amplas que a maioria das regexes, especialmente quando caracteres internacionais estão envolvidos.

3. Decida sobre normalização e unicidade. Armazene o endereço bruto mais uma forma canônica (frequentemente NFC) para checagens de igualdade. Se o e-mail é chave única no seu sistema, documente se entradas visualmente idênticas mas codificadas de forma diferente contam como a mesma conta.

4. Trate o domínio corretamente. Normalize o domínio e converta para ASCII (punycode) antes de qualquer trabalho com DNS. Depois verifique o domínio e cheque registros MX (e possivelmente fallback para A/AAAA se sua política permitir).

5. Tenha uma política para partes locais Unicode. Se seu provedor de saída não entrega SMTPUTF8 de forma confiável, aceite o cadastro só se tiver um plano B (verificação in-app, método de contato alternativo ou um aviso claro antes de prometer entrega por e-mail).

Mantenha um pequeno conjunto de logs sobre resultados de validação para que o suporte possa investigar casos extremos sem adivinhar.

Validação vs entregabilidade: o que você pode provar

Muitas pessoas dizem "validação de e-mail" quando querem dizer "minha mensagem vai alcançar uma pessoa real". Isso é entregabilidade, e você não pode prová-la completamente no cadastro. Com endereços internacionalizados, é ainda mais fácil confundir "parece válido" com "vai funcionar em todos os lugares".

Validação ainda pode dar sinais fortes antes de você armazenar um endereço ou enviar para ele:

• Sintaxe é aceitável (incluindo regras SMTPUTF8 quando relevante)
• O domínio existe e é resolvível
• Registros MX estão presentes (ou o domínio está configurado para receber mail)
• O endereço ou domínio parece arriscado (por exemplo, provedores descartáveis)

Mas validação não garante que a inbox existe ou aceitará sua mensagem. Muitos provedores bloqueiam sondagens em caixas, aceitam mail para usuários desconhecidos e só devolvem bounce depois, ou mudam políticas sem aviso.

Uma abordagem mais segura é em duas etapas:

• Validar no cadastro para capturar problemas óbvios, reduzir erros de digitação e prevenir cadastros de baixa qualidade.
• Confirmar propriedade com um passo de verificação por e-mail (um clique). Isso prova que o usuário pode receber mensagens e controla o endereço.

Para resultados de "alto risco", bloqueios rígidos costumam criar falsos negativos. Atrito suave tende a funcionar melhor: permita o cadastro, exija confirmação antes de ações críticas ou peça um sinal extra apenas quando o risco for alto.

Erros comuns que bloqueiam usuários legítimos

A forma mais rápida de perder cadastros reais é tratar tudo fora do ASCII simples como inválido. Muitos provedores legítimos suportam domínios internacionalizados e alguns usuários dependem deles.

Erro 1: regras "apenas ASCII" demasiadamente estritas

Muito código em produção ainda assume que e-mail significa A-Z, 0-9, pontos e uma lista curta de símbolos. Isso quebra para domínios IDN e garante rejeições falsas em produtos globais.

Erro 2: converter toda a string para minúsculas ou normalizar demais

Converter o domínio para minúsculas é ok. Converter a parte local pode ser arriscado.

A normalização ajuda, mas fazê-la sem critério pode surpreender usuários. Normalize intencionalmente, mantenha a entrada original e teste como sistemas a jusante se comportam.

Transformações “úteis” que falham:

• Aparar agressivamente (ou deletar caracteres que você pensa ser invisíveis)
• Converter todo o endereço para minúsculas
• Aplicar uma forma de normalização em todos os lugares sem testar exportações e integrações
• Remover automaticamente pontos ou tags de plus (comportamento específico de provedor)

Erro 3: mostrar punycode para usuários

Seu backend pode precisar de punycode para checagens DNS, mas a interface do usuário deve normalmente exibir o domínio no script do usuário. Mostrar xn--... em confirmações ou mensagens de erro costuma parecer suspeito, mesmo quando o endereço está correto.

Erro 4: presumir que partes locais Unicode sempre funcionam

Mesmo que um endereço seja válido pela especificação, nem todo servidor suporta SMTPUTF8. Se você aceita partes locais Unicode, esteja preparado para diferenças de entregabilidade entre provedores.

Erro 5: ignorar artefatos de colar

Copiar e colar introduz espaços inseparáveis, caracteres de largura zero e espaços em branco estranhos ao redor do @. Usuários não conseguem ver esses problemas, mas sua validação sim.

Exemplo: um usuário cola name@пример.рф com um espaço final. Se você validar antes de aparar, rejeita. Se você sanitiza demais, pode alterar a parte local.

Verificações rápidas antes do lançamento

Endereços internacionalizados podem funcionar de ponta a ponta, mas apenas se todas as camadas concordarem sobre o que aceitar, armazenar e enviar. Antes do release, rode checagens que reflitam o comportamento de produção, não apenas testes unitários.

Checklist prático pré-lançamento

• Confirme que o formulário de cadastro aceita Unicode onde você pretende (domínio, parte local ou ambos). Se você não suporta parte local Unicode, informe isso no ponto de entrada.
• Escolha uma regra de normalização (geralmente NFC) e aplique-a de forma consistente no browser, API, jobs em background e ferramentas administrativas.
• Converta o domínio para ASCII (punycode) antes de trabalho com DNS e armazene uma forma comparável para que as buscas não derivem.
• Faça a unicidade de conta corresponder às regras de login e busca. Decida se endereços visualmente idênticos mas codificados de forma diferente devem mapear para um único usuário.
• Teste envio de e-mail no seu caminho real (provedor, relay, biblioteca) usando exemplos com domínio IDN e parte local Unicode.

Checagens que costumam ser esquecidas (até os tickets chegarem)

Assegure que logs e ferramentas administrativas exibam a versão amigável ao usuário sem transformar em mojibake ou quebrar exportações. Confirme também que todo sistema que toca o endereço pode lidar com ele: eventos de analytics, sincronização com CRM, payloads de webhooks, exportações CSV e ingestão em data warehouse. Muitas falhas acontecem na exportação, não na entrada.

Um teste concreto: faça passar o mesmo endereço por cadastro, login, reset de senha e qualquer fluxo de merge de conta. Se passar no cadastro e falhar depois, há um desalinhamento na normalização, armazenamento ou comparações.

Cenário de exemplo e próximos passos

Um usuário se cadastra com marta@bücher.example. Parece normal porque o domínio está em Unicode. Seu sistema precisa tratar o domínio como um IDN.

No lado do domínio, mantenha a exibição amigável ao usuário, mas valide a forma segura para o DNS. Converta bücher.example para punycode (xn--bcher-kva.example) antes de fazer buscas MX. Se você só checar a forma Unicode, algumas bibliotecas DNS podem falhar ou se comportar de forma inconsistente.

Agora a parte sutil: o mesmo e-mail pode ser digitado de múltiplas maneiras que parecem idênticas. Suponha que a usuária digite márta@bücher.example, mas o "á" pode ser composto como um único caractere ou como "a" mais um acento combinante. Se você armazenar apenas a entrada bruta, uma pessoa pode acabar com duas contas que parecem iguais na sua UI.

A normalização corrige isso. Normalize para NFC antes de comparar, armazenar, limitar taxa ou desduplicar, e aplique os mesmos passos em todos os lugares que o endereço for tocado.

A parte local (tudo antes do @) é onde você precisa de uma política clara. SMTPUTF8 permite partes locais Unicode, mas nem todo provedor as suporta de ponta a ponta. Uma política prática para muitos produtos é:

• Aceitar partes locais ASCII por padrão.
• Se a parte local contém Unicode, aceite-a mas exija confirmação ou mostre um aviso claro.
• Se seu produto depende fortemente de entrega por e-mail (resets de senha, faturas), bloqueie partes locais Unicode a menos que você tenha testado suporte SMTPUTF8 em toda sua pilha de e-mail.

Se você quiser um único lugar para executar checagens de sintaxe mais verificação de domínio e MX (e filtrar provedores descartáveis), um serviço de validação de e-mail como Verimail (verimail.co) pode fornecer esses sinais sem depender de uma regex frágil.

Próximos passos que mantêm você seguro sem rejeitar usuários reais:

• Documente sua política para partes locais Unicode (aceitar, avisar ou bloquear) e mantenha-a consistente entre web, mobile e ferramentas administrativas.
• Normalize para NFC antes de armazenar, comparar ou desduplicar.
• Teste casos de borda: domínios IDN, scripts mistos, caracteres compostos vs decompostos e entradas coladas.
• Monitore resultados: taxa de confirmação, bounces e erros de "e-mail já em uso" após normalização.
• Mantenha logs suficientes das decisões de validação para depurar rejeições falsas rapidamente.