Gérez l'adressage + lors des inscriptions sans bloquer de vrais utilisateurs. Apprenez une normalisation sûre pour la déduplication, les règles de stockage et les vérifications.
Oui, de nombreux utilisateurs réels comptent sur l'adressage plus comme [email protected], et beaucoup de fournisseurs livrent ces adresses dans la même boîte que [email protected]. Traitez cela comme un choix de format normal, pas comme un signe d'alerte.
Les gens utilisent des tags pour trier les messages dans des dossiers, tracer où une adresse a été utilisée et séparer différentes inscriptions. Bloquer + rejette souvent des clients prudents et légitimes.
Par défaut, stockez et affichez l'e-mail exactement tel qu'il a été saisi, et envoyez les messages à cette chaîne exacte. Le modifier peut casser des filtres, semer la confusion et créer des problèmes de support plus tard.
Ne dédupliquez pas en supprimant le +tag dans votre champ e-mail principal. Si vous devez dédupliquer, créez une « clé de comparaison » interne séparée et conservez l'adresse originale intacte pour l'envoi et l'affichage.
Exigez l'e-mail exact utilisé à l'inscription comme identifiant principal de connexion. Si quelqu'un entre une variante qui ne correspond que via une clé normalisée, demandez-lui de vérifier la propriété au lieu de le connecter silencieusement.
Normalisez de façon conservative : supprimez les espaces autour, rejetez les caractères de contrôle et mettez le domaine en minuscule. N'appliquez des règles sur la partie locale (comme supprimer +tag) que pour des domaines que vous avez explicitement sur une liste blanche et que vous comprenez, et conservez cette logique dans une clé de déduplication séparée.
Un motif trop strict qui n'autorise que lettres, chiffres et points avant @ est une cause fréquente. Utilisez une validation conforme aux RFC et évitez des regex maison qui considèrent + comme invalide.
Non, le support dépend de la configuration du domaine destinataire, pas seulement de la marque du fournisseur. Supposez que cela puisse fonctionner, validez les signaux de délivrabilité et évitez des règles du type « + marche toujours » ou « + ne marche jamais ».
Un +tag indique généralement une boîte normale, mais il peut être utilisé pour créer de nombreuses adresses « visuellement uniques » pour la même boîte. Gérez cela par des règles produit et des contrôles de comportement (vérification, limites de taux, scoring de risque), pas en interdisant +.
Validez la portée et le risque : syntaxe, vérification du domaine, enregistrements MX et détection des fournisseurs jetables, tout en acceptant les adresses taguées. Conservez les résultats de validation (statut, raison, horodatage) séparés de la chaîne d'e-mail stockée pour ne pas réécrire ce que l'utilisateur a saisi.
Beaucoup de gens utilisent des adresses comme [email protected]. La partie +tag est un tag (aussi appelé sous-adresse). De nombreux fournisseurs livrent ces messages dans la même boîte que [email protected], mais le tag permet à l'utilisateur d'identifier où l'adresse a été utilisée.
Les gens utilisent les tags pour des raisons pratiques : filtrage (règles qui classent les messages dans des dossiers), suivi (repérer quel site a fuité ou vendu une adresse) et séparation des inscriptions (chaque compte semble avoir un e-mail distinct). C'est particulièrement courant chez les utilisateurs de Gmail et Fastmail.
Les problèmes commencent quand un formulaire d'inscription considère + comme invalide ou suspect. Cela bloque des clients légitimes et prudents. Une autre erreur fréquente est de supprimer le tag et de stocker uniquement l'adresse de base. Cela peut fusionner plusieurs inscriptions en un seul compte et provoquer des problèmes de connexion et de récupération plus tard.
Modes d'échec courants :
+ alors qu'ils peuvent recevoir du courrier.name+billing@... et name+personal@... en un seul utilisateur.Considérez l'adressage plus comme un choix de format, pas comme une preuve de fraude. Acceptez les adresses capables de recevoir du courrier, et ne dédupliquez que lorsque c'est réellement sûr. La règle la plus simple qui évite la plupart des problèmes : conservez l'e-mail original exactement comme l'utilisateur l'a saisi, et (si nécessaire) créez une clé de correspondance séparée utilisée uniquement pour la comparaison.
Si vous utilisez une validation d'e-mail (par exemple via un fournisseur comme Verimail), la validation doit se concentrer sur la délivrabilité et les signaux de risque, pas sur la pénalisation des +tags dont beaucoup d'utilisateurs légitimes dépendent.
L'adressage plus est une façon d'ajouter un tag à une adresse e-mail sans créer une nouvelle boîte. Le schéma habituel est [email protected], où la partie après + aide l'utilisateur à étiqueter l'utilisation de l'adresse.
Une adresse e-mail a deux parties principales : la partie locale et le domaine. Dans [email protected], name+tag est la partie locale, et example.com est le domaine.
Trois idées sont souvent confondues :
+.sales@ et hello@), gérées par le fournisseur ou le propriétaire du domaine.Ce qui compte comme « la même boîte » dépend du fournisseur destinataire et de la configuration du domaine. Techniquement, [email protected] et [email protected] sont des chaînes différentes. Certains fournisseurs livrent les deux à la même boîte, mais ce n'est pas systématique, et le comportement peut varier selon le domaine.
C'est pourquoi la valeur par défaut la plus sûre est de traiter l'adresse complète saisie par l'utilisateur comme significative. Si quelqu'un s'inscrit avec [email protected], il peut s'attendre à recevoir ultérieurement des messages qui continuent d'atterrir dans le dossier filtré qu'il a configuré.
Exemple : un client utilise [email protected] pour les newsletters et [email protected] pour les factures. Si votre application supprime +news et +billing, vous pouvez fusionner deux intentions distinctes en un seul compte et créer de la confusion (et des tickets support) plus tard.
L'adressage plus est courant, mais il n'est pas universel. Beaucoup de grandes boîtes acceptent des adresses comme [email protected] et les livrent dans la même boîte que [email protected]. D'autres traitent la partie + différemment, ou ne la prennent pas en charge.
Un détail compte davantage que la marque : la règle est définie par le domaine destinataire. Même au sein d'une même entreprise, différents domaines peuvent avoir des réglages de routage du courrier différents. Durcir « + fonctionne toujours » ou « + ne fonctionne jamais » finit par bloquer de vrais utilisateurs.
Certains domaines supportent les +tags seulement pour certaines boîtes. Certains autorisent des séparateurs différents. Certains systèmes de transfert passent par des services qui suppriment ou réécrivent des parties de la partie locale. Traitez le sous-adressage comme une fonctionnalité « possible » sauf si vous pouvez la vérifier.
Ce qu'il ne faut pas supposer pour tous les domaines :
jane.doe vs janedoe) sauf si vous savez que le domaine se comporte ainsi.+tags pour les décisions d'envoi (envoyer le courrier à l'utilisateur).Un comportement par défaut sûr est simple : acceptez l'e-mail saisi par l'utilisateur, validez-le et conservez-le exactement tel quel pour l'envoi. Si vous devez dédupliquer, stockez une seconde valeur « normalisée pour la déduplication » séparément.
Si quelqu'un s'inscrit comme [email protected] parce qu'il souhaite filtrer les e-mails d'onboarding, le rejeter vous fait perdre un client réel. Le remplacer par [email protected] peut être tout aussi dommageable, car vous n'envoyez plus à l'adresse qu'il attend.
Une approche pratique : acceptez l'adresse, vérifiez la syntaxe et la configuration du domaine (y compris les enregistrements MX), puis appliquez des contrôles de jetable et de risque. Une API de validation d'e-mail comme Verimail peut confirmer que l'adresse est bien formée et que le domaine est configuré pour recevoir du courrier, tout en vous permettant de conserver l'adresse originale intacte pour l'envoi.
Stockez ce que l'utilisateur a saisi et envoyez vers cette adresse exacte. Les gens utilisent des tags pour de bonnes raisons (filtrer des reçus, séparer inscriptions pro/perso), et réécrire l'adresse peut casser la délivrabilité ou compliquer le support quand un utilisateur dit « je me suis inscrit avec [email protected]. »
En même temps, beaucoup de produits veulent une seconde valeur qui aide à repérer les doublons et garder les comptes propres. C'est là que la normalisation a sa place : dans une clé interne séparée, pas dans l'e-mail que vous utilisez pour l'envoi.
Un modèle de données pratique garde deux champs avec des rôles différents :
Conservez les informations de vérification séparément des deux. La validation n'est pas une propriété de l'adresse elle-même mais une caractéristique à un instant donné. Stockez des éléments comme le statut (valide, risqué, invalide), une raison (par exemple, domaine sans MX) et un horodatage.
La normalisation doit être conservative. Mettre le domaine en minuscules est généralement sûr. Mettre la partie locale en minuscules est souvent sûr en pratique, mais soyez cohérent et évitez les surprises. Surtout, ne retirez pas le +tag sauf si c'est uniquement pour une clé interne et seulement lorsque vous êtes certain que cela n'unifiera pas des personnes différentes.
Exemple concret : stockez [email protected] comme e-mail original, mais conservez une clé comme [email protected] pour la correspondance si vous êtes sûr de pouvoir le faire. Les messages continueront d'arriver où l'utilisateur s'y attend, tandis que votre système peut repérer des doublons potentiels sans réécrire l'adresse de livraison.
Acceptez les adresses réelles (y compris l'adressage plus) tout en repérant les doublons en créant une clé de déduplication séparée, pas en réécrivant ce que l'utilisateur a saisi.
Une approche pratique :
Couper et assainir l'entrée. Supprimez les espaces en début et fin. Rejetez les caractères de contrôle (tabulations, retours à la ligne, nulls) qui peuvent masquer une adresse différente ou perturber les logs et les envois.
Effectuer des vérifications de syntaxe basiques, sans interdire le +. Une partie locale valide peut inclure + et d'autres caractères. Concentrez-vous sur des problèmes évidents comme l'absence de @, des parties vides ou des espaces illégaux.
Normaliser le domaine avec soin. Mettez le domaine en minuscules et normalisez-le de façon cohérente. Si vous supportez les domaines internationalisés, convertissez-les via un processus standard pour que exämple.com et sa forme ASCII correspondent au même domaine.
Appliquer des règles sur la partie locale seulement quand vous contrôlez le risque. Ne supprimez pas globalement le +tag. Si vous souhaitez dédupliquer [email protected] avec [email protected], ne le faites que pour des domaines que vous avez explicitement sur liste blanche et que vous pouvez vérifier se comporter ainsi.
Créer une clé de déduplication stable, garder l'original intact. Stockez les deux valeurs : l'original pour l'envoi et l'affichage, et la clé normalisée pour la correspondance.
Exemple : si quelqu'un s'inscrit en tant que [email protected], stockez [email protected] comme e-mail de contact. Construisez une clé de déduplication comme [email protected] uniquement si example.com est sur une liste blanche pour la suppression des +tags. Sinon, conservez la clé proche de l'original, par exemple [email protected].
Si vous utilisez une API de validation d'e-mails comme Verimail, validez d'abord, puis normalisez. Cet ordre permet d'éviter de « corriger » une mauvaise adresse en quelque chose qui a l'air valide mais qui ne délivrera toujours pas.
Considérez l'e-mail saisi comme l'étiquette d'identité d'une personne, pas comme quelque chose que vous pouvez réécrire librement. Avec l'adressage plus, deux chaînes peuvent pointer vers la même boîte, mais elles ne représentent pas toujours le même « compte » du point de vue de l'utilisateur.
À l'inscription, acceptez les +tags et affichez l'adresse exactement comme elle a été saisie (y compris la partie +). Cela rassure l'utilisateur que vous n'avez pas « corrigé » son e-mail.
Pour la connexion, une règle simple évite les surprises : laissez les utilisateurs se connecter avec l'e-mail exact qu'ils ont utilisé lors de la création du compte. Si quelqu'un essaie une variation différente (comme retirer le tag) et que vous ne trouvez une correspondance qu'avec une clé normalisée, ne le connectez pas silencieusement. Demandez une confirmation de propriété, par exemple via le mode de connexion habituel ou une vérification par e-mail.
La fusion doit requérir une preuve, pas seulement « ces adresses se normalisent de la même façon ». Options sûres courantes :
Exemple : Alex s'inscrit en tant que [email protected] pour un essai de newsletter. Des mois plus tard, un collègue saisit [email protected] sur un appareil partagé. La fusion automatique basée uniquement sur la normalisation peut donner l'accès à une mauvaise personne.
Décidez dès le départ si les +tags comptent comme des identités distinctes. Certaines équipes traitent chaque adresse invitée comme unique pour le suivi, mais empêchent la création de plusieurs comptes sauf si l'invitation est revendiquée via un e-mail confirmé.
Si vous validez les e-mails pendant l'inscription, gardez les frontières claires : la validation aide la délivrabilité et la détection de risque, tandis que les décisions d'identité (connexion, fusion, invitations) doivent suivre des règles produit explicites.
La manière la plus rapide de perdre de bonnes inscriptions est de traiter une adresse valide comme « étrange ». L'adressage plus est normal pour les personnes qui filtrent leurs messages, traquent qui a utilisé leur adresse ou gardent des inscriptions séparées.
Un bug fréquent est une regex qui n'autorise que lettres, chiffres, points et tirets avant le @. Cela bloque [email protected] alors que c'est valide pour beaucoup de fournisseurs. Si vos règles de validation datent, c'est souvent la source du problème.
Une autre erreur est de supprimer le +tag puis d'utiliser la version modifiée pour l'envoi. Si l'utilisateur a saisi [email protected], vous devez stocker et envoyer exactement ce qu'il a entré. Le retrait du tag peut aussi casser des règles de boîte de réception qui en dépendent.
La gestion des points est particulièrement risquée. Certains services ignorent les points dans la partie locale (sam.smith@... vs samsmith@...), mais beaucoup ne le font pas. Supposer l'insensibilité aux points partout peut fusionner deux boîtes différentes.
Un problème plus sournois est l'incohérence des règles entre systèmes. Si votre flux d'inscription accepte [email protected], mais que votre outil de facturation supprime le tag alors que votre outil marketing le conserve, la même personne peut apparaître comme plusieurs contacts ou être fusionnée incorrectement.
Vérifications rapides « ne faites pas ça » :
+ dans la partie locale.La normalisation n'est pas une vérification. Utilisez la normalisation uniquement pour une déduplication prudente. Utilisez un vrai validateur (par exemple Verimail) pour attraper les fautes de frappe, les domaines invalides et les adresses jetables sans bloquer les utilisateurs légitimes avec +tag.
Un +tag est généralement le signe d'un utilisateur prudent, pas d'un attaquant. Les gens utilisent des tags pour filtrer le courrier ou pour savoir quel site a divulgué leur adresse.
Les attaquants peuvent néanmoins abuser des alias pour créer de nombreux comptes, car certains fournisseurs traitent [email protected] comme la même boîte. Cela peut contourner les règles « un compte par e-mail » si votre système considère chaque +tag comme une identité distincte.
La solution n'est pas d'interdire les +tags. Cela bloque de vrais utilisateurs et n'empêche pas l'abus sur des fournisseurs qui supportent d'autres styles d'alias (points, alias de domaine, catch-alls). Décidez ce que vous protégez : la création de comptes en volume, les promotions ou l'identité.
Concentrez la friction sur le comportement, pas sur le format. Par exemple : limitez le débit des pics d'inscription suspects, exigez une vérification par e-mail pour les inscriptions à risque élevé et surveillez de nombreuses inscriptions mappant vers une même boîte en peu de temps.
Si vous devez séparer « identité » et « méthode de contact », ne faites pas de l'e-mail votre seule clé. Traitez le compte comme un enregistrement à part entière et les adresses e-mail comme des points de contact pouvant être ajoutés, vérifiés et supprimés. Cela facilite la gestion des boîtes partagées, des adresses de rôle et des changements d'adresse légitimes.
La détection des adresses jetables est plus importante que l'interdiction des +tags. Une boîte jetable est conçue pour des inscriptions éphémères ; un +tag est généralement une boîte normale. Des outils comme Verimail peuvent aider en repérant les fournisseurs jetables connus, les pièges à spam et les adresses invalides tout en acceptant les adresses taguées légitimes.
La plupart des problèmes réels avec l'adressage plus sont auto-infligés : une regex trop stricte ou une règle de déduplication qui fusionne silencieusement des comptes qui devraient rester séparés.
Commencez par accepter. Votre validateur doit autoriser le + dans la partie locale (avant @). Évitez les raccourcis regex qui supposent seulement lettres, chiffres, points et underscores. Si vous utilisez une bibliothèque, confirmez qu'elle suit les règles RFC plutôt qu'un motif maison.
Ensuite, séparez livraison et déduplication. Stockez toujours l'e-mail original exactement comme l'utilisateur l'a saisi pour l'affichage et l'envoi. Si vous créez une clé normalisée pour la déduplication, gardez-la séparée et documentez les règles afin que le support et l'ingénierie prennent les mêmes décisions.
Une petite checklist avant déploiement :
+ dans la partie locale.Pour les signaux de portée et de boîte, validez avant de bloquer les utilisateurs sur des étapes comme « vérifiez votre e-mail pour continuer ». Un validateur peut vous aider à éviter de bloquer de vrais utilisateurs à cause de fautes de frappe ou de domaines morts.
Enfin, exécutez un jeu de tests simples : [email protected], [email protected] et [email protected]. Confirmez qu'ils peuvent s'inscrire, se connecter, réinitialiser le mot de passe et recevoir des messages sans surprises.
Cas courant : une application B2B offre des essais gratuits. Un administrateur chez Acme teste le produit pour différents clients et utilise des tags comme [email protected], [email protected] et [email protected] pour garder ses règles de boîte organisées. C'est un comportement d'adressage plus normal, et les messages arrivent toujours dans la même boîte.
Les ennuis commencent quand la déduplication est trop agressive. Si vous supprimez tout après + et traitez toutes ces inscriptions comme le même utilisateur, vous pouvez bloquer des personnes. L'administrateur essaie de créer un deuxième essai, mais votre application pense que le compte existe déjà et bloque l'inscription. Puis la réinitialisation du mot de passe leur est envoyée pour le premier essai, pas pour celui qu'ils consultent.
Une approche plus sûre est de séparer « identité de livraison » et « identité de compte ». Stockez l'e-mail original exactement comme saisi. Stockez une forme normalisée uniquement comme aide pour la correspondance, la revue ou l'analytics. Puis :
[email protected], mais exigez la confirmation par e-mail avant d'activer l'essai.Pour le support, il est utile d'afficher les deux champs dans le profil utilisateur et les logs : « E-mail saisi » et « Normalisé pour déduplication ». Cela facilite les explications et les corrections rapides.
Si vous acceptez les +tags mais les gérez différemment entre inscription, connexion et outils internes, vous continuerez à créer des doublons et à confondre les utilisateurs. La correction la plus rapide est d'écrire vos règles et de les appliquer partout où le champ e-mail apparaît.
Une politique simple fonctionne pour la plupart des équipes : stockez l'e-mail exactement comme l'utilisateur l'a saisi, et n'utilisez qu'une valeur normalisée séparée pour la correspondance et le reporting. Cela vous permet de dédupliquer sans casser la livraison ni surprendre quelqu'un qui dépend des tags.
Checklist de déploiement :
Si vous souhaitez une implémentation qui se concentre sur la portée et les signaux de risque (sans rejeter les +tags légitimes), Verimail (verimail.co) fournit une API de validation d'e-mails unique qui combine les vérifications de syntaxe, la vérification des domaines et MX, et la détection des adresses jetables et des listes de blocage.
Une fois les changements en production, mesurez les résultats pour détecter les régressions et ajuster les règles. Suivez le taux de rejet à l'inscription et les raisons, le taux de rebond de confirmation, le taux de comptes dupliqués selon votre clé normalisée, et les tickets support mentionnant des comptes dupliqués ou des inscriptions échouées. Conservez un petit échantillon d'adresses rejetées (anonymisées) et revoyez-les. Si vous voyez beaucoup de domaines réels bloqués, vos règles de validation ou de normalisation sont trop agressives.