Accueil › Vérifier une adresse email
Vérifier une adresse email valide
En résumé : collez une adresse, la syntaxe RFC 5322 est contrôlée instantanément dans votre navigateur ; la présence d'un serveur de messagerie (MX) et la détection des domaines jetables passent par l'API, avec 100 vérifications offertes. Ce qu'on ne fait pas — et qu'aucun outil honnête ne fait vraiment — c'est jurer qu'une boîte précise existe sans envoyer de message.
Dernière mise à jour : juillet 2026.
Syntaxe RFC, domaine, MX, détection jetable et adresses génériques.
« Email valide » veut dire trois choses différentes
La plupart des services affichent un unique badge « valide / invalide ». C'est trompeur : il y a trois questions distinctes, de plus en plus dures à répondre, et la dernière est hors de portée de tout outil qui n'envoie pas de message.
| Niveau | Question | Comment on le sait | Où c'est fait |
|---|---|---|---|
| 1. Syntaxe | L'adresse est-elle bien formée ? | Regex RFC 5322, hors ligne | Navigateur, instantané |
| 2. Domaine | Le domaine peut-il recevoir du courrier ? | Requête DNS : MX, sinon A/AAAA | API (requête réseau) |
| 3. Boîte | Cette boîte précise existe-t-elle ? | Dialogue SMTP (RCPT TO) — non fiable | Personne ne le fait proprement |
Notre verdict « valide » couvre les niveaux 1 et 2 : syntaxe conforme + domaine qui a un serveur de messagerie, et non jetable. C'est ce qui élimine l'écrasante majorité des rebonds. Le niveau 3, on l'annonce comme inatteignable plutôt que de le simuler.
Pourquoi on ne fait pas de sondage SMTP (RCPT TO)
La seule façon technique de « demander » à un serveur si une boîte existe, c'est d'ouvrir une connexion SMTP et d'envoyer RCPT TO:<adresse> sans jamais finir l'envoi (le fameux SMTP callout). Sur le papier, un code 550 dit « inconnue » et 250 dit « existe ». En pratique, trois murs :
- Les serveurs catch-all disent oui à tout. Beaucoup de PME et d'hébergements mutualisés acceptent n'importe quelle adresse du domaine puis trient après coup. nimportequoi@leur-domaine.fr répond 250 OK. Le test valide alors des adresses qui n'existent pas.
- Gmail et Outlook brouillent la réponse exprès. Pour empêcher la collecte de comptes, les gros fournisseurs renvoient un accept générique quel que soit l'état réel de la boîte. Le RCPT TO n'y apprend rien.
- Sonder grille l'IP. Multiplier les connexions RCPT TO depuis une même IP la fait inscrire sur des listes anti-abus (Spamhaus PBL/SBL, greylisting RFC 6647). Résultat : ce sont ensuite vos vrais emails qui partent en spam. Vérifier casserait ce qu'on prétend protéger.
Notre parti pris, le même que sur nos pages SIRET et IBAN : dire franchement où s'arrête la certitude. On contrôle la forme et le domaine, pas l'existence de la boîte. Un service qui vous promet du 100 % « email existe » sur du volume, soit il ment, soit il grille votre réputation.
Adresses jetables et adresses génériques : deux drapeaux
Une adresse peut être parfaitement valide (syntaxe + MX) et pourtant sans valeur pour vous. Deux catégories que l'API signale distinctement :
Jetables / temporaires
Boîtes à usage unique créées pour franchir un formulaire puis abandonnées : yopmail.com, mailinator.com, jetable.org, guerrillamail.com… Le domaine a bien un MX (le test « domaine » passe), mais l'inscrit est déjà parti : l'email marketing ne sera jamais lu. Drapeau disposable.
Génériques / role-based
Adresses de fonction, pas de personne : contact@, info@, admin@, postmaster@… La RFC 2142 en normalise une liste (postmaster, abuse, webmaster, hostmaster). Pour du nominatif, elles génèrent plus de plaintes et de désabonnements. Drapeau roleBased.
On signale plutôt qu'on ne bloque : contact@ est parfois la seule adresse d'un prospect B2B légitime. À vous d'en faire un critère de score. La page dédiée détecter et bloquer les emails jetables détaille la méthode anti-fraude à l'inscription.
À quoi ça sert, concrètement
Nettoyer une base avant campagne. Vous avez importé 4 000 contacts d'un vieux CRM. Passez-les à la validation : les domaines morts, les fautes de frappe (@gmail.con, @hotmail.fr sans MX) et les jetables ressortent avant l'envoi, pas après le rebond.
Réduire le taux de rebond. Les routeurs surveillent le bounce dur ; au-delà de quelques pour cent, ils avertissent puis suspendent. Retirer en amont ce qui rebondit protège la délivrabilité de toute votre liste, pas seulement de la campagne.
Protéger un formulaire d'inscription. Un appel API à la volée sur le champ email refuse la syntaxe cassée, signale le jetable et le role-based — moins de faux comptes, une base plus propre dès l'entrée.
Vérifier des emails en masse
Le widget ci-dessus fait une adresse à la fois, format seul, sans compte. Pour le MX, la détection jetable et surtout le volume, deux voies :
- →Un fichier à passer d'un coup ? Le nettoyeur de liste (CSV) traite une colonne entière et vous rend chaque ligne annotée du motif de rejet.
- →Dans votre code, l'endpoint REST renvoie syntaxe, MX, disposable et roleBased en JSON :
curl -X POST https://data-checker.fr/api/v1/validate \
-H "Authorization: Bearer dck_live_votreCle" \
-H "Content-Type: application/json" \
-d '{"type":"email","value":"contact@exemple.fr"}'Réponse : valid, syntaxValid, mxFound, disposable, roleBased, credits_remaining. Détail dans la documentation.
Questions fréquentes
Une adresse email valide existe-t-elle forcément ?
Non. « Valide » a trois sens qu'on confond souvent. 1) Syntaxe correcte : l'adresse respecte la RFC 5322, on peut le vérifier hors ligne. 2) Domaine capable de recevoir : le domaine a un enregistrement MX (ou un A/AAAA de secours), on le vérifie par une requête DNS. 3) Boîte réellement existante : jean.dupont@gmail.com correspond bien à un compte ouvert. Seul le niveau 3 prouve l'existence, et il n'est pas atteignable de façon fiable sans envoyer un message. Une adresse peut passer les niveaux 1 et 2 et pointer sur une boîte qui n'a jamais été créée.
Peut-on vérifier un email sans en envoyer un ?
Oui pour la forme et le domaine, non pour l'existence de la boîte. La syntaxe (RFC 5322) et la présence d'un serveur de messagerie (MX en DNS) se contrôlent sans envoyer le moindre message. En revanche, savoir si contact@exemple.fr désigne une boîte réelle exige de dialoguer avec le serveur SMTP du domaine (commande RCPT TO) — une manœuvre intrusive et peu fiable qu'on ne fait pas, pour les raisons détaillées plus bas.
Pourquoi ne faites-vous pas de vérification SMTP (RCPT TO) ?
Parce qu'elle ment souvent et qu'elle grille votre IP. Trois obstacles concrets. Les serveurs en catch-all (fréquent chez les PME et sur les hébergements mutualisés) répondent 250 OK à toutes les adresses, existantes ou non : le test « valide » n'importe quoi. Gmail et Outlook renvoient volontairement un accept générique pour empêcher l'énumération de leurs comptes. Et sonder des centaines d'adresses depuis une même IP la fait classer sur des listes anti-spam (Spamhaus PBL/SBL), ce qui pénalise ensuite VOS envois. Un « vérificateur SMTP » vend une certitude qu'il n'a pas.
Quelle différence entre email « valide » et email « délivrable » ?
Valide décrit la structure ; délivrable décrit ce qui se passe à l'arrivée. Un contrôle MX prouve qu'il existe un serveur pour recevoir le courrier du domaine — pas que votre message franchira son filtre anti-spam, ni que la boîte n'est pas pleine, désactivée ou en congé. La délivrabilité dépend aussi de votre réputation d'expéditeur, de votre SPF/DKIM/DMARC et du contenu. La validation réduit les rebonds durs (domaine mort, syntaxe cassée) ; elle ne garantit pas l'inbox.
Un domaine sans MX peut-il quand même recevoir du courrier ?
Oui, dans un cas précis. La RFC 5321 (§5.1) prévoit qu'en l'absence d'enregistrement MX, le serveur émetteur se rabat sur l'enregistrement A ou AAAA du domaine, traité comme un MX implicite de priorité 0. Un petit domaine sans MX mais avec une IP qui écoute sur le port 25 reçoit donc son courrier. C'est pourquoi un bon contrôle regarde le MX puis, à défaut, le A/AAAA — sinon on rejette à tort des domaines qui reçoivent bel et bien.
Comment réduire le taux de rebond (bounce) d'une campagne ?
En retirant avant l'envoi les trois familles qui rebondissent à coup sûr : syntaxe cassée, domaines sans serveur de messagerie, et domaines jetables (l'inscrit est déjà parti). C'est exactement ce que fait la validation en amont. Les routeurs (Mailchimp, Brevo, SendGrid…) surveillent le taux de rebond dur ; passé quelques pour cent, ils avertissent ou suspendent l'envoi, car un fort taux de bounce dégrade la réputation de tout le monde. Nettoyer la liste protège vos futurs envois autant que la campagne du jour.
Faut-il bloquer les adresses génériques comme contact@ ou info@ ?
Pas bloquer — signaler. Ces adresses « role-based » (RFC 2142 en normalise une liste : postmaster, abuse, webmaster, hostmaster…) pointent souvent vers plusieurs personnes ou une boîte partagée. Pour une inscription individuelle ou un envoi marketing nominatif, c'est un signal de qualité faible (désabonnements, plaintes plus fréquentes). Pour un contact commercial B2B, contact@ est parfois la seule adresse publique. La réponse de l'API expose le drapeau roleBased : à vous d'en faire un critère de score, pas un rejet automatique.
Références : format d'adresse (RFC 5322), transport et MX implicite (RFC 5321 §5.1), adresses de fonction (RFC 2142), greylisting (RFC 6647).
À contrôler aussi : un numéro de téléphone (format international, type de ligne), un SIRET (existence réelle), un IBAN (clé mod-97). Pour tout intégrer, la documentation de l'API.