Vérification des Emails Clients — Guide complet
Installer, configurer et exploiter la vérification de délivrabilité des emails et le nettoyage de la base clients pour PrestaShop 8 et 9.
Vérification des Emails Clients contrôle la délivrabilité réelle de chaque adresse email de votre boutique : syntaxe, existence du domaine via ses enregistrements MX, et, en option, une sonde SMTP qui interroge le serveur du destinataire. Le statut de chaque client (Valide, Invalide, À risque, Non vérifié) s’affiche dans un onglet dédié du back-office, où vous pouvez vérifier toute la base par lots et supprimer en un clic les clients dont l’email n’existe pas — sans jamais effacer un vrai client par erreur. Ce guide couvre l’installation, la configuration, les niveaux de vérification et le nettoyage de la base.
Installation
- Téléchargez l’archive
dfemailcheck.zipdepuis votre compte DataFirefly. - Back-office PrestaShop → Modules → Téléverser un module → envoyez le ZIP.
- À l’installation, le module crée sa table
df_email_check, enregistre ses hooks et ajoute l’onglet Clients → Vérification emails.
Compatible PrestaShop 8.0 à 9.x, en PHP 7.4 à 8.3. Aucun override de thème, aucune dépendance Composer. Compatible multiboutique et traduisible.
Configuration
Rendez-vous dans Modules → Vérification des Emails Clients → Configurer.
Vérification à l’inscription
Lorsque l’option Vérifier à la création du compte est active, chaque nouveau client est contrôlé automatiquement à sa création (hook actionObjectCustomerAddAfter). Seule la vérification rapide — syntaxe et domaine — est exécutée à ce moment, afin de ne pas ralentir le tunnel de commande. Le statut est également recalculé lorsqu’un client modifie son adresse email.
Blocage de l’inscription
L’option Bloquer l’inscription si domaine invalide refuse le formulaire d’inscription lorsque le domaine de l’email ne possède aucun enregistrement MX ni A (hook actionValidateCustomerFormFields). Le client voit alors un message d’erreur sur le champ email. Désactivée par défaut.
Vérification SMTP (avancé)
La sonde SMTP confirme l’existence réelle de la boîte aux lettres en dialoguant avec le serveur du destinataire (commande RCPT TO), avec détection des serveurs en catch-all. Trois réglages l’accompagnent :
- Vérification SMTP : active ou désactive la sonde. Désactivée par défaut.
- Adresse expéditeur SMTP : adresse annoncée pendant le dialogue (
MAIL FROM). - Timeout SMTP : délai d’attente maximal par serveur, en secondes (6 par défaut).
La vérification SMTP nécessite le port 25 sortant, très souvent fermé sur les hébergements mutualisés. Sans elle, la vérification s’arrête au domaine — ce qui détecte déjà la grande majorité des fausses adresses.
Sécurité de la suppression
- Protéger les clients ayant des commandes : empêche la suppression de tout client possédant au moins une commande, afin d’éviter les commandes orphelines. Activée par défaut.
- Taille de lot : nombre de clients traités par passage lors des vérifications en masse (50 par défaut).
Les niveaux de vérification
Le contrôle se fait en trois niveaux, du plus rapide au plus précis :
- Syntaxe : validation du format de l’adresse.
- Domaine : recherche des enregistrements MX du domaine, avec repli sur les enregistrements A/AAAA.
- SMTP (optionnel) : dialogue avec le serveur du destinataire pour confirmer la boîte, avec détection des serveurs catch-all.
Les statuts
Chaque client reçoit l’un des quatre statuts suivants :
- Valide : syntaxe correcte et domaine recevable (et boîte confirmée si la sonde SMTP est active).
- Invalide : signal négatif certain — syntaxe incorrecte (
bad_syntax), domaine sans MX ni A (no_mx) ou rejet SMTP explicite (smtp_rejected). Ce sont les seuls clients supprimables. - À risque : serveur en catch-all (
smtp_catch_all) — l’adresse est acceptée mais le serveur accepte aussi les adresses inexistantes. Jamais supprimé automatiquement. - Non vérifié : résultat indéterminé — délai dépassé, port fermé, greylisting ou client jamais contrôlé. Jamais supprimé.
Le code de détail (par exemple no_mx, smtp_catch_all) est affiché à côté du statut dans la liste, pour expliquer chaque décision.
Le tableau de bord
L’onglet Clients → Vérification emails affiche en haut cinq compteurs : nombre total de clients, valides, invalides, à risque et non vérifiés. En dessous, la liste complète des clients est filtrable par statut. Deux boutons lancent la vérification :
- Vérifier les nouveaux clients : ne contrôle que les clients jamais vérifiés.
- Tout re-vérifier : recontrôle l’intégralité de la base.
Le traitement s’effectue par lots en AJAX, avec une barre de progression, ce qui permet de traiter de grandes bases sans dépassement de délai. La sonde SMTP, si activée, n’est utilisée que pendant ces vérifications en masse.
Supprimer les clients invalides
Le bouton Supprimer les clients invalides efface en une fois tous les clients au statut Invalide. Les clients ayant passé au moins une commande sont ignorés tant que l’option de protection est active. Vous pouvez aussi agir sur une sélection précise via les actions groupées de la liste : Re-vérifier la sélection ou Supprimer la sélection. La suppression utilise le mécanisme natif de PrestaShop (Customer::delete()) et nettoie également la table de résultats.
La suppression d’un client est définitive. Vérifiez le compteur « Invalides » et, au besoin, filtrez la liste sur ce statut pour contrôler les adresses avant la purge.
Sécurité — zéro faux positif
La règle centrale du module : une adresse n’est jamais marquée Invalide sur un simple doute. Un délai dépassé, un greylisting, un port SMTP fermé ou une réponse temporaire (4xx) laissent le statut sur Non vérifié, jamais supprimé. Seuls les signaux négatifs certains (syntaxe, absence de MX/A, rejet 5xx) rendent un client supprimable. Combinée à la protection des clients avec commandes, cette logique évite d’effacer un vrai client par erreur.
Compatibilité et notes techniques
- PrestaShop 8.0 à 9.x, multiboutique, interface traduisible.
- Contrôleur d’administration legacy (pas de contrôleur Symfony) pour la compatibilité PS8/PS9.
- Hooks :
actionObjectCustomerAddAfter,actionObjectCustomerUpdateAfter,actionObjectCustomerDeleteAfter,actionValidateCustomerFormFields. - Endpoint AJAX back-office via le 4ᵉ argument de
getAdminLink(); rendu JSON par une méthode dédiée. - Table
df_email_check: un enregistrement par client (email, statut, code de détail, date de contrôle). - Aucun appel à un service tiers : la vérification s’appuie uniquement sur le DNS et, en option, sur une connexion SMTP directe.
FAQ et dépannage
La vérification SMTP renvoie toujours « Non vérifié ». Le port 25 sortant est probablement fermé par votre hébergeur. Désactivez la sonde SMTP : la vérification du domaine (MX) suffit dans la majorité des cas.
Des clients légitimes apparaissent « À risque ». Leur serveur de messagerie est en catch-all (il accepte toutes les adresses). C’est un comportement serveur, pas une erreur ; ces clients ne sont jamais supprimés automatiquement.
La purge ne supprime aucun client alors que le compteur Invalides est positif. Vérifiez l’option « Protéger les clients ayant des commandes » : les clients invalides possédant une commande sont volontairement ignorés.
Le blocage à l’inscription ne se déclenche pas. Le hook de validation du formulaire dépend de la version de PrestaShop ; si votre version ne le déclenche pas, la vérification reste assurée juste après la création du compte, et le client apparaît alors en « Invalide » dans la liste.
La vérification ralentit-elle l’inscription ? Non. À l’inscription, seule la vérification rapide (syntaxe et domaine) est exécutée. La sonde SMTP n’intervient que lors des vérifications en masse depuis le back-office.