« La vérification d'e-mails » semble simple. En pratique, c'est une négociation avec des milliers de serveurs de messagerie aux comportements très différents : Google qui limite le débit de votre IP, Microsoft qui renvoie des blocages de politique, Yahoo qui exige un recours à Verifly, et les serveurs catch-all qui répondent oui à tout.
Voici exactement ce qui se passe lorsque vous cliquez sur Vérifier dans Email Validator.
Étape 1 : syntaxe et nettoyage
Avant tout appel réseau :
- Supprimer les caractères Unicode invisibles (espaces de largeur nulle, BOM)
- Valider le format RFC 5322
- Normaliser les points Gmail (
john.doe@gmail.com→ dedup key) - Vérifier la liste de blocage des domaines jetables (plus de 10 000 domaines)
- Vérifier les motifs de pièges à spam
Échec à cette étape → invalides ou jetable — aucune requête SMTP nécessaire, aucun crédit débité.
Étape 2 : recherche MX DNS
Nous interrogeons le DNS pour les enregistrements MX. Sans MX → invalides (le domaine ne peut pas recevoir de courrier).
La priorité MX détermine le serveur que nous sondons en premier. Plusieurs hôtes MX sont essayés avec une rotation d'IP sur nos pools GRE/Hetzner.
Étape 3 : dialogue SMTP
Séquence de sondage typique :
>>> EHLO verify.email-validaton.com
<<< 250 OK
>>> MAIL FROM:<verify@email-validaton.com>
<<< 250 OK
>>> RCPT TO:<cible@company.com>
<<< 250 OK ← ou 550 / 552 / 450
>>> RCPT TO:<aleatoirefaux@company.com> ← catch-tous test
<<< 550 ← bon: serveur rejette faux
Détection catch-all :si l'adresse fictive reçoit aussi 250, le domaine est en catch-all : la boîte individuelle n'est pas confirmée.
Étape 4 : classification des réponses
Notre classificateur associe le texte SMTP à des statuts :
| Schéma de réponse | Statut |
|---|---|
| 250 sur la vraie adresse, 550 sur la fictive | valide |
| 250 sur les deux | catch_all |
| 550 utilisateur inconnu | invalides |
| 552 mailbox full | over_quota |
| Indices 450 / greylist | risqué (nouvelle tentative) |
| Blocage par politique, résultat non concluant | risqué ou inconnu |
Étape 5 : traitement spécifique aux fournisseurs
Certains fournisseurs ne peuvent pas être vérifiés de manière fiable via SMTP brut :
- Yahoo / AOL → repli sur l'API Verifly
- Mail.ru → Verifly avec la correspondance spécifique à Mail.ru
- Google 452 / 552 quota dépassé →
over_quota(mailbox exists but is not accepting mail)
Nous ne marquons jamais valide à moins que le niveau de confiance ne soit élevé.
Étape 6 : mise en cache et crédits
Résultats définitifs (valid, invalid, catch_all, over_quota, disposable) cache per user — repeat checks within TTL skip SMTP.
Facturables : valid, invalid, over_quota, disposable
Gratuits : catch_all, risky, unknown, error
Échecs internes des contrôles (rate_limited) map to inconnu avant que vous ne les voyiez — les clients ne sont jamais facturés pour les états d'infrastructure non concluants.
Pourquoi c'est important pour votre liste
Comprendre la vérification SMTP explique pourquoi :
- Un catch-all n'est pas « valide » — le protocole ne peut tout simplement pas prouver l'existence de la boîte
- Boîte pleine n'est pas invalide — la boîte existe
- Les adresses risquées doivent être revérifiées — le greylisting est temporaire
- Le même moteur alimente la vérification unitaire, en masse, l'API et Company Finder
Voir en direct — Essayer la vérification unitaire →
Voir aussi : Explication des catch-all · Guide des statuts
