Repérez les e-mails d'inscription jetables, mal saisis ou sans serveur de messagerie
Offrez à votre formulaire d'inscription une vérification précoce de chaque adresse : syntaxe, domaines jetables/temporaires connus, présence d'un serveur de messagerie pour le domaine, fautes de frappe probables et adresses génériques — sous la forme d'un verdict accept, review ou reject accompagné de ses motifs. Appelez POST /v1/email/validate depuis le JavaScript de votre formulaire, ou vérifiez des listes en masse depuis votre backend ou le tableau de bord.
Requête et authentification
Envoyez un corps JSON { "email": "user@example.com" } à POST /v1/email/validate avec une clé publiable restreinte par origine dans l'en-tête X-Api-Key — le même type de clé et le même modèle d'origines autorisées que GET /v1/geo, ce qui permet de l'appeler directement depuis un formulaire d'inscription pendant la saisie ou à la soumission. Côté serveur, votre clé secrète donne accès à POST /v1/email/batch (jusqu'à 100 adresses par requête), aux tâches de liste asynchrones jusqu'à 100 000 adresses (API ou page Email lists du tableau de bord, CSV en entrée et en sortie) et à POST /v1/signup/check, qui combine la vérification d'e-mail avec les indicateurs réseau de l'IP d'inscription en un seul score.
Lisez le verdict, puis les motifs
verdict est l'issue la plus sévère : reject pour une syntaxe invalide, un domaine inexistant, un domaine sans serveur de messagerie ou un domaine jetable ; review pour une faute de frappe présumée, une adresse générique comme info@, un domaine avec seulement un serveur de messagerie implicite, ou une recherche DNS non aboutie ; sinon accept. reasons énumère chaque condition rencontrée, pour que votre formulaire affiche un message précis — et lorsque didYouMean est renseigné, proposez la correction plutôt qu'une erreur.
Quand l'appeler
Appelez-la à la perte de focus ou à la soumission plutôt qu'à chaque frappe — vérifier une adresse encore incomplète à chaque caractère ajoute des requêtes sans signal utile et peut faire clignoter un message d'erreur pendant que le visiteur tape encore. Chaque appel compte comme une requête.
En cas d'échec de la requête
Échouez en mode ouvert : laissez l'inscription se poursuivre si la requête réseau échoue ou expire, plutôt que de bloquer chaque visiteur à cause d'une panne côté client. Côté serveur, une recherche DNS qui échoue est signalée par le motif dns_unavailable (verdict review), jamais par une erreur ou un reject. Conservez ce que le visiteur a déjà saisi afin qu'une vérification échouée ne lui fasse jamais perdre sa saisie.
Comment les domaines jetables sont détectés
Les domaines jetables/temporaires connus proviennent de la fusion de trois listes open source maintenues par la communauté (voir sources de données), actualisées toutes les quelques heures, avec une liste d'autorisation afin qu'une mauvaise entrée en amont ne puisse jamais signaler un grand fournisseur. Les sous-domaines d'un domaine listé correspondent aussi. Les nouveaux domaines jetables qu'aucune liste ne connaît encore sont souvent repérés grâce à leur serveur de messagerie : les services jetables font pointer de nombreux domaines vers les mêmes quelques hôtes, et un domaine dont le serveur de messagerie dessert des domaines listés est signalé avec disposableSource : mx_host. Un fournisseur très récent sur un nouveau serveur de messagerie peut encore passer inaperçu.
Usage et quota
Chaque adresse vérifiée compte comme une requête sur le plafond mensuel partagé de votre forfait — une vérification unitaire, chaque adresse d'un lot, chaque adresse distincte d'une tâche de liste — aux côtés de votre autre trafic, avec la même limite de débit par minute. Il n'y a ni forfait ni prix e-mail distinct. La limite de débit par minute compte les appels HTTP, pas les éléments : un lot de jusqu'à 100 IP ou adresses e-mail compte pour une seule requête, tandis que chaque élément compte toujours séparément dans le plafond mensuel de requêtes.
Ce que cela ne vérifie pas
Chaque vérification porte sur le domaine ou l'adresse. Watch-IP ne contacte jamais le serveur de messagerie du destinataire : un résultat n'établit donc pas que la boîte aux lettres existe, que le courrier y parviendra ni qu'elle appartient à la personne qui s'inscrit. Un verdict accept signifie « aucun problème détecté », pas une adresse dont le fonctionnement est confirmé — utilisez un e-mail de confirmation pour cela.
Champs de la réponse
- syntaxValid
- Indique si l'adresse est syntaxiquement valide.
- isDisposable
- Indique si le domaine correspond à un fournisseur jetable/temporaire connu, directement, via un domaine parent ou via son serveur de messagerie. Toujours false lorsque syntaxValid vaut false.
- disposableSource
- list, parent_domain ou mx_host — pourquoi isDisposable vaut true ; null sinon.
- mx
- Le statut du serveur de messagerie du domaine (found, implicit, none, null_mx, no_domain ou unknown) et son hôte MX principal.
- didYouMean
- Une correction probable de faute de frappe, comme gmial.com → gmail.com, ou null.
- isRoleAccount / isFreeProvider
- Indicateurs d'adresse générique (admin@, info@, noreply@…) et de fournisseur de messagerie grand public. Le fournisseur gratuit est purement informatif.
- normalizedEmail / canonicalEmail
- L'adresse en minuscules, et la même sans +tags (ni points Gmail) pour repérer les comptes en double.
- verdict / reasons
- accept, review ou reject, plus chaque code de motif rencontré — voir la référence pour la liste complète.
Agir selon le verdict
JavaScript du formulaire d'inscription
async function checkEmail(email) {
const response = await fetch('https://api.watch-ip.com/v1/email/validate', {
method: 'POST',
headers: { 'X-Api-Key': 'YOUR_PUBLISHABLE_KEY', 'Content-Type': 'application/json' },
body: JSON.stringify({ email }),
});
if (!response.ok) return { state: 'unknown' }; // fail open — ne bloquez pas l'inscription en cas d'erreur réseau
const result = await response.json();
if (result.didYouMean) return { state: 'suggest', suggestion: result.didYouMean };
if (result.verdict === 'reject') return { state: 'reject', reasons: result.reasons };
return { state: 'ok' }; // accept ou review : laissez passer l'inscription et signalez-la côté backend
}Affichez un message distinct par motif — invalid_syntax, disposable_domain et no_mail_server appellent des corrections différentes de la part du visiteur — et proposez didYouMean comme correction en un clic.
Questions fréquentes
Vérifie-t-il que la boîte aux lettres existe ?
Non. Elle vérifie la syntaxe, les listes et les enregistrements DNS de serveur de messagerie du domaine, ainsi que la forme de l'adresse. Elle ne contacte jamais le serveur de messagerie et ne confirme pas que la boîte aux lettres individuelle existe — un reject pour no_mail_server concerne le domaine entier.
Un accept prouve-t-il que l'e-mail fonctionne ?
Non. accept signifie qu'aucune vérification n'a détecté de problème, pas que l'adresse recevra forcément du courrier ni qu'elle appartient à la personne qui s'inscrit. Utilisez un e-mail de confirmation si vous en avez besoin.
Les utilisateurs peuvent-ils contourner la validation navigateur ?
Oui. Toute vérification côté navigateur, y compris celle-ci, peut être contournée en désactivant JavaScript ou en appelant directement votre point de terminaison d'inscription. Appliquez toute décision importante sur votre backend — POST /v1/signup/check est conçu pour cela.
Puis-je nettoyer une liste existante ?
Oui. Envoyez un CSV depuis la page Email lists du tableau de bord, ou soumettez jusqu'à 100 000 adresses à POST /v1/email/jobs avec votre clé secrète, puis téléchargez un CSV de résultats avec un verdict et des motifs par ligne. Les doublons ne sont facturés qu'une fois, et les envois et résultats sont supprimés après 7 jours.
Comment les requêtes sont-elles comptabilisées ?
Une requête par adresse vérifiée, imputée au plafond mensuel partagé de votre forfait. Les doublons d'une tâche de liste comptent une seule fois ; une vérification d'inscription compte comme une requête.
Pages associées
- Référence de l'API de vérification d'e-mailChamps, verdicts et codes de motif des points de terminaison e-mail : vérification unitaire, par lot, tâches de liste et vérification d'inscription.
- Prévention des abus d'inscriptionCombinez les signaux de l'e-mail et de l'IP pour décider d'accepter, d'examiner ou de refuser une inscription.
- Géolocalisation du visiteurAppelez GET /v1/geo depuis le navigateur avec une clé publiable.
- E-mail jetable vs vérificationPourquoi un contrôle de domaine jetable n'est pas une vérification de boîte aux lettres ou de délivrabilité.