Lide com endereços com + nos cadastros sem bloquear usuários reais. Aprenda normalização segura para desduplicação, regras de armazenamento e verificações de validação.
Sim, muitos usuários reais usam endereçamento com +, como [email protected], e muitos provedores entregam na mesma caixa que [email protected]. Trate isso como uma escolha de formatação normal, não como um sinal de alerta.
As pessoas usam tags para filtrar mensagens em pastas, rastrear onde um endereço foi usado e manter cadastros separados. Bloquear + frequentemente rejeita clientes legítimos e cuidadosos.
O padrão mais seguro é armazenar e exibir o e-mail exatamente como o usuário digitou e enviar mensagens para essa string exata. Alterá-lo pode quebrar filtros da caixa de entrada, confundir usuários e gerar problemas de suporte.
Não deduplique removendo +tag no campo principal de e-mail. Se precisar deduplicar, crie uma 'chave de comparação' interna separada e mantenha o endereço original intacto para envio e exibição.
Exija o e-mail exato usado no cadastro como identificador principal de login. Se alguém inserir uma variação diferente que só corresponda por uma chave normalizada, solicite verificação de propriedade em vez de conectá-lo silenciosamente.
Normalize de forma conservadora: remova espaços laterais, rejeite caracteres de controle e coloque o domínio em minúsculas. Aplique regras na parte local, como remover +tag, apenas para domínios que você explicitamente permita e compreenda, e mantenha essa lógica em uma chave de desduplicação separada.
Um padrão muito restrito que permite apenas letras, números e pontos antes do @ é uma causa comum. Use validação de sintaxe compatível com RFC e evite regex caseiras que considerem + inválido.
Não — o suporte depende da configuração do domínio receptor, não apenas da marca do provedor. Assuma que pode funcionar, valide sinais de entregabilidade e evite regras rígidas como “+ sempre funciona” ou “+ nunca funciona”.
Uma +tag geralmente indica uma caixa de entrada normal, mas pode ser usada para criar muitos endereços 'aparentemente únicos' para a mesma caixa. Trate isso com regras de produto e checagens comportamentais (verificação, limites de taxa, pontuação de risco), não proibindo +.
Valide a alcançabilidade e o risco: sintaxe, verificação de domínio, registros MX e detecção de provedores descartáveis, mantendo a aceitação de endereços com tags. Mantenha os resultados da validação (status, motivo, timestamp) separados da string de e-mail armazenada para não reescrever o que o usuário digitou.
Muitas pessoas reais usam e-mails como [email protected]. A parte +tag é uma tag (também chamada de subaddress). Muitos provedores entregam esses e-mails na mesma caixa que [email protected], mas a tag permite que alguém identifique onde o endereço foi usado.
As pessoas usam tags por motivos práticos: filtragem (regras que movem mensagens para pastas), rastreamento (identificar qual site vazou ou vendeu um endereço) e para manter cadastros separados (cada conta parece ter um e-mail distinto). É especialmente comum entre usuários do Gmail e Fastmail.
Os problemas começam quando um formulário de cadastro trata + como inválido ou suspeito. Isso bloqueia clientes legítimos e cuidadosos. Outro erro comum é remover a tag e armazenar apenas o endereço base. Isso pode juntar vários cadastros numa conta só e causar problemas confusos de login e recuperação depois.
Falhas comuns:
+ mesmo quando eles podem receber mensagens.name+billing@... e name+personal@... numa só conta.Trate o endereçamento com + como uma escolha de formatação, não como prova de fraude. Aceite endereços que possam receber e-mail e só dedupe quando for realmente seguro. A regra mais simples que evita a maioria dos problemas: mantenha o e-mail original exatamente como o usuário digitou e (se precisar) crie uma chave separada usada apenas para comparação.
Se você usar validação de e-mail (por exemplo, via um provedor como Verimail), a validação deve focar em entregabilidade e sinais de risco, não em punir +tags que muitos usuários legítimos usam.
O endereçamento com + é uma forma de adicionar uma tag ao e-mail sem criar uma nova caixa. O padrão usual é [email protected], onde a parte após + ajuda o usuário a identificar onde o endereço foi usado.
Um endereço de e-mail tem duas partes principais: a parte local e o domínio. Em [email protected], name+tag é a parte local e example.com é o domínio.
Três ideias costumam ser confundidas:
+.sales@ e hello@), gerenciados pelo provedor ou pelo dono do domínio.O que conta como “a mesma caixa” depende do provedor receptor e da configuração do domínio. Tecnicamente, [email protected] e [email protected] são strings diferentes. Alguns provedores entregam ambas na mesma caixa, mas nem todos fazem isso, e o comportamento pode variar por domínio.
Por isso o padrão mais seguro é tratar o endereço completo digitado pelo usuário como significativo. Se alguém se cadastra com [email protected], ele pode esperar que mensagens futuras continuem caindo na pasta filtrada que configurou.
Exemplo: um cliente usa [email protected] para newsletters e [email protected] para faturas. Se seu app remover +news e +billing, você pode juntar duas intenções distintas numa só conta e gerar confusão (e tickets de suporte) depois.
O endereçamento com + é comum, mas não é universal. Muitos provedores aceitam endereços como [email protected] e os entregam na mesma caixa que [email protected]. Outros tratam a parte + de forma diferente ou não a suportam.
Um detalhe importa mais do que a marca: a regra é definida pelo domínio receptor. Mesmo dentro de uma mesma empresa, domínios diferentes podem ter regras de roteamento distintas. Hardcodar “+ sempre funciona” ou “+ nunca funciona” eventualmente vai bloquear usuários reais.
Alguns domínios suportam +tags apenas para certas caixas. Outros permitem separadores diferentes. Algumas configurações encaminham o e-mail por sistemas que removem ou reescrevem partes da parte local. Considere o subendereçamento como um recurso “talvez” a menos que você possa verificar.
O que não se deve assumir em todos os domínios:
jane.doe vs janedoe) a menos que você saiba que o domínio se comporta assim.+tags para decisões de envio (ao enviar e-mail ao usuário).Um padrão seguro é simples: aceite o e-mail digitado pelo usuário, valide-o e mantenha-o exatamente como entrou para envio. Se você precisar deduplicar, armazene um segundo valor “normalizado para dedupe” separadamente.
Se alguém se cadastra como [email protected] porque quer filtrar e-mails de onboarding, rejeitá-lo é perder um cliente real. Sobrescrever para [email protected] pode ser igualmente ruim, porque você não estará mais enviando para o endereço que ele esperava.
Uma abordagem prática é aceitar o endereço, validar sintaxe e configuração do domínio (incluindo registros MX) e então aplicar checagens de descartáveis e risco. Uma API de validação de e-mail como Verimail (verimail.co) pode confirmar que o endereço está bem formado e que o domínio está configurado para receber mensagens, enquanto você mantém o endereço original intacto para envio.
Armazene o que o usuário digitou e envie para esse endereço exato. As pessoas usam tags por motivos reais (filtrar recibos, separar cadastros pessoais e de trabalho) e reescrever o endereço pode quebrar a entrega ou dificultar o suporte quando o usuário disser “eu me cadastrei com [email protected]”.
Ao mesmo tempo, muitos produtos querem um segundo valor que ajude a identificar duplicatas e manter contas organizadas. É aí que a normalização pertence: numa chave interna separada, não no e-mail que você usa para enviar.
Um modelo de dados prático mantém dois campos com funções diferentes:
Mantenha as informações de verificação separadas de ambos. Validação não é parte do endereço em si. É uma propriedade do endereço num momento no tempo. Armazene coisas como status (válido, arriscado, inválido), uma razão (por exemplo, domínio sem MX) e um timestamp.
A normalização deve ser conservadora. Colocar o domínio em minúsculas geralmente é seguro. Colocar a parte local em minúsculas costuma ser seguro na prática, mas seja consistente e evite surpresas. O mais importante: não remova +tag a menos que seja apenas para uma chave interna e apenas onde você tem confiança de que não irá juntar pessoas diferentes.
Exemplo concreto: armazene [email protected] como e-mail original, mas mantenha uma chave como [email protected] para correspondência apenas se for apropriado. As mensagens ainda vão onde o usuário espera, enquanto seu sistema pode identificar possíveis duplicatas sem reescrever o endereço de entrega.
Aceite endereços reais (incluindo endereçamento com +) enquanto identifica duplicatas criando uma chave de dedupe separada, não reescrevendo o que o usuário digitou.
Uma abordagem prática:
Remova espaços e sanitize a entrada. Tire espaços nas extremidades. Rejeite caracteres de controle (tabs, quebras de linha, nulos) que podem esconder outro endereço ou quebrar logs e e-mails.
Faça checagens básicas de sintaxe, mas não bloqueie +. Uma parte local válida pode incluir + e outros caracteres. Foque em problemas óbvios como falta de @, partes vazias ou espaços ilegais.
Normalize o domínio com cuidado. Coloque o domínio em minúsculas e normalize-o de forma consistente. Se você suporta domínios internacionalizados, converta-os usando um processo padrão para que exämple.com e sua forma ASCII mapem para o mesmo domínio.
Aplique regras na parte local só quando você controla o risco. Não remova +tag globalmente. Se você quer deduplicar [email protected] com [email protected], faça isso apenas para domínios que você explicitamente permita e consegue verificar que se comportam assim.
Crie uma chave de dedupe estável e mantenha o original intacto. Armazene ambos os valores: o original para envio e exibição, e a chave normalizada para correspondência.
Exemplo: se alguém se cadastra como [email protected], armazene [email protected] como e-mail de contato. Construa uma chave de dedupe como [email protected] somente se example.com estiver numa allowlist para remoção de +tags. Caso contrário, mantenha a chave mais próxima do original, como [email protected].
Se você usa uma API de validação de e-mail como Verimail, valide primeiro e depois normalize. Essa ordem ajuda a evitar “consertar” um endereço ruim para algo que pareça válido mas ainda não entregue.
Trate o e-mail que a pessoa digita como o rótulo de sua identidade, não algo que você possa reescrever livremente. Com endereçamento com +, duas strings podem apontar para a mesma caixa, mas nem sempre representam a mesma “conta” do ponto de vista do usuário.
No cadastro, aceite +tags e mostre o e-mail exatamente como foi digitado (incluindo a parte +). Isso dá segurança ao usuário de que você não “corrigiu” o e-mail por conta própria.
Para login, uma regra simples evita surpresas: permita que o usuário entre com exatamente o e-mail que usou ao criar a conta. Se alguém tentar uma variação diferente (como remover a tag) e você só encontrar uma correspondência via chave normalizada, não faça o login silenciosamente. Peça confirmação de propriedade, por exemplo pedindo que faça login normalmente ou completando uma verificação por e-mail.
Mesclar deve requerer prova, não apenas “isso normaliza para a mesma string”. Opções seguras comuns:
Exemplo: Alex se cadastra como [email protected] para uma assinatura de newsletter. Meses depois, um colega digita [email protected] num dispositivo compartilhado. Mesclar automaticamente com base apenas na normalização pode dar acesso à pessoa errada.
Decida antecipadamente se +tags contam como identidades únicas. Algumas equipes tratam cada endereço convidado como distinto para rastreamento, mas ainda impedem múltiplas contas a menos que o convite seja reivindicado via confirmação de e-mail.
Se você valida e-mails durante o cadastro, deixe clara a fronteira: a validação ajuda na entregabilidade e no risco, enquanto decisões de identidade (login, mesclagem, convites) devem seguir regras explícitas do produto.
A maneira mais rápida de perder bons cadastros é tratar um endereço válido como “esquisito”. Endereçamento com + é normal para pessoas que filtram e-mails, rastreiam onde compartilharam um endereço ou mantêm cadastros separados.
Um bug comum é um regex de e-mail que só permite letras, números, pontos e hífens antes do @. Isso bloqueia [email protected] mesmo quando é válido para muitos provedores. Se suas regras de validação foram escritas anos atrás, esse é frequentemente o culpado.
Outro erro é remover a +tag e então usar a versão removida para envio. Se o usuário digitou [email protected], você deve armazenar e enviar exatamente para o que ele entrou. Remover a tag também pode quebrar regras de caixa de entrada que dependem dela.
O tratamento de pontos é especialmente arriscado. Alguns serviços ignoram pontos na parte local (sam.smith@... vs samsmith@...), mas muitos não. Assumir insensibilidade a pontos em todos os domínios pode juntar caixas diferentes.
Um problema mais sutil é regras inconsistentes entre sistemas. Se seu fluxo de cadastro aceita [email protected], mas sua ferramenta de faturamento remove a tag enquanto sua ferramenta de marketing a mantém, a mesma pessoa pode aparecer como contatos múltiplos ou ser mesclada incorretamente.
Checagens rápidas “não faça isto”:
+ na parte local.Normalização não é verificação. Use normalização apenas para desduplicação cuidadosa. Use um validador real (por exemplo, Verimail) para detectar erros de digitação, domínios inválidos e endereços descartáveis sem bloquear usuários legítimos com +tag.
Uma +tag costuma ser sinal de um usuário cuidadoso, não de um atacante. Pessoas usam tags para filtrar e-mails ou para ver qual site vazou seu endereço.
Atacantes ainda podem abusar de aliases para criar muitas contas, porque alguns provedores tratam [email protected] como a mesma caixa. Isso pode burlar regras de “uma conta por e-mail” se seu sistema tratar cada +tag como nova identidade.
A solução não é banir +tags. Isso bloqueia usuários reais e não impede abuso em provedores que suportam outros estilos de alias (pontos, aliases de domínio, catch-alls). Decida o que você está protegendo: criação de contas em volume, promoções ou identidade.
Foque a fricção no comportamento, não na formatação. Por exemplo: limite a taxa de cadastros suspeitos, exija verificação por e-mail para cadastros de maior risco e monitore muitos cadastros que mapeiam para uma mesma caixa num curto período.
Se você precisa separar “identidade” de “método de contato”, não faça do e-mail sua única chave. Trate a conta como um registro próprio e trate endereços de e-mail como pontos de contato que podem ser adicionados, verificados e removidos. Isso facilita suportar caixas compartilhadas, endereços de função e mudanças legítimas de e-mail.
Detectar e-mails descartáveis importa mais do que banir +tags. Uma caixa descartável é feita para cadastros temporários; uma +tag costuma ser uma caixa normal. Ferramentas como Verimail podem ajudar ao identificar provedores descartáveis conhecidos, armadilhas de spam e endereços inválidos enquanto ainda aceitam endereços marcados com tags.
A maioria dos problemas reais com endereçamento com + é autoinfligida: um regex demasiado rígido ou uma regra de dedupe que mescla silenciosamente contas que deveriam ficar separadas.
Comece aceitando. Seu validador deve permitir + na parte local (antes do @). Evite atalhos regex que assumam apenas letras, números, pontos e underscores. Se usar uma biblioteca, confirme que ela segue as regras do RFC em vez de um padrão caseiro.
Em seguida, separe envio de dedupe. Sempre armazene o e-mail original exatamente como o usuário digitou para exibição e envio. Se criar uma chave normalizada para dedupe, mantenha-a separada e documente as regras para que suporte e engenharia tomem as mesmas decisões.
Uma breve lista antes do lançamento:
+ na parte local.Para sinais de alcançabilidade de domínio e caixa, valide antes de travar o usuário em etapas como “verifique seu e-mail para continuar”. Um validador pode ajudar a evitar bloquear usuários reais por causa de typos ou domínios mortos.
Por fim, rode um conjunto de testes simples: [email protected], [email protected] e [email protected]. Confirme que eles conseguem se cadastrar, entrar, resetar senhas e receber mensagens sem surpresas.
Um caso comum: um app B2B oferece trials gratuitos. Um administrador na Acme testa o produto para diferentes clientes e usa tags como [email protected], [email protected] e [email protected] para manter regras de caixa organizadas. Isso é comportamento normal de endereçamento com +, e as mensagens ainda entregam na mesma caixa.
O problema começa quando a dedupe é agressiva demais. Se você remover tudo após + e tratar todos esses cadastros como o mesmo usuário, pode bloquear pessoas. O administrador tenta criar um segundo trial, mas seu app acha que a conta já existe e bloqueia o cadastro. Então o reset de senha envia para a conta do primeiro trial, não para a que ele está tentando acessar.
Uma abordagem mais segura é separar “identidade de entrega” de “identidade de conta”. Armazene o e-mail original exatamente como digitado. Guarde uma forma normalizada apenas como auxiliar para correspondência, revisão ou análise. Então:
[email protected], mas exija confirmação por e-mail antes do trial ficar ativo.Para suporte, é útil mostrar ambos os campos no perfil do usuário e nos logs: “E-mail digitado” e “Normalizado para dedupe”. Isso facilita explicar o que ocorreu e corrigir rapidamente.
Se você aceita +tags mas as trata de forma diferente no cadastro, login e ferramentas internas, continuará criando duplicatas e confundindo usuários. A correção mais rápida é documentar suas regras e aplicá-las em todos os lugares onde o campo de e-mail aparece.
Uma política simples funciona bem para a maioria das equipes: armazene o e-mail exatamente como o usuário digitou e use um valor normalizado separado apenas para correspondência e relatórios. Isso permite deduplicar sem quebrar a entrega ou surpreender alguém que depende das tags.
Checklist de rollout:
Se você quer uma implementação que foque em alcançabilidade e sinais de risco (sem rejeitar +tags legítimos), Verimail (verimail.co) fornece uma API única de validação de e-mail que combina checagens de sintaxe, verificação de domínio e MX, e detecção de descartáveis e blocklists.
Depois que as mudanças estiverem ativas, meça os resultados para detectar regressões e ajustar regras. Monitore taxa de rejeição de cadastros e motivos, taxa de bounce nas confirmações, taxa de contas duplicadas pela chave normalizada e tickets de suporte mencionando contas duplicadas ou cadastros falhos. Mantenha uma pequena amostra de endereços rejeitados (anonimizados) e revise-os. Se você ver muitos domínios reais sendo bloqueados, suas regras de validação ou normalização estão agressivas demais.