Comment vérifier les e-mails dans les formulaires WordPress

Toutes les extensions de formulaire WordPress collecteront volontiers asdf@asdf et une centaine d'adresses Gmail comportant des fautes de frappe, puis les transmettront directement à votre liste de diffusion. Pour vérifier les e-mails dans les formulaires WordPress, vous n'avez pas besoin d'une nouvelle extension — vous devez appeler une API de vérification au moment où quelqu'un soumet le formulaire, ou exporter les entrées et les nettoyer en masse. Ce guide présente les deux approches pour les trois grandes extensions de formulaire (Contact Form 7, WPForms, Gravity Forms), à l'aide de méthodes qui fonctionnent quelle que soit celle que vous utilisez.

La réponse courte#

Deux approches prises en charge, et celle que vous choisissez dépend de votre extension et de son forfait :

1. Temps réel — connectez-vous à l'événement de soumission ou de validation de l'extension et appelez l'API Qualisend avant que l'entrée ne soit confirmée. Sur la plupart des extensions, il s'agit d'un petit extrait de code PHP sur un filtre de validation (le seul endroit où vous pouvez rejeter une adresse directement), ou d'une étape webhook sur les offres Pro pour un tagging asynchrone.
2. En masse — exportez les entrées stockées par l'extension au format CSV et passez-les dans le vérificateur en masse de Qualisend selon une planification. Aucun code, fonctionne sur tous les forfaits qui stockent les entrées.

Vérifier les e-mails dans les formulaires WordPress à la soumission#

Presque toutes les extensions de formulaire déclenchent un événement côté serveur à l'arrivée d'une soumission, et cet événement est votre point d'intégration. La distinction importante porte sur le moment où le hook se déclenche, car il détermine si vous pouvez bloquer une mauvaise adresse ou seulement y réagir :

Si vous voulez que le visiteur voie « cette adresse ne semble pas délivrable » et la corrige, il vous faut le filtre de validation, ce qui implique un peu de PHP. Si vous voulez seulement empêcher les adresses mortes d'atteindre votre outil en aval, un webhook suffit et ne nécessite aucun code.

Voici l'approche par filtre de validation sur le filtre de validation d'e-mail de Contact Form 7. La même structure se transpose à Gravity Forms et WPForms — seuls le nom du hook (gform_field_validation sur Gravity Forms, wpforms_process sur WPForms) et la façon d'attacher l'erreur changent. Si Gravity Forms est votre extension, le guide de vérification des e-mails depuis Gravity Forms parcourt le hook gform_field_validation de bout en bout avec le câblage exact propre à GF. La clé API réside dans une constante de wp-config.php, jamais dans un shortcode, un fichier de thème ou du JavaScript côté client :

// In a snippet plugin, or your theme's functions.php.
// In wp-config.php:  define( 'QUALISEND_API_KEY', 'YOUR_API_KEY' );

add_filter( 'wpcf7_validate_email*', 'qs_verify_email', 20, 2 );
add_filter( 'wpcf7_validate_email',  'qs_verify_email', 20, 2 );

function qs_verify_email( $result, $tag ) {
    $field = $tag->name;
    $email = isset( $_POST[ $field ] ) ? trim( wp_unslash( $_POST[ $field ] ) ) : '';
    if ( $email === '' ) {
        return $result; // let the plugin's own required-field check handle it
    }

    // Check /developers for the exact endpoint and request body.
    $response = wp_remote_post( 'https://api.qualisend.com/v1/verify', array(
        'timeout' => 4, // don't let a slow probe stall the form
        'headers' => array(
            'Authorization' => 'Bearer ' . QUALISEND_API_KEY,
            'Content-Type'  => 'application/json',
        ),
        'body' => wp_json_encode( array( 'email' => $email ) ),
    ) );

    // Fail open: never block a real visitor because our API had a bad moment.
    if ( is_wp_error( $response ) || wp_remote_retrieve_response_code( $response ) !== 200 ) {
        return $result;
    }

    $data    = json_decode( wp_remote_retrieve_body( $response ), true );
    $verdict = $data['result'] ?? array();

    if ( ( $verdict['status'] ?? '' ) === 'undeliverable' ) {
        $result->invalidate( $tag, "That address doesn't look deliverable — please check it." );
    } elseif ( ! empty( $verdict['sub_flags']['disposable'] ) ) {
        $result->invalidate( $tag, 'Please use a permanent email address.' );
    }

    return $result;
}

Trois éléments soutiennent cet extrait, et ce sont les mêmes trois dans tous les langages : gardez la clé côté serveur, plafonnez la requête avec un délai d'expiration court, et échouez de façon ouverte (fail open) — si l'appel échoue, expire ou renvoie un code différent de 200, laissez passer la soumission. Une API de vérification est un filtre de qualité, pas un gardien, et perdre un vrai prospect à cause d'une panne passagère est le pire résultat. Pour les mécanismes de l'appel API lui-même — en-têtes, gestion des erreurs, forme de la réponse — le guide de validation d'e-mail en PHP parcourt la même requête de bout en bout.

Si le PHP personnalisé n'est pas une option, l'alternative sans code est un webhook. Si votre extension propose des webhooks — Gravity Forms via son module Webhooks, WPForms via l'addon Webhooks, tous deux sur les licences de niveau supérieur — pointez le webhook vers une petite fonction serverless qui détient votre clé et appelle l'API. Le hic, d'après le tableau ci-dessus : ces webhooks se déclenchent après l'enregistrement de l'entrée, ils ne peuvent donc pas afficher d'erreur directe. Ce qu'ils peuvent faire, c'est vérifier de manière asynchrone et agir sur le verdict — ajouter un tag, ignorer le répondeur automatique, ou écarter les adresses non délivrables avant qu'elles n'atteignent votre outil e-mail. Une étape webhook sans code (du type de celles qu'exposent Zapier ou Make) fonctionne de la même manière : soumission du formulaire en entrée, appel API, verdict en sortie.

Le fait qu'une extension donnée expose des webhooks ou vous permette d'exécuter du PHP personnalisé dépend entièrement de l'extension et de son forfait — la version gratuite de Contact Form 7 vous donne le filtre de validation mais pas d'interface webhook ; Gravity Forms et WPForms réservent les webhooks à des modules payants. Vérifiez ce que votre offre inclut avant de vous engager sur une voie.

Agir sur le verdict#

L'API renvoie un objet result contenant un status de deliverable, risky, undeliverable ou unknown, ainsi qu'un score de 0 à 100, un code reason et des sous-indicateurs pour disposable, role, free et catch_all — le même $data['result'] que lit l'extrait ci-dessus. Faites correspondre ces valeurs à une action de formulaire :

Le verdict local immédiat — syntaxe, domaine, adresse jetable, adresse générique — est celui que vous voulez sur un formulaire en direct : il revient vite et intercepte la majeure partie des mauvaises soumissions. La sonde SMTP de la boîte aux lettres, plus lourde, convient mieux à l'approche en masse ci-dessous, où quelques secondes de latence n'ont pas d'importance. Si vous vous demandez pourquoi chaque contrôle se situe là où il est, comment fonctionne la vérification des e-mails décompose le pipeline.

Ou vérifier les entrées en masse à partir d'un export CSV#

Tous les formulaires n'ont pas besoin d'un filtre en temps réel, et certaines extensions rendent le code personnalisé laborieux. L'alternative sans code consiste à laisser les soumissions s'accumuler et à les nettoyer selon une planification.

1. Exportez les entrées au format CSV. Gravity Forms propose Import/Export → Export Entries ; WPForms propose un export des entrées sur l'offre Pro ; Contact Form 7 ne stocke rien par défaut, associez-le donc à l'extension gratuite Flamingo pour d'abord capturer les soumissions.
2. Vérifiez le CSV en masse. Importez-le dans le vérificateur en masse de Qualisend, qui exécute le pipeline complet — y compris la sonde SMTP — sur chaque ligne et vous renvoie un fichier scoré.
3. Filtrez et synchronisez. Conservez deliverable, examinez risky et écartez undeliverable avant d'importer les survivants dans votre plateforme e-mail.

C'est le même flux de travail que n'importe quel nettoyage de liste, simplement alimenté par la table des entrées de votre formulaire — le guide pour nettoyer une liste d'e-mails couvre en détail la boucle export-vérification-réimport. La vérification en masse est aussi le bon outil pour les adresses que vous avez déjà collectées avant d'ajouter un contrôle en temps réel : passez l'historique une fois, puis laissez le hook au moment de la soumission maintenir la liste propre à partir de là.

Temps réel, en masse, ou les deux#

Ils résolvent des problèmes différents, c'est pourquoi la plupart des sites finissent par vouloir les deux :

• Le temps réel relève de la prévention. Une faute de frappe interceptée à la soumission, c'est un prospect sauvé grâce à une correction d'une ligne ; un domaine mort rejeté à ce moment-là ne deviendra jamais un rebond dur qui entame votre taux de rebond.
• La vérification en masse relève du nettoyage. Les adresses se dégradent — les gens changent d'emploi, les domaines expirent — donc même une liste parfaitement filtrée a besoin d'une re-vérification périodique.

Associer un hook au moment de la soumission à un passage en masse mensuel relève de la même logique que combiner la vérification avec un flux de double opt-in : arrêter les déchets évidents à la porte, et balayer le reste selon une planification.

Foire aux questions#

Puis-je vérifier les e-mails dans Contact Form 7 sans module payant ?#

Oui. Contact Form 7 expose le filtre wpcf7_validate_email sur sa version gratuite : un petit extrait de code PHP comme celui ci-dessus peut donc appeler l'API et rejeter directement les adresses non délivrables ou jetables — aucun module supplémentaire requis. Vous devez toutefois pouvoir ajouter du code (via le functions.php de votre thème ou une extension de gestion d'extraits de code) et stocker votre clé API dans wp-config.php.

Un webhook Gravity Forms ou WPForms peut-il rejeter une mauvaise adresse directement ?#

Généralement non. Ces webhooks se déclenchent après l'enregistrement de l'entrée : ils s'exécutent donc de manière asynchrone et ne peuvent pas afficher d'erreur de validation au visiteur. Ils sont parfaits pour taguer, router ou écarter les adresses non délivrables avant qu'elles n'atteignent votre outil e-mail. Pour un rejet direct visible par le visiteur, utilisez plutôt le filtre de validation de l'extension avec un code PHP personnalisé.

Existe-t-il une extension Qualisend native pour WordPress ?#

Pas pour le moment — nos intégrations de plateforme natives sont en cours de refonte, et un connecteur WordPress figure dans notre feuille de route. En attendant sa sortie, les approches prises en charge sont les deux de ce guide : appeler l'API REST depuis un hook de formulaire, un webhook ou une fonction serverless, ou exporter les entrées au format CSV pour les vérifier en masse. Les deux s'appuient directement sur l'API documentée.

Faut-il vérifier à la soumission ou nettoyer les entrées en masse ?#

Les deux, pour des raisons différentes. Vérifier à la soumission empêche les fautes de frappe et les adresses jetables d'entrer dans votre liste, avec un retour immédiat pour le visiteur. La vérification en masse détecte les adresses qui se sont dégradées après leur collecte et nettoie l'historique accumulé avant que vous n'ajoutiez un contrôle en temps réel. Un hook au moment de la soumission, complété par un passage en masse périodique, couvre les deux cas.

Prêt à tout mettre en place ? Le forfait gratuit inclut des crédits pour tester les deux approches, la référence de l'API contient la requête /verify exacte pour votre hook ou votre fonction serverless, et le vérificateur d'e-mails gratuit vous permet de tester ponctuellement une seule adresse avant d'écrire la moindre ligne de code.