Endereçamento com + em e-mail: aceitar +tags e desduplicar com segurança

Por que o uso de +tags causa problemas nos cadastros

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:

• Rejeitar e-mails com + mesmo quando eles podem receber mensagens.
• Lógica de dedupe que junta name+billing@... e name+personal@... numa só conta.
• Redefinições de senha e logins falhando porque o usuário digitou a versão com tag que usou originalmente.
• Recuperação de conta quebrando quando o sistema “normaliza” o endereço de maneira diferente ao longo do tempo.

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.

Endereçamento com + e subendereçamento em linguagem simples

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:

• Endereçamento com + (subaddressing): Uma tag adicionada à parte local, frequentemente após +.
• Aliases: Endereços adicionais que entregam na mesma caixa (como sales@ e hello@), gerenciados pelo provedor ou pelo dono do domínio.
• Encaminhamento: Mensagens enviadas para um endereço são automaticamente redirecionadas para outro.

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.

Onde o endereçamento com + funciona e onde pode não funcionar

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.

Variações que você verá por aí

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:

• Não remova pontos (jane.doe vs janedoe) a menos que você saiba que o domínio se comporta assim.
• Não transforme a parte local em minúsculas para todos os domínios. A sensibilidade a maiúsculas é rara na prática, mas é permitida.
• Não remova +tags para decisões de envio (ao enviar e-mail ao usuário).

Como lidar com a incerteza sem quebrar cadastros

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.

O que armazenar: e-mail original vs e-mail normalizado

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:

• Email (original): entrada exata, preservada para envio, exibição e auditoria.
• Email key (normalizado): forma consistente usada para desduplicação, busca e comparação.

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.

Passo a passo: uma estratégia segura de normalização para dedupe

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:

1. 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.

2. 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.

3. 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.

4. 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.

5. 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.

Como lidar com cadastro, login e mesclagem de contas

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.

Mesclagem de contas sem correspondências falsas

Mesclar deve requerer prova, não apenas “isso normaliza para a mesma string”. Opções seguras comuns:

• O usuário já está autenticado em uma conta e verifica a outra.
• Ambas as contas confirmam propriedade via códigos por e-mail.
• Mesclagem assistida pelo suporte com registro de auditoria.

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.

Convites e indicações

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.

Erros comuns que bloqueiam usuários reais

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.

A armadilha do regex muito rígido

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.

Normalizar demais e mesclar pessoas erradas

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”:

• Não rejeite + na parte local.
• Não envie para uma versão modificada do que o usuário digitou.
• Não assuma que pontos são seguros para colapsar em todos os domínios.
• Não aplique regras diferentes nas etapas de cadastro, faturamento e ferramentas de e-mail.

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.

Observações sobre abuso e fraude: o que +tags significam (ou não)

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.

Checagens rápidas antes de lançar

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:

• Aceite + na parte local.
• Armazene o e-mail original sem alterações; nunca envie para uma versão modificada.
• Use uma chave normalizada para dedupe apenas com regras claras e dependentes do domínio.
• Confirme sinais do domínio antes de bloquear fluxos que dependam de e-mail (domínio existe, registros MX, indicadores de descartável).
• Teste com alguns provedores principais e pelo menos um domínio personalizado que você controle.

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.

Exemplo: evitar má dedupe em um fluxo real de cadastro

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:

• Permita cadastro com [email protected], mas exija confirmação por e-mail antes do trial ficar ativo.
• Se a chave normalizada coincidir com uma conta confirmada existente, mostre uma mensagem clara como “Você já pode ter uma conta. Quer entrar em vez disso?”.
• Se seu produto suporta múltiplos workspaces, mantenha registros separados e conecte-os depois via um fluxo de mesclagem explícito.

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.

Próximos passos: validar, medir e manter o banco limpo

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:

• Documente as regras de normalização (o que você muda, o que nunca muda) num lugar compartilhado.
• Aplique as mesmas regras no cadastro, ferramentas de administração, importações e fluxos de suporte.
• Valide no cadastro com checagens de sintaxe compatíveis com RFC, verificação de domínio, lookup MX e detecção de descartáveis.
• Para casos incertos, permita cadastro mas exija verificação de propriedade via e-mail.

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.