1. La partie locale (nom d’utilisateur)

La partie locale apparaît avant le symbole @ et identifie la boîte aux lettres spécifique d’un domaine. Selon la RFC 5322, la partie locale peut contenir :

Caractères autorisés :

• Lettres majuscules et minuscules (A-Z, a-z)
• Chiffres (0-9)
• Caractères spéciaux : ! # $ % & ‘ * + – / = ? ^ _ ` { | } ~
• Point (.) mais PAS au début, à la fin, ou consécutivement

Règles clés :

• Longueur maximale : 64 caractères
• Sensible à la casse en théorie, bien que la plupart des serveurs de messagerie les traitent comme insensibles à la casse
• Les chaînes entre guillemets autorisent des caractères supplémentaires : `”john..doe”@example.com`

Exemples valides courants :

• `john.doe` (lettres et point)
• `user+tag` (signe plus pour le filtrage)
• `admin_2024` (underscore et chiffres)
• `first-last` (trait d’union)

Erreurs courantes à éviter :

• Commencer ou finir par un point : `.john@` ou `john.@`
• Points consécutifs : `john..doe@`
• Espaces sans guillemets : `john doe@`
• Uniquement des caractères spéciaux : `@@@@@@@`

2. Le symbole @

Le symbole @ (arobase) sert de séparateur obligatoire entre la partie locale et le nom de domaine. Chaque adresse e-mail valide contient exactement un symbole @ (sauf s’il est dans une chaîne entre guillemets).

Règles critiques :

• Exactement un @ requis
• Ne peut pas apparaître au début ou à la fin
• Ne peut pas être échappé ou remplacé

La position du symbole @ détermine où se termine la partie locale et où commence le nom de domaine. Les systèmes de validation d’e-mail localisent d’abord le symbole @, puis valident séparément les portions avant et après celui-ci.

3. Le nom de domaine

Le nom de domaine suit le symbole @ et identifie le serveur de messagerie qui reçoit les messages pour cette adresse. Les noms de domaine doivent être conformes aux normes DNS (Domain Name System).

Exigences de structure du domaine :

• Contient une ou plusieurs étiquettes séparées par des points
• Chaque étiquette : 1 à 63 caractères
• Longueur totale du domaine : 253 caractères maximum
• Doit avoir des enregistrements MX ou des enregistrements A valides pour la livraison des e-mails

Caractères autorisés dans les noms de domaine :

• Lettres (A-Z, a-z)
• Chiffres (0-9)
• Traits d’union (-) mais PAS au début ou à la fin des étiquettes

Exemples de domaines valides :

• `example.com` (domaine de base)
• `mail.company.co.uk` (sous-domaine avec code pays)
• `server-01.internal.org` (traits d’union et chiffres)

Exemples de domaines invalides :

• `-example.com` (commence par un trait d’union)
• `example-.com` (étiquette se termine par un trait d’union)
• `example` (pas de TLD)
• `example..com` (points consécutifs)

Pour qu’un e-mail puisse réellement recevoir des messages, le domaine doit avoir des enregistrements MX correctement configurés dans le DNS. Ces enregistrements indiquent aux serveurs d’envoi quels serveurs de messagerie gèrent les e-mails pour ce domaine.

4. Le domaine de premier niveau (TLD)

Le TLD est le segment final du nom de domaine après le dernier point. Les TLD entrent dans plusieurs catégories :

TLD génériques (gTLDs) :

• Originaux : .com, .org, .net, .edu, .gov
• Nouveaux gTLDs : .app, .dev, .io, .tech, .shop (plus de 1000 disponibles)

TLD de codes pays (ccTLDs) :

• Codes à deux lettres : .uk, .de, .jp, .au, .ca
• Souvent utilisés localement mais accessibles mondialement

Exigences de TLD valides :

• Minimum 2 caractères (historiquement)
• Les nouveaux gTLDs peuvent être plus longs : .technology, .international
• Doit être enregistré auprès de l’IANA
• Ne peut pas contenir uniquement des chiffres (dans la plupart des contextes)

La validation moderne doit accepter tout TLD enregistré auprès de l’IANA plutôt que de maintenir une liste codée en dur, car de nouveaux TLD sont régulièrement introduits.

Adresses e-mail valides

Adresses e-mail invalides

Distinction importante : Ces exemples montrent la validité syntaxique. Une adresse peut être syntaxiquement valide mais échouer à recevoir des e-mails si le domaine n’existe pas ou n’a pas de serveurs de messagerie.

Validation d’e-mail (Vérification de syntaxe)

Ce que c’est : Vérifier si une adresse e-mail suit les règles de format appropriées sans contacter de serveurs.

Ce qui est vérifié :

• Structure correcte ([email protected])
• Uniquement les caractères autorisés
• Placement correct des points
• Limites de longueur
• Format de domaine de base

Méthodes :

• Correspondance de motifs Regex
• Analyseurs de format
• Validation JavaScript côté client
• Vérification de syntaxe côté serveur

Vitesse : Instantanée (millisecondes)

Résultat : “Cette adresse est correctement formatée” ou “Cette adresse viole les règles de format”

Limitation : Ne peut pas déterminer si l’adresse existe réellement ou reçoit des e-mails.

Vérification d’e-mail (Vérification d’existence)

Ce que c’est : Confirmer qu’une adresse e-mail existe réellement et peut recevoir des messages.

Ce qui est vérifié :

• Le domaine a des enregistrements MX valides
• Le serveur de messagerie répond
• La boîte aux lettres existe (lorsque possible)
• Ce n’est pas une adresse jetable/temporaire connue
• Pas sur des listes noires

Méthodes :

• Recherches d’enregistrements MX DNS
• Connexions aux serveurs SMTP
• Protocoles de vérification de boîte aux lettres
• Vérifications de bases de données de délivrabilité

Vitesse : Plus lente (1 à 5 secondes par adresse)

Résultat : “Délivrable”, “Non livrable”, “Inconnu” ou “Risqué”

Limitation : Certains serveurs de messagerie bloquent les tentatives de vérification ; les résultats ne sont pas toujours précis à 100 %.

Pourquoi vous avez besoin des deux

Les systèmes d’e-mail intelligents utilisent d’abord la validation (rapide, élimine les erreurs évidentes) suivie de la vérification pour les adresses qui passent les contrôles de syntaxe. Cette approche en deux étapes :

• Prévient les fautes de frappe lors de la soumission du formulaire (validation)
• Réduit le taux de rebond (vérification)
• Maintient l’hygiène de la liste (vérification)
• Améliore la réputation de l’expéditeur (les deux)
• Améliore la délivrabilité (les deux)

Pour les entreprises qui collectent des adresses e-mail, la mise en œuvre des deux processus via des outils de vérification et de validation d’e-mail améliore considérablement la qualité des données.

1. Validation de formulaire trop restrictive

Problème : De nombreux sites Web utilisent des règles de validation obsolètes qui rejettent les adresses légitimes.

Restrictions courantes :

• Blocage des signes plus (+) utilisés pour le filtrage d’e-mails
• Rejet des nouveaux TLD comme .io, .app ou .dev
• Exigence d’au moins un point dans la partie locale
• Blocage des underscores ou des traits d’union

Solution : Mettez à jour les motifs regex de validation pour accepter tous les formats conformes à la RFC. Utilisez un analyseur de syntaxe d’e-mail complet au lieu de regex trop simplifiés.

2. Filtrage des caractères spéciaux

Problème : Les formulaires soucieux de la sécurité bloquent parfois des caractères spéciaux légitimes dans les adresses e-mail.

Souvent rejetés :

• `[email protected]` (filtrage du signe plus)
• `user%[email protected]` (pourcentage)
• `[email protected]` (underscore, rarement)

Solution : Distinguez la validation d’e-mail de la désinfection générale des entrées. Les adresses e-mail nécessitent leurs propres règles de validation spécialisées.

3. Restrictions sur les TLD

Problème : Les formulaires maintenant des listes de TLD codées en dur rejettent les domaines de premier niveau nouvellement introduits ou moins courants.

Exemples rejetés :

• `[email protected]`
• `[email protected]`
• `[email protected]`

Solution : Acceptez tout domaine avec une structure de TLD valide plutôt que de maintenir une liste blanche. Vérifiez la validité du TLD via une recherche de domaine plutôt qu’une correspondance de motif.

4. Limitations de longueur

Problème : Les champs de base de données ou de formulaire avec des limites de longueur arbitraires rejettent les adresses valides plus longues.

Problème : Définir un maximum de 50 caractères rejette des adresses comme :

• `[email protected]` (55 caractères)

Solution : Supportez le maximum de 320 caractères (64 partie locale + @ + 255 domaine). Les champs de base de données doivent utiliser VARCHAR(320) ou équivalent.

5. Motifs Regex incorrects

Problème : Les motifs regex simplifiés manquent des cas limites ou rejettent les formats valides.

Problèmes regex courants :

• Exiger au moins un point : `^[^@]+@[^@]+\.[^@]+$` (trop simple)
• Bloquer les points consécutifs dans les chaînes entre guillemets
• Ne pas gérer correctement les sous-domaines
• Définitions de classes de caractères incorrectes

Solution : Utilisez des bibliothèques de validation d’e-mail établies et conformes à la RFC plutôt que d’écrire des regex personnalisés. À titre de référence, un motif regex entièrement conforme s’étend sur des centaines de caractères.

6. Gestion des caractères Unicode/internationaux

Problème : Les formulaires ne prenant pas en charge les adresses e-mail internationalisées rejettent les adresses avec des caractères non ASCII.

Exemples :

• `mü[email protected]`
• `用户@domain.cn`

Solution : Implémentez le support RFC 6531 ou communiquez clairement les limitations ASCII uniquement aux utilisateurs.

Méthodes manuelles

1. Vérification visuelle de la syntaxe

Examinez l’adresse pour des erreurs évidentes :

• Un symbole @ est-il présent ?
• Des caractères avant et après le @ ?
• Le domaine a-t-il au moins un point ?
• Aucun espace ou caractère manifestement invalide ?

Utile pour des vérifications rapides sur place mais sujet aux erreurs pour les problèmes subtils.

2. Envoyer un e-mail de test

Le test définitif : envoyez un message et confirmez la réception.

Processus :

• Envoyer un e-mail à l’adresse
• Inclure un lien ou un code de confirmation
• Attendre l’action du destinataire
• Confirmer la délivrabilité

Avantages : 100 % précis pour la délivrabilité réelle
Inconvénients : Lent, nécessite la coopération du destinataire, risque de plaintes pour spam

3. Astuce de récupération de mot de passe

Vérification indirecte astucieuse :

• Allez sur un service que la personne utilise probablement (Gmail, LinkedIn, etc.)
• Entrez l’e-mail dans le flux “Mot de passe oublié”
• Le système indique “E-mail envoyé” ou “E-mail introuvable”

Note : Cela ne fonctionne que lorsque les services indiquent si un e-mail existe dans leur base de données. Beaucoup renvoient maintenant des messages génériques pour des raisons de sécurité.

Méthodes automatisées

1. Validation par motif Regex

Les expressions régulières vérifient la syntaxe sans appels externes.

Motif de base (simplifié) :

“`regex

^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$

“`

Motif plus complet (toujours simplifié) :

“`regex

^[a-zA-Z0-9!#$%&’+/=?^_`{|}~-]+(?:\.[a-zA-Z0-9!#$%&’+/=?^_`{|}~-]+)@(?:[a-zA-Z0-9](?:[a-zA-Z0-9-][a-zA-Z0-9])?\.)+[a-zA-Z0-9](?:[a-zA-Z0-9-]*[a-zA-Z0-9])?$

“`

Avantages : Rapide, fonctionne hors ligne, pas de dépendances externes
Inconvénients : Motifs complexes difficiles à maintenir, ne peut pas vérifier la délivrabilité, cas limites délicats

Meilleure pratique : Utilisez des bibliothèques établies plutôt que d’écrire des motifs regex personnalisés.

2. Services API

Les API de vérification d’e-mail vérifient la syntaxe et la délivrabilité.

Services populaires :

• ZeroBounce
• NeverBounce
• Kickbox
• Clearout
• EmailListVerify

Fonctionnalités typiques de l’API :

• Validation de syntaxe
• Vérification de domaine
• Vérification des enregistrements MX
• Détection d’e-mail jetable
• Identification des pièges à spam
• Vérification de l’existence de la boîte aux lettres

Avantages : Vérifications complètes, haute précision, rapide (1 à 3 secondes)
Inconvénients : Coûteux à grande échelle, nécessite une connexion Internet

3. Widgets de validation en temps réel

Bibliothèques JavaScript qui valident pendant que les utilisateurs tapent.

Fonctionnalités :

• Feedback de syntaxe instantané
• Détection de fautes de frappe dans le domaine (“gmial.com” → “gmail.com”)
• Avertissements d’e-mail jetable
• Indicateurs visuels (coche/X)

Bibliothèques populaires :

• Mailcheck.js (détection de fautes de frappe)
• Email-validator (syntaxe uniquement)
• Validator.js (inclut la validation d’e-mail)

Avantages : Excellente expérience utilisateur, prévient les erreurs avant la soumission
Inconvénients : Syntaxe uniquement (pas de vérification de délivrabilité), limitations côté client

4. Outils de vérification en masse

Pour valider de grandes listes d’e-mails (milliers à millions).

Processus :

1. Télécharger un fichier CSV/texte d’adresses
2. Le système traite en parallèle
3. Télécharger les résultats avec le statut de vérification

Les résultats incluent généralement :

• Statut valide/invalide
• Score de délivrabilité
• Niveau de risque (sûr/risqué/inconnu)
• Raison de l’invalidité

Cas d’utilisation :

• Maintien de l’hygiène de la liste d’e-mails
• Nettoyage de liste avant campagne
• Dédoublonnage de base de données
• Validation d’importation

La vérification en masse est essentielle pour maintenir l’hygiène de la liste d’e-mails et garantir des taux de délivrabilité élevés.

Pour les entreprises

1. Accepter tous les formats valides

Ne rejetez pas les adresses e-mail simplement parce qu’elles sont inhabituelles :

• Autoriser l’adressage par signe plus (`[email protected]`)
• Accepter tous les TLD valides
• Supporter les sous-domaines
• Autoriser les points, traits d’union, underscores selon les règles RFC

Mise en œuvre : Utilisez une bibliothèque de validation complète qui suit les normes RFC 5322 plutôt que des regex personnalisés.

2. Expérience utilisateur de validation en temps réel

Fournir un retour immédiat sans frustrer les utilisateurs :

Bonnes pratiques :

• Valider pendant que les utilisateurs tapent (avec un court délai)
• Afficher des messages d’erreur clairs expliquant les problèmes
• Suggérer des corrections pour les fautes de frappe courantes
• Utiliser des indicateurs visuels (couleur, icônes)
• Ne pas bloquer la soumission pour des délais de vérification

Mauvaises pratiques :

• Valider uniquement après la soumission du formulaire
• Erreurs génériques : “E-mail invalide”
• Bloquer l’adressage par signe plus sans explication
• Faux positifs rejetant des adresses valides

3. Mise en œuvre du double opt-in

Confirmer que les adresses e-mail appartiennent réellement aux utilisateurs :

Processus :

1. L’utilisateur soumet son e-mail
2. Le système envoie un e-mail de confirmation
3. L’utilisateur clique sur le lien de confirmation
4. L’adresse est marquée comme vérifiée

Avantages :

• Prévient les fautes de frappe dans votre base de données
• Confirme la délivrabilité
• Réduit les plaintes pour spam
• Améliore les métriques d’engagement
• Conformité légale (consentement RGPD)

4. Maintenir l’hygiène de la liste

Nettoyez régulièrement votre base de données d’e-mails :

Actions :

• Supprimer immédiatement les rebonds durs
• Marquer les adresses avec plusieurs rebonds doux
• Identifier et segmenter les utilisateurs inactifs
• Revérifier périodiquement les anciennes adresses
• Supprimer les adresses de rôle si nécessaire

Fréquence : Revérifier la liste entière tous les 6 à 12 mois ; contacts critiques trimestriellement.

Pour les utilisateurs

1. Choisir des adresses mémorables

Votre e-mail sert d’identité en ligne :

Conseils :

• Utilisez le format prénom.nom pour les contextes professionnels
• Restez simple pour le partage oral
• Évitez les nombres excessifs ou les caractères spéciaux
• Pensez à la longévité (les adresses scolaires expirent)

2. Considérations de sécurité

Bonnes pratiques :

• Utilisez un e-mail unique pour les comptes financiers
• Envisagez des adresses séparées pour les achats/newsletters
• Ne partagez pas votre e-mail publiquement (robots de collecte)
• Activez l’authentification à deux facteurs
• Utilisez des alias d’e-mail si vous vous souciez de la confidentialité

3. Adressage par signe plus pour le filtrage

Gmail et la plupart des fournisseurs supportent l’adressage par signe plus :

Format : `[email protected]`

Cas d’utilisation :

• `[email protected]` (filtrer par étiquette)
• `[email protected]` (désabonnement facile)
• `[email protected]` (suivre qui partage/vend des données)

Toutes les variantes arrivent à `[email protected]` mais permettent des règles de filtrage automatiques.

4. Gérer plusieurs adresses

Approche stratégique multi-adresses :

Structure :

• Professionnel : [email protected]
• Personnel : [email protected]
• Achats : [email protected]
• Tests : services jetables pour sites non fiables

Utilisez des clients de messagerie ou le transfert pour gérer plusieurs adresses depuis une seule boîte de réception.

Adresses e-mail internationalisées

La RFC 6531 (2012) a introduit la prise en charge Unicode dans les adresses e-mail, permettant les caractères non ASCII dans la partie locale et le domaine.

Exemples :

• `用户@例え.jp` (chinois/japonais)
• `Dörte@Sörensen.com` (umlauts allemands)
• `χρήστης@παράδειγμα.gr` (grec)
• `अजय@डाटा.भारत` (hindi)

État actuel :

• Support : Croissant mais incohérent
• Principaux fournisseurs : Gmail, Outlook supportent la réception ; l’envoi varie
• Défis : Compatibilité des systèmes hérités, limitations DNS

Recommandation : Les adresses ASCII restent plus universellement compatibles. Les adresses internationalisées fonctionnent mieux au sein de systèmes régionaux partageant des ensembles de langues/caractères.

Sous-adressage et filtrage

Au-delà de l’adressage par signe plus (+), certains systèmes supportent d’autres délimiteurs :

Variations :

• Plus : `[email protected]` (Gmail, Outlook, la plupart des fournisseurs)
• Trait d’union : `[email protected]` (Yahoo, certains fournisseurs)
• Underscore : Fonctionne parfois mais n’est pas standardisé

Filtrage avancé :

1. Créer des sous-adresses pour différents objectifs
2. Configurer des filtres/règles automatiques
3. Suivre quels services partagent votre e-mail
4. Identifier facilement les sources de spam
5. Supprimer en masse par filtre

Limitation : Les spammeurs sophistiqués suppriment l’adressage par signe plus avant de vendre des listes.

Adresses e-mail jetables

Les services d’e-mail temporaires fournissent des adresses de courte durée pour les situations nécessitant un e-mail sans engagement.

Services populaires :

• 10 Minute Mail
• Guerrilla Mail
• Temp Mail
• Mailinator

Cas d’utilisation valides :

• Tester la fonctionnalité d’e-mail
• Éviter le spam sur des sites non fiables
• Téléchargements uniques nécessitant une inscription
• Protéger la confidentialité pour les services non critiques

Considérations commerciales :

Les e-mails jetables sont syntaxiquement valides mais représentent des prospects de faible qualité. De nombreux services de vérification signalent les domaines jetables, permettant aux entreprises de :

• Bloquer les jetables à l’inscription
• Exiger un e-mail alternatif pour les comptes importants
• Segmenter les jetables pour un traitement différent

Adresses de rôle

Les adresses de rôle représentent des fonctions plutôt que des individus :

Exemples courants :

• `[email protected]`
• `[email protected]`
• `[email protected]`
• `[email protected]`
• `[email protected]`

Caractéristiques :

• Souvent des boîtes aux lettres partagées
• Taux d’engagement plus faibles
• Requises pour les opérations commerciales
• Soumises à des règles anti-spam différentes

Perspective commerciale :

Certaines réglementations de marketing par e-mail découragent l’envoi de contenu promotionnel aux adresses de rôle sans opt-in explicite.

Domaines Catch-All

Les configurations catch-all acceptent les e-mails à TOUTE adresse d’un domaine, même celles qui n’existent pas.

Comment ça marche :

• Le domaine est configuré pour accepter tous les e-mails : `*@example.com`
• `[email protected]` → livré à la boîte aux lettres catch-all
• Souvent utilisé par les petites entreprises pour ne jamais manquer d’e-mails

Défi de vérification :

Les domaines catch-all signalent toujours les adresses comme “valides” lors de la vérification car le serveur accepte tous les destinataires. Les services de vérification signalent généralement ces adresses comme ayant un statut “inconnu” car la délivrabilité réelle ne peut pas être confirmée.

Erreurs “Adresse e-mail non valide”

Quand vous voyez ceci :

Votre e-mail est rejeté alors que vous savez qu’il fonctionne.

Solutions :

1. Vérifiez les fautes de frappe (points consécutifs, @ manquant, espaces finaux)
2. Supprimez temporairement l’adressage par signe plus
3. Essayez un e-mail alternatif si vous utilisez un TLD peu courant
4. Contactez le support du site Web en citant la conformité RFC 5322
5. Utilisez un autre e-mail comme solution de contournement

Si vous êtes développeur :

Examinez la regex de validation par rapport aux normes RFC 5322. Envisagez d’utiliser des bibliothèques établies comme `validator.js` ou `email-validator` au lieu de motifs personnalisés.

Pourquoi Gmail ignore les points

Question : Pourquoi `[email protected]` et `[email protected]` livrent-ils dans la même boîte aux lettres ?

Réponse : Gmail ignore intentionnellement les points dans la partie locale pour des raisons d’utilisabilité. Tous ces éléments arrivent dans la même boîte de réception :

• `[email protected]`
• `[email protected]`
• `[email protected]`

Implication : Vous pouvez donner différentes “versions” de votre adresse et filtrer par champ destinataire, mais ce n’est pas une fonctionnalité de sécurité : elles arrivent toutes au même endroit.

Le signe plus ne fonctionne pas

Problème : Utilisation de `[email protected]` mais il est rejeté ou ne filtre pas correctement.

Causes :

1. Le site Web bloque les signes plus : Courant mais non conforme à la RFC
2. Votre fournisseur ne le prend pas en charge : Moins courant ; Gmail/Outlook le font
3. Filtre non configuré : Vous devez créer manuellement des règles de filtrage

Solutions :

• Solution de contournement : Utilisez un trait d’union si le fournisseur le prend en charge
• Contactez le site Web pour corriger la validation
• Créez manuellement un filtre pour les e-mails entrants

Problèmes de caractères internationaux

Problème : Caractères accentués ou non latins rejetés.

Réalité :

• La RFC 6531 prend en charge les caractères internationaux
• De nombreux systèmes n’ont pas implémenté le support
• L’ASCII reste le plus compatible

Solutions :

• Utilisez l’équivalent ASCII si disponible
• Demandez au fournisseur son support international
• Utilisez un autre e-mail pour les services nécessitant de l’ASCII
• Signalez la limitation au fournisseur de services

“Cet e-mail existe déjà”

Problème : Impossible de s’inscrire car l’e-mail est déjà enregistré.

Causes possibles :

1. Vous avez un ancien compte oublié
2. Quelqu’un a mal tapé son e-mail (le vôtre)
3. Une violation de données a conduit à des comptes pré-enregistrés
4. Une variante d’adressage par signe plus est déjà utilisée

Solutions :

• Utilisez la récupération de mot de passe pour retrouver l’accès
• Essayez une variante d’adressage par signe plus : `[email protected]`
• Contactez le support pour vérifier/supprimer l’ancien compte
• Utilisez une autre adresse e-mail

L’e-mail fonctionne mais la vérification échoue

Problème : Vous recevez normalement des e-mails mais les outils de vérification signalent “invalide.”

Causes :

1. Problèmes temporaires de serveur : Enregistrements MX temporairement inaccessibles
2. Blocage de la vérification : Le serveur de messagerie bloque les tentatives de vérification
3. Domaine catch-all : Le serveur accepte toutes les adresses, la vérification est incertaine
4. Greylisting : Rejet temporaire nécessitant une nouvelle tentative

Solutions :

• Réessayez la vérification après 24 heures
• Vérifiez la délivrabilité en envoyant un e-mail de test
• Vérifiez directement les enregistrements MX DNS
• Acceptez l’incertitude de vérification pour les domaines catch-all

Services de validation recommandés

Pour la validation en temps réel :

• Abstract API – API simple, syntaxe + délivrabilité
• Clearout – Widget en temps réel + API
• Kickbox – Détection d’e-mails jetables + vérification

Pour la vérification en masse :

• ZeroBounce – Nettoyage de liste d’e-mails + scoring
• NeverBounce – Vérification de liste à haut volume
• BriteVerify – Options en temps réel + en masse

Validateurs gratuits à essayer

Outils de syntaxe uniquement :

• Testeur Regex d’e-mail (regex101.com)
• Validateur de format d’e-mail (freeformatter.com)
• Vérification rapide d’e-mail (quickemailverification.com – niveau gratuit limité)

Vérification d’e-mail unique :

• Email Checker (email-checker.net)
• Vérifier l’adresse e-mail (verifalia.com – niveau gratuit)
• Mail Tester (mail-tester.com)

Ressources pour développeurs

Bibliothèques de validation :

JavaScript :

“`javascript

// Utilisation de validator.js

import validator from ‘validator’;

validator.isEmail(‘[email protected]’); // true

“`

Python :

“`python

Utilisation de email-validator

from email_validator import validate_email, EmailNotValidError

try:

v = validate_email(“[email protected]”)

email = v[“email”] # forme normalisée

except EmailNotValidError as e:

print(str(e))

“`

PHP :

“`php

// Utilisation du filtre intégré

if (filter_var($email, FILTER_VALIDATE_EMAIL)) {

// Syntaxe valide

}

“`

Ruby :

“`ruby

Utilisation du gem valid_email2

require ‘valid_email2’

ValidEmail2::Address.new(“[email protected]”).valid? # true

“`

Documentation RFC

RFC clés :

• RFC 5321 – Simple Mail Transfer Protocol (SMTP)
• RFC 5322 – Internet Message Format (syntaxe des adresses e-mail)
• RFC 6531 – Internationalized Email
• RFC 3696 – Application Techniques for Checking and Transformation

Accès : Recherchez “[numéro RFC] ietf.org” ou visitez tools.ietf.org/html/rfcXXXX

Qu’est-ce qui rend une adresse e-mail invalide ?

Une adresse e-mail est invalide si elle viole les règles de format RFC 5322 : symbole @ manquant, pas de partie locale ou de domaine, points consécutifs dans la partie locale, caractères interdits, dépassement des limites de longueur (320 caractères au total), ou structure de domaine mal formée. Les exemples courants d’adresses invalides incluent celles avec des espaces, plusieurs symboles @, ou des domaines de premier niveau manquants.

Les adresses e-mail peuvent-elles contenir des espaces ?

Non, les adresses e-mail ne peuvent pas contenir d’espaces sous forme non entre guillemets. Les espaces dans la partie locale (avant le @) nécessitent que toute la partie locale soit entourée de guillemets doubles : `”nom d’utilisateur”@example.com`. Cependant, les adresses entre guillemets sont rarement prises en charge par les systèmes modernes, et la plupart des fournisseurs de messagerie les rejettent malgré leur validité technique selon la RFC 5322.

Les lettres majuscules sont-elles autorisées dans les adresses e-mail ?

Oui, la RFC 5321 spécifie techniquement que les adresses e-mail sont sensibles à la casse. Cependant, pratiquement tous les fournisseurs de messagerie modernes traitent les adresses comme insensibles à la casse en pratique. `[email protected]` et `[email protected]` livrent dans la même boîte aux lettres sur Gmail, Outlook, Yahoo et la plupart des autres services. Meilleure pratique : traitez les adresses comme insensibles à la casse.

Quelle est la longueur maximale d’une adresse e-mail ?

La longueur maximale d’une adresse e-mail est de 320 caractères au total : jusqu’à 64 caractères pour la partie locale (avant le @), plus le symbole @ (1 caractère), plus jusqu’à 255 caractères pour le nom de domaine. Les noms de domaine ont également des restrictions par étiquette (63 caractères maximum par étiquette entre les points).

Tous les domaines d’e-mail acceptent-ils tous les formats valides ?

Non. Bien que la RFC 5322 définisse la syntaxe valide, les serveurs de messagerie individuels peuvent implémenter des règles plus strictes. Certains fournisseurs rejettent l’adressage par signe plus, les chaînes entre guillemets ou les caractères spéciaux peu courants malgré leur validité technique. De plus, certains services bloquent les domaines d’e-mail jetables, les adresses de rôle, ou implémentent des restrictions personnalisées pour des raisons de sécurité ou de politique.

Comment puis-je vérifier si une adresse e-mail existe ?

Envoyez un e-mail de test et confirmez la réception, ou utilisez des services de vérification d’e-mail qui vérifient les enregistrements MX et interrogent les serveurs de messagerie. Les API de vérification (ZeroBounce, NeverBounce, Kickbox) peuvent déterminer le statut de délivrabilité. Notez que certains serveurs de messagerie bloquent les tentatives de vérification, et les domaines catch-all acceptent toutes les adresses, rendant la confirmation d’existence définitive impossible dans certains cas.

Qu’est-ce que la validation de syntaxe d’e-mail ?

La validation de syntaxe d’e-mail est le processus de vérification si une adresse e-mail suit les règles de format appropriées sans tenter de livraison. Elle vérifie la structure correcte ([email protected]), les caractères autorisés, le placement correct des points et les limites de longueur. La validation de syntaxe se produit instantanément et détecte les erreurs évidentes, mais ne peut pas confirmer si l’adresse existe réellement ou reçoit des e-mails.

Puis-je utiliser des caractères spéciaux dans mon adresse e-mail ?

Oui, la partie locale des adresses e-mail peut contenir ces caractères spéciaux : `! # $ % & ‘ * + – / = ? ^ _ ` { | } ~` plus les points (avec restrictions). La partie domaine n’autorise que les lettres, les chiffres, les traits d’union et les points. Cependant, certains sites Web rejettent incorrectement les caractères spéciaux valides, en particulier les signes plus utilisés pour le filtrage d’e-mails.

Que sont les adresses e-mail jetables ?

Les adresses e-mail jetables sont des adresses temporaires fournies par des services comme 10 Minute Mail ou Guerrilla Mail qui expirent automatiquement après un certain temps. Elles sont syntaxiquement valides et reçoivent les e-mails normalement pendant leur durée de vie. Les utilisateurs les emploient pour éviter le spam sur des sites non fiables, tandis que les entreprises bloquent souvent les domaines jetables connus pour garantir des informations de contact de qualité.

Comment valider des adresses e-mail en masse ?

Utilisez des services de vérification d’e-mail en masse (ZeroBounce, NeverBounce, EmailListVerify) qui traitent de grandes listes. Téléchargez un fichier CSV ou texte contenant les adresses, et le service valide la syntaxe et vérifie la délivrabilité de chaque entrée, traitant généralement des milliers par minute. Les résultats incluent le statut de validité, les scores de délivrabilité et les niveaux de risque. La vérification en masse régulière maintient l’hygiène de la liste et améliore la réputation de l’expéditeur.

Pourquoi mon e-mail valide est-il rejeté sur certains sites Web ?

La plupart des rejets d’e-mails valides se produisent en raison de règles de validation de site Web trop restrictives qui ne sont pas entièrement conformes à la RFC 5322. Les causes courantes incluent le blocage des signes plus (+), le rejet des nouveaux TLD (.io, .app), l’exigence de points dans les parties locales, ou l’utilisation de motifs regex obsolètes. Essayez de supprimer les caractères spéciaux, d’utiliser temporairement une adresse .com, ou de contacter le support du site Web pour signaler le problème de validation.

Quelle est la différence entre la validation et la vérification d’e-mail ?

La validation d’e-mail vérifie la syntaxe et les règles de format (instantanée, hors ligne, gratuite), confirmant que l’adresse est correctement structurée. La vérification d’e-mail vérifie la délivrabilité réelle en interrogeant les enregistrements DNS et les serveurs de messagerie (plus lente, nécessite Internet, souvent payante), confirmant que l’adresse existe et reçoit des e-mails. Une gestion efficace des e-mails utilise d’abord la validation pour détecter les erreurs évidentes, puis la vérification pour les adresses passant les contrôles de syntaxe.