Validation d'email en temps réel

La validation en temps réel analyse une adresse pendant qu'une personne la saisit, et renvoie un statut dans la réponse de l'appel. Dix-huit contrôles s'exécutent sans consommer de crédit, ce qui permet de valider chaque frappe sans coût. La vérification SMTP reste optionnelle et se demande au moment qui compte.

POST /v2/email/validate
Score global 100 / 100
  • Syntaxe Adresse conforme. valid
  • Domaine Le domaine annonce un serveur de messagerie. valid
  • Boîte SMTP Le serveur destinataire confirme la boîte. valid
  • Domaine jetable Domaine absent de la base de domaines jetables. valid
Réponse de l'API pour une adresse, extrait.credits.used = 1: seule la vérification SMTP est facturée.

Un appel, une décision

Une requête porte une adresse, la réponse revient dans le même appel. Sans paramètre supplémentaire, seuls les contrôles gratuits s'exécutent et aucun crédit n'est débité, quel que soit le résultat. C'est la forme à utiliser pour valider une saisie au fil de la frappe, sur un formulaire à fort trafic.

Validation sans vérification SMTP
curl -X POST https://api.yeswecheck.fr/v2/email/validate \
  -H "Authorization: Bearer $YESWECHECK_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"email":"[email protected]"}'

Ajouter le paramètre de vérification SMTP à cette même requête déclenche le dialogue avec le serveur destinataire. C'est le seul changement qui peut entraîner un débit.

Validation avec vérification SMTP
curl -X POST https://api.yeswecheck.fr/v2/email/validate \
  -H "Authorization: Bearer $YESWECHECK_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"email":"[email protected]","smtp":true}'

L'authentification passe par l'en-tête Authorization, avec le schéma Bearer, pour une clé API comme pour un jeton de session. L'en-tête X-API-Key n'est jamais lu.

Quelle décision prendre pour chaque statut

Quatre statuts, quatre conduites différentes. Le statut valide autorise la suite du parcours. Le statut invalide justifie un refus, l'adresse produira un rebond. Le statut risqué appelle une règle métier plutôt qu'un refus automatique. Le statut indéterminé ne doit jamais bloquer une inscription : il décrit un serveur, pas une adresse.

Les 4 statuts et la conduite à tenir dans un formulaire.
StatutCe que cela signifieConduite à tenir
validL'adresse existe et le serveur destinataire accepte de la recevoir. Quand la vérification SMTP est demandée, ce statut n'est rendu que si le serveur a confirmé la boîte.Accepter l'adresse.
invalidL'adresse ne peut pas recevoir de message : syntaxe non conforme, domaine sans enregistrement MX, boîte refusée par le serveur, ou adresse présente en liste noire de l'organisation.Rejeter l'adresse, elle produira un rebond définitif.
riskyL'adresse est techniquement acceptable mais porte un signal de risque : domaine jetable, domaine malveillant, domaine typosquatté, ou score global inférieur au seuil de dégradation.Accepter sous condition, ou écarter selon la politique métier configurée.
unknownLe serveur destinataire n'a pas permis de conclure : domaine catch-all, temporisation greylisting, sonde bloquée, serveur injoignable ou erreur réseau.Ne pas trancher sur ce seul résultat. Aucun crédit n'est débité.

Lire la définition des statuts et du score

Quand demander la vérification SMTP

Valider à chaque frappe sans vérification SMTP, puis demander la vérification SMTP une seule fois, à la soumission du formulaire. Cette séquence donne une correction immédiate des fautes de frappe sans dépenser de crédit, et réserve le contrôle facturé au moment où l'adresse est réellement enregistrée dans la base.

Un crédit est débité si et seulement si la vérification SMTP a été demandée et que le statut final n'est pas « unknown ».

Le délai accordé à la session SMTP est réglable, entre 1000 et 30000 millisecondes. Ce sont des bornes de configuration, pas une mesure de temps de réponse.

Comprendre la vérification SMTP

Ce que coûte l'attente

Le temps de réponse n'est pas le même selon que la vérification SMTP est demandée ou non. Sans elle, la réponse ne dépend que de contrôles locaux et de résolutions de noms. Avec elle, la réponse dépend d'un serveur tiers que YesWeCheck ne contrôle pas, et qui peut prendre son temps.

Sans vérification SMTP, la réponse est immédiate. Avec vérification SMTP, le temps de réponse dépend du serveur destinataire et peut aller de quelques centaines de millisecondes à plusieurs secondes.

Aucun chiffre de latence n'est publié sur ce site. Les mesures disponibles sont prises côté serveur, sur des effectifs trop faibles pour qu'une valeur publiée ait un sens. Une campagne de mesure dédiée est nécessaire avant de publier quoi que ce soit.

Questions fréquentes

Faut-il activer la vérification SMTP dans un formulaire d'inscription ?
Pas systématiquement. Les dix-huit contrôles gratuits écartent déjà la syntaxe invalide, le domaine sans serveur de messagerie, l'adresse jetable et la faute de frappe de domaine. La vérification SMTP se justifie quand le coût d'une adresse fausse dépasse le coût d'un crédit, par exemple sur un formulaire de devis.
Que faire quand le statut renvoyé est indéterminé ?
Accepter la saisie et ne pas bloquer la personne. Un statut indéterminé décrit un serveur qui n'a pas permis de conclure, pas une adresse fausse. Refuser une inscription sur ce motif écarte des clients réels, et l'appel n'est de toute façon pas facturé.
La validation ralentit-elle le formulaire ?
Sans vérification SMTP, la réponse est immédiate. Avec vérification SMTP, le temps de réponse dépend du serveur destinataire et peut aller de quelques centaines de millisecondes à plusieurs secondes. Une intégration prudente valide sans SMTP à la saisie, puis demande la vérification SMTP au moment de la soumission.
Un message est-il envoyé à l'adresse vérifiée ?
Non. La vérification SMTP ouvre une session avec le serveur destinataire et s'arrête avant d'écrire le message. La personne dont l'adresse est vérifiée ne reçoit rien, et rien n'apparaît dans sa boîte.

Aller plus loin

La page de référence de l'API rassemble les paramètres, les codes de réponse et le détail des contrôles. Pour valider un formulaire sans écrire de code d'intégration, le widget appelle le même moteur depuis la page. Pour nettoyer une base existante, le traitement par lots reprend les mêmes règles de facturation.