Validation SMTP expliquée : comment fonctionnent réellement les validateurs d'e-mails

La plupart des vérificateurs d'e-mails affirment être précis. Peu expliquent comment ils vérifient réellement une adresse.

Voici cette explication.

Qu'est-ce que SMTP ?

SMTP = Simple Mail Transfer Protocol
C'est le langage que les serveurs de messagerie utilisent pour envoyer et recevoir des e-mails.

Lorsque vous envoyez un e-mail :
1. Votre client se connecte à un serveur SMTP
2. Envoie MAIL FROM: you@yourcompany.com
3. Envoie RCPT TO: recipient@their.com
4. Le serveur répond 250 OK (yes, we accept it) or 550 Reject (no, we don't)
5. Le client envoie le corps du message

Validation SMTP : la vérification réelle

Validation SMTP simule les étapes 1 à 4 sans envoyer l'e-mail réel.

C'est pourquoi c'est le seul moyen de savoir si une boîte aux lettres existe réellement.

La poignée de main SMTP

atterrissent Client: EHLO mail.validateur.com
← Serveur: 250 OK ESMTP

atterrissent Client: MAIL FROM:<validateur@mail.validateur.com>
← Serveur: 250 OK

atterrissent Client: RCPT TO:<test@gmail.com>
← Serveur: 250 OK
     (Les configurations catch-all ne sont pas une erreur. Elles répondent à des besoins professionnels légitimes : existe et accepte mail)

atterrissent Client: QUIT
← Serveur: 221 Bye

Si le RCPT TO returns 250, l'adresse est Valide.
Si elle renvoie 550, l'adresse est Les e-mails invalides.
Si le serveur ne répond pas, c'est À risque ou Inconnu.

Pourquoi les autres méthodes échouent

❌ Vérification de la syntaxe uniquement

test@example.com ✅ (semble bon)
test.12345@example.com ❌ (pourrait Paiement Lemon Squeezy : existe)

La syntaxe est correcte mais nous ne savons pas si la boîte aux lettres existe.

❌ Vérification des enregistrements MX uniquement

Domaine: gmail.com atterrissent MX: aspmx.l.google.com (oui, existe)
Mais la boîte mail était-elle réelle ?: fait test@gmail.com vraiment existe ? Inconnu.

✅ Validation SMTP

Connexion à gmail SMTP atterrissent RCPT TO test@gmail.com
← 550 Aucune tel user
Résultat: INVALIDE (Les configurations catch-all ne sont pas une erreur. Elles répondent à des besoins professionnels légitimes : ne't existe)

Le défi : les domaines Catch-All

Certains serveurs (surtout les plus anciens) répondent « oui » à chaque adresse :

atterrissent RCPT TO: realuser@company.com
← 250 OK

atterrissent RCPT TO: fakeuser123456789@company.com
← 250 OK (aussi accepté!)

Ce sont domaines catch-all. La vérification SMTP seule ne permet pas de savoir si l'adresse est réelle.

Avancé : scoring et détection catch-all

Les meilleurs validateurs combinent SMTP et d'autres signaux :

• Réputation du domaine — le serveur de messagerie est-il connu pour rejeter les messages ?
• Activité récente — ce domaine était-il actif au cours des 90 derniers jours ?
• Contrôles honeypot — s'agit-il d'un piège à spam connu ?
• Indicateur risqué + catch-all — « Valide par SMTP mais pourrait être catch-all »

Score de 0 à 10 = niveau de confiance, et non simplement réussite ou échec.

Vitesse vs précision

Pourquoi la validation SMTP est importante

✅ Protège la réputation d'expéditeur — vérifiez avant d'envoyer
✅ Réduit les taux de rebond — le SMTP détecte les adresses invalides avant l'envoi
✅ Économise des crédits — ne payez pas votre ESP pour des e-mails rejetés
✅ Améliore la délivrabilité — les FAI récompensent un envoi propre

Comment vérifier soi-même (développeurs uniquement)

import smtplib

domaine = "gmail.com"
try:
    smtp = smtplib.SMTP(f"mx.{domaine}")
    smtp.mail("test@validator.com")
    code, msg = smtp.rcpt("recipient@gmail.com")
    if code == 250:
        print("Valid")
    else:
        print("Invalid")
    smtp.quit()
except:
    print("Risky/Unknown")

Mais en production, utilisez un service. La validation SMTP à grande échelle est complexe (pare-feu, limites de débit, délais).

SMTP en détail

SMTP est un protocole textuel. Une session est une courte conversation composée d'une suite de commandes et de réponses numériques. Pour la validation, seule la première moitié compte : la partie qui précède l'envoi de tout corps de message.

Ports et TLS

• 25 — le port classique de serveur à serveur. Souvent bloqué par les hébergeurs pour lutter contre le spam, c'est pourquoi les services de validation s'appuient sur une infrastructure dédiée.
• 465 — TLS implicite (SMTPS).
• 587 — port de soumission avec STARTTLS, utilisé par les clients de messagerie.

Un validateur doit pouvoir atteindre le port 25 du serveur MX du destinataire. Si votre propre serveur ne peut pas joindre le port 25, vous ne pouvez pas effectuer de vérifications SMTP fiables vous-même : c'est la raison la plus courante pour laquelle les équipes externalisent la vérification.

EHLO, MAIL FROM, RCPT TO

atterrissent EHLO validateur.example.com
← 250-mail.example.com
← 250-PIPELINING
← 250 SIZE 35882577

atterrissent MAIL FROM:<de la syntaxe@validator.example.com>
← 250 OK

atterrissent RCPT TO:<person@example.com>
← 250 OK

EHLO opens the session and asks which extensions the server supports. MAIL FROM declares the envelope sender. RCPT TO is the actual test: the server accepts or rejects the recipient. QUIT ends the session.

Le point essentiel : RCPT TO reçoit une réponse avant l'envoi de toute donnée de message. C'est ce qui rend la validation possible sans jamais délivrer de courrier.

Interpréter les codes de réponse SMTP

Un validateur qui considère chaque réponse autre que 250 comme « invalide » est erroné : les codes 4xx sont temporaires et se résolvent souvent lors d'une nouvelle tentative.

Pourquoi les vérifications de syntaxe et de MX ne suffisent pas

Ces deux contrôles sont peu coûteux et utiles comme premier filtre, mais aucun ne peut répondre à la seule question qui compte : cette boîte aux lettres accepte-t-elle les messages ?

• Syntaxe indique que la chaîne ressemble à une adresse. Il ne peut pas détecter que l'entreprise a fermé.
• MX indique que le domaine dispose d'un serveur de messagerie. Il ne peut pas détecter que person@ was never created.
• SMTP dialogue avec ce serveur et interroge ce destinataire précis. Seule cette étape fournit une réponse réelle.

En pratique, une liste qui réussit les contrôles de syntaxe et de MX peut tout de même provoquer 20 à 30 % de rebonds. C'est pourquoi les outils « vérificateur d'e-mails gratuit » qui se contentent d'expressions régulières sont populaires, mais inutiles pour l'optimisation de la délivrabilité.

Domaines à acceptation totale en détail

Un serveur en mode catch-all est configuré pour accepter les messages destinés à n'importe quelle partie locale. Il s'agit d'une configuration légitime (les entreprises l'utilisent pour que une faute de frappe dans l'adresse d'un prospect ne disparaisse pas silencieusement), mais elle rend la validation SMTP impossible.

Comment gérer les domaines catch-all :

1. Les détecter. Envoyez une sonde à une partie locale aléatoire et manifestement fausse. Si elle renvoie également 250, le domaine est catch-all.
2. Signaler, ne pas supprimer. Les adresses catch-all appartiennent souvent à de vraies personnes. Les supprimer peut coûter 5 à 15 % d'une liste B2B.
3. Envoyer par petits lots et mesurer les ouvertures et les rebonds. Si un segment catch-all performe, conservez-le.
4. Utiliser des signaux supplémentaires (réputation du domaine, historique d'engagement et reconnaissance de schémas) pour classer les adresses catch-all.

Greylisting, limitation de débit et protection contre la collecte d'adresses

Les vrais serveurs mail ne sont pas des bancs d'essai. Attendez-vous à :

• Greylisting — le serveur rejette temporairement les expéditeurs inconnus avec un code 4xx et attend une nouvelle tentative. Les services de validation réessaient automatiquement.
• Limitation de débit — un trop grand nombre de connexions depuis une même IP est ralenti. Les bons fournisseurs répartissent les vérifications entre plusieurs IP et dans le temps.
• Anti-collecte — certains serveurs répondent délibérément de façon ambiguë à quiconque sonde un grand nombre d'adresses.
• Pièges à spam — adresses qui n'existent que pour détecter les expéditeurs en masse. Un bon validateur les signale.

C'est pourquoi les scripts de validation maison fonctionnent sur dix adresses mais s'effondrent sur dix mille.

Temps réel vs traitement par lots, et le modèle asynchrone

• Temps réel convient aux formulaires d'inscription et au paiement : une adresse, une réponse immédiate, avec un délai d'attente strict pour que l'utilisateur n'attende jamais plus d'une ou deux secondes.
• Traitement par lots convient aux listes : des milliers d'adresses, des nouvelles tentatives et un fichier de résultats que vous pouvez segmenter.
• Asynchrone est le modèle de production pour les deux : mettez l'adresse en file d'attente, renvoyez la réponse immédiatement, vérifiez en arrière-plan et mettez à jour l'enregistrement à réception du résultat.

Ne bloquez jamais un thread de requête sur une négociation SMTP distante. Un serveur lent ou hostile peut maintenir la connexion pendant 30 secondes ou plus.

Un meilleur exemple en Python

import smtplib
import dns.resolver

def de la syntaxe(domaine: str, adresse: str, timeout: int = 10) -> str:
    try:
        mx = str(dns.resolver.resolve(domaine, "MX")[0].exchange).rstrip(".")
        with smtplib.SMTP(mx, 25, timeout=timeout) as smtp:
            smtp.ehlo_or_helo_if_needed()
            smtp.mail("check@validator.example.com")
            code, _ = smtp.rcpt(adresse)
            if code ( (250, 251):
                return "valid"
            if code ( (450, 451, 452, 552):
                return "risqué"
            if code ( (550, 551, 553):
                return "invalid"
            return "unknown"
    except Exception:
        return "unknown"

Même cette version simplifiée pose des problèmes à grande échelle : elle ignore le greylisting, ne détecte pas les domaines catch-all, utilise une seule adresse IP et sera bloquée par les fournisseurs qui limitent le débit. C'est un outil d'apprentissage, pas un validateur de production.

Limites et éthique

Aucun validateur ne peut garantir la délivrabilité. Les boîtes mail se ferment entre la vérification et l'envoi ; les serveurs changent de politique ; une adresse « valide » peut tout de même être abandonnée. Utilisez la vérification pour éliminer les échecs prévisibles, pas pour promettre une campagne sans aucun rebond.

Sur le plan éthique, ne validez que les adresses que vous avez une base légale de contacter. Le sondage SMTP est une opération technique, mais il ne crée pas de consentement, et utiliser la validation pour blanchir une liste achetée ne rend pas l'envoi légal.

Ce que la validation ne peut pas voir

• Engagement — une adresse valide peut ne jamais ouvrir votre e-mail.
• Intention — une personne réelle peut ne pas vouloir de votre offre.
• Consentement — une adresse délivrable n'est pas une base légale.
• État futur — une boîte mail peut être fermée le lendemain de votre vérification.

La vérification élimine l'incertitude technique. Tout le reste relève toujours du marketing.

Tester d'abord votre propre domaine

Avant de valider une liste, validez votre domaine d'envoi :

• Envoyez un test à une boîte mail que vous contrôlez sur Gmail, Outlook et un domaine d'entreprise.
• Vérifiez l'alignement SPF, DKIM et DMARC.
• Surveillez de près les 200 premiers envois de tout nouveau domaine : la période de chauffe compte plus que n'importe quelle vérification isolée.

Une liste propre envoyée depuis un domaine dont l'authentification est défaillante finit tout de même dans les spams.

Questions fréquentes

La validation SMTP envoie-t-elle un e-mail ?
Non. Elle s'arrête à RCPT TO, before any message body is transmitted.

Pourquoi certaines adresses valides ressortent-elles comme « risquées » ?
Greylisting, erreurs temporaires du serveur ou politiques anti-collecte. Réessayez après 24 à 48 heures.

Puis-je valider depuis mon propre serveur ?
Seulement s'il peut atteindre le port 25 et n'est ni limité en débit ni placé sur liste noire. La plupart des hébergements mutualisés le bloquent.

La détection catch-all est-elle fiable ?
Elle indique de manière fiable que le domaine est catch-all. En revanche, elle ne peut pas dire si une boîte mail précise existe.

Quelle précision faut-il attendre ?
Un bon validateur basé sur SMTP a raison environ 95 à 99 % du temps ; l'incertitude restante provient surtout des domaines catch-all et des échecs temporaires.

SPF, DKIM et DMARC en un paragraphe chacun

• SPF liste les serveurs autorisés à envoyer des messages pour votre domaine. Il s'agit d'un enregistrement DNS de type TXT, et il cesse de fonctionner lorsque vous dépassez la limite de 10 requêtes DNS.
• DKIM ajoute une signature cryptographique à chaque message afin que le destinataire puisse vérifier qu'il n'a pas été modifié. Renouvelez les clés périodiquement.
• DMARC indique aux destinataires quoi faire lorsque SPF ou DKIM échoue (none, quarantine, reject) et vous envoie des rapports. Commencez par p=none, read the reports, then tighten.

La validation SMTP vérifie le destinataire ; SPF, DKIM et DMARC déterminent si vos propres messages sont considérés comme fiables à l'envoi. Une liste vérifiée envoyée depuis un domaine dont l'authentification est défaillante échouera quand même. Configurez les rapports DMARC avant d'augmenter le volume d'une campagne : ces rapports vous permettent de repérer les expéditeurs que vous avez oubliés.

Commencer la validation

Commencer gratuitement →

100 validations SMTP par mois, sans carte bancaire.