Questions fréquentes

La vérification d'emails repère les adresses qui rebondiraient avant que vous ne leur écriviez. C'est important, car un taux de rebond élevé abîme votre réputation d'expéditeur et pousse le reste de vos emails vers le spam. Techniquement, elle consiste à établir si une adresse peut réellement recevoir du courrier, sans rien lui envoyer. Un contrôle inspecte la syntaxe de l'adresse, confirme que le domaine existe et publie des enregistrements MX, ouvre une conversation avec le serveur de messagerie destinataire et lui demande s'il accepterait un message pour cette boîte. Le résultat est un verdict, pas une garantie, car certains serveurs refusent délibérément de répondre à la question.

Les fournisseurs de messagerie comme Gmail et Outlook surveillent la part de vos emails qui rebondit. Écrire à des adresses qui n'existent pas leur indique une liste ancienne, achetée ou mal collectée, des habitudes de spammeurs, et ils accordent moins de confiance à votre domaine. Moins de confiance signifie plus d'emails filtrés en spam, y compris ceux destinés à de vrais clients engagés. Le préjudice touche votre domaine et votre IP d'envoi, pas les mauvaises adresses, c'est pourquoi un seul envoi négligent peut affecter tout ce que vous enverrez ensuite.

En général trois choses, à peu près dans cet ordre. Les fournisseurs de messagerie retardent vos emails ou les classent en spam. Votre plateforme d'envoi le remarque, car un taux de rebond élevé met en danger sa propre réputation partagée, et peut examiner, limiter ou suspendre votre compte jusqu'au nettoyage de la liste. Ensuite, la récupération prend du temps : un domaine abîmé doit regagner la confiance par des envois propres et réguliers pendant des semaines, et certaines équipes abandonnent pour passer à un nouveau domaine. Vérifier avant d'envoyer coûte bien moins cher que chacune de ces étapes.

En pratique, les deux mots désignent la même chose, et tous les acteurs du secteur les emploient indifféremment. Là où une distinction est faite, la validation vérifie qu'une adresse est bien formée et que son domaine est réel, tandis que la vérification ajoute le contrôle au niveau de la boîte auprès du serveur destinataire. BounceIntel fait les deux en un seul appel et vous dit quelle étape a produit le verdict.

Non. Le contrôle s'arrête avant la remise. Il ouvre une conversation SMTP avec le serveur destinataire, demande si un message pour cette adresse serait accepté, puis ferme la connexion avant que le moindre corps de message soit transmis. Le titulaire de la boîte ne voit rien et ne reçoit rien.

Pour des boîtes ordinaires chez les grands fournisseurs, une vérification est fiable et le verdict peut être suivi. La précision se dégrade dans deux situations précises et identifiables : les domaines attrape-tout, qui acceptent le courrier pour toutes les adresses et ne permettent donc pas d'en confirmer une en particulier, et les serveurs qui pratiquent le greylisting ou refusent autrement de répondre au trafic de vérification. Nous rapportons les deux comme des verdicts à part plutôt que de les noyer dans un pourcentage. Nous ne publions pas de chiffre de précision affiché, car aucun chiffre du secteur n'est vérifiable de manière indépendante, et un nombre que vous ne pouvez pas contrôler n'est pas un fait.

Les données de contact se dégradent en continu, donc la réponse utile est une périodicité plutôt qu'une opération unique. Vérifiez au point de saisie pour que rien de mauvais n'entre, puis revérifiez tout segment avant de lui écrire s'il est resté dormant plus de quelques mois. Une liste restée un an sans vérification doit être considérée comme inconnue tant qu'elle n'a pas été contrôlée.

Non, et tout fournisseur qui le promet décrit quelque chose d'irréalisable. Une boîte peut être fermée entre le moment où vous la vérifiez et celui où vous envoyez. Une boîte pleine peut rejeter un message une heure après avoir accepté une vérification. La vérification retire les adresses qui n'allaient jamais fonctionner, soit la grande majorité des rebonds évitables, et vous dit lesquelles des restantes sont incertaines.

Délivrable signifie que la boîte existe et accepte le courrier : envoyez. Risqué signifie que l'adresse est réelle mais que quelque chose appelle à la prudence, un compte générique ou un domaine attrape-tout par exemple : envoyez en connaissance de cause. Non délivrable signifie que l'adresse rebondira : n'envoyez pas. Inconnu signifie que le serveur destinataire n'a pas voulu répondre, ce qui est une information sur le serveur plutôt que sur l'adresse.

Le verdict est la réponse catégorielle, le score la réponse graduée. Deux adresses peuvent être toutes deux délivrables alors que l'une est une boîte ancienne chez un grand fournisseur et l'autre un compte tout neuf sur un domaine obscur. Le score porte cette différence pour que vous fixiez votre propre seuil au lieu d'accepter le nôtre. Un niveau de confiance l'accompagne, indiquant sur combien d'éléments il repose.

Un code de raison nomme le constat précis qui a produit le verdict, et il est assez stable pour brancher dessus dans le code. C'est la différence entre un résultat exploitable et un nombre à croire sur parole. Si une adresse est supprimée, le code de raison dit si c'est la syntaxe, le domaine, la boîte ou la réputation du fournisseur qui a tranché, ce qui permet d'expliquer une décision à un collègue, à un client ou à un auditeur des mois plus tard.

Inconnu signifie que le serveur destinataire a refusé de répondre, pas que l'adresse est mauvaise. Certains serveurs appliquent le greylisting aux connexions inconnues et diffèrent tout au premier contact. D'autres limitent ou refusent par principe le trafic de vérification. D'autres encore sont simplement injoignables au moment du contrôle. Traiter inconnu comme non délivrable revient à jeter de bonnes adresses, d'où le fait que ce soit un verdict distinct et non un cas fondu dans un autre.

Un domaine attrape-tout est configuré pour accepter le courrier adressé à n'importe quoi sur ce domaine, que la boîte existe ou non : le serveur répond donc oui à toutes les questions. Aucun vérificateur ne peut prouver qu'une boîte précise se cache derrière un attrape-tout, et celui qui prétend le contraire devine. Nous renvoyons l'adresse comme risquée avec la raison attrape-tout attachée, à vous de décider par segment : souvent un risque acceptable sur une liste chaude, rarement pour de la prospection à froid sur un domaine d'envoi jeune.

Une adresse générique appartient à une fonction plutôt qu'à une personne : info, support, ventes, admin, facturation. Elle est généralement délivrable, donc pas marquée invalide, mais elle est souvent lue par plusieurs personnes ou par aucune, et elle génère plus facilement une plainte sur du courrier marketing. Elle est signalée plutôt que retirée parce que la bonne réponse dépend de ce que vous envoyez. Gardez-les pour le transactionnel et le support, et réfléchissez à deux fois avant de les inclure dans une campagne.

Un piège à spam est une adresse qui n'existe que pour repérer les expéditeurs qui n'entretiennent pas leurs listes. Les pièges vierges n'ont jamais été des adresses valides ; les pièges recyclés sont des boîtes abandonnées réactivées par le fournisseur. Personne ne peut identifier un piège avec certitude depuis l'extérieur, et tout fournisseur revendiquant un détecteur définitif exagère. Ce que fait la vérification, c'est supprimer les conditions dans lesquelles vivent les pièges : adresses dormantes depuis longtemps, adresses qui ne résolvent plus, et listes non contrôlées depuis des années.

Un rebond dur est permanent : l'adresse n'existe pas, ou le domaine n'accepte pas le courrier. Il pèse sur votre réputation d'expéditeur et l'adresse doit être supprimée immédiatement. Un rebond mou est temporaire : boîte pleine, serveur en panne, message trop lourd. La vérification vise les rebonds durs, parce que ce sont les seuls à la fois prévisibles à l'avance et dommageables quand ils surviennent.

Quatre étapes, dans l'ordre, arrêtées dès qu'une réponse est certaine. La syntaxe, qui rejette les adresses mal formées sans aucun trafic réseau. Le DNS et les MX, qui confirment que le domaine existe et publie un serveur de messagerie. La conversation SMTP avec ce serveur, où la boîte elle-même est contrôlée. Et un ensemble de signaux de classification : domaine jetable ou non, adresse générique ou non, boîte désactivée ou pleine, et fournisseur derrière l'adresse.

Bien en dessous de la seconde dans le cas ordinaire, ce qui suffit pour tenir dans un gestionnaire de formulaire d'inscription. La variable, c'est le serveur destinataire : certains répondent immédiatement, d'autres retardent délibérément les connexions inconnues. Fixez un délai adapté à votre formulaire et décidez du repli à l'avance. La plupart des équipes acceptent l'adresse et la marquent plutôt que de bloquer une inscription sur une consultation tierce lente.

Oui. La réponse nomme le fournisseur, Google Workspace ou Microsoft 365 par exemple, ainsi que le degré de certitude de cette identification. C'est utile au-delà de la curiosité : le fournisseur est l'une des entrées du score, et il vous dit lesquels de vos destinataires se trouvent derrière les systèmes de réputation qui comptent le plus pour la délivrabilité.

Oui, à chaque contrôle, sous forme de marqueur dans la réponse et non comme produit séparé. Maintenir votre propre liste de domaines jetables est une course perdue, car de nouveaux apparaissent plus vite que quiconque ne peut les ajouter : c'est exactement pour cela que cela relève d'une consultation et non de votre base de code.

Importez un CSV dans le tableau de bord, ou soumettez les adresses à l'endpoint de traitement en masse et interrogez le résultat. Dans les deux cas le traitement est asynchrone, donc rien n'a à maintenir une connexion ouverte, et l'avancement est lisible pendant l'exécution. Les résultats reviennent avec la même structure par adresse qu'un contrôle unitaire, donc tout ce que vous avez construit pour l'un fonctionne pour l'autre.

Assez grande pour que la limite pratique soit votre solde de crédits plutôt que le traitement lui-même. Les très grandes listes gagnent à être soumises en plusieurs lots, pour commencer à agir sur les premiers résultats pendant que les autres tournent, et pour qu'une reprise ne relance pas tout.

Les résultats sont disponibles en JSON via l'API et en fichier téléchargeable depuis le tableau de bord. Ce fichier contient un jeu fixe de colonnes de résultat indexées sur l'adresse, et non vos lignes d'origine, pour s'importer de la même façon à chaque fois ; rapprochez-le de votre propre système via la colonne adresse. Un rapport de synthèse est également disponible pour partager la physionomie de la liste plutôt que ses lignes.

Pas lors d'un import depuis le tableau de bord : les adresses répétées sont fusionnées avant le lancement, chacune est donc vérifiée et facturée une seule fois. Un traitement soumis via l'API est facturé par adresse présente dans la requête, dédupliquez donc avant de soumettre. Dans tous les cas, c'est une bonne habitude sur les listes assemblées depuis plusieurs sources, où les doublons sont fréquents et gonflent la taille apparente de la liste.

Oui, et c'est la manière principale d'utiliser le produit. Un endpoint REST vérifie une adresse unique, un autre soumet et interroge les traitements en masse, et les deux s'authentifient par jeton porteur. La documentation contient des exemples de requête et de réponse pour chaque endpoint, plus un bac à sable appelable en direct depuis la page.

La documentation montre cURL, TypeScript, Python et Go, tous en appels HTTP simples sans SDK. C'est délibéré : l'API est assez petite pour qu'un SDK ajoute une dépendance sans retirer de travail, et un appel fetch brut se lit et se vérifie dans n'importe quel langage.

Les erreurs reviennent avec un code lisible par machine et stable, à côté du statut HTTP, pour que la logique de réessai branche sur le code plutôt que d'analyser un message. Une limite de débit et un solde de crédits épuisé renvoient tous deux 429 mais avec des codes différents, parce que l'un mérite un réessai après pause et l'autre non. La documentation liste chaque code et l'action correspondante.

Oui. La documentation inclut un bac à sable qui émet de vraies requêtes vers la vraie API, pour voir une réponse réelle avant d'écrire la moindre ligne de code.

Vous pouvez détenir plusieurs clés à la fois et révoquer chacune indépendamment, ce qu'il faut pour séparer la préproduction de la production, ou pour confier à un prestataire une clé retirable sans tout faire tourner.

Un crédit vérifie une adresse, qu'elle vienne de l'API, d'un import en masse ou du tableau de bord. Les crédits s'achètent en formules mensuelles ou en packs à l'usage, et le tarif au crédit baisse quand le volume monte. Pas de facturation séparée pour l'API, pas de frais par utilisateur, pas d'engagement minimum.

Un contrôle qui atteint le serveur destinataire consomme un crédit quelle que soit la réponse, y compris inconnu, parce que le travail a été fait et que le résultat est une véritable information sur ce serveur. Une requête qui échoue avant toute vérification, une requête mal formée par exemple, n'en consomme pas.

L'API renvoie 429 avec un code de quota distinct du code de limite de débit, pour que votre intégration distingue attendre de recharger. Rien n'est supprimé et aucun traitement n'est perdu : ajoutez des crédits et le même traitement reprend.

Les crédits à l'usage restent sur le compte. Les crédits de formule se renouvellent au rythme de la formule. La page des tarifs énonce explicitement les conditions de chaque formule plutôt qu'en note de bas de page, parce que les crédits qui expirent sont la mauvaise surprise la plus fréquente du secteur.

Une facture est émise pour chaque paiement et reste disponible dans l'espace de facturation. Pour un engagement annuel, de plus gros volumes ou des exigences d'achat, écrivez-nous et nous chiffrerons sur votre volume réel plutôt que de vous pousser vers le palier publié le plus proche.

Les nouveaux comptes démarrent avec une dotation de crédits, de quoi vérifier un échantillon réel de vos propres données avant de décider. Aucune carte n'est demandée pour l'utiliser.

Elles sont traitées pour produire le verdict demandé, et pour rien d'autre. Vos adresses ne sont ni vendues, ni partagées, ni ajoutées à une liste, ni utilisées pour constituer une base revendue à qui que ce soit. La politique de confidentialité le dit en détail et l'accord de traitement des données le rend contractuel.

Les résultats de vérification restent disponibles dans votre compte aussi longtemps que vous en avez besoin, et les données d'un traitement en masse peuvent être supprimées depuis le tableau de bord dès que vous avez téléchargé les résultats. Les durées de conservation sont détaillées dans la politique de confidentialité.

Oui. Il existe une page RGPD décrivant comment le règlement s'applique spécifiquement à la vérification d'emails, un accord de traitement des données ouvert à tous les clients, et une liste publiée des sous-traitants impliqués dans la fourniture du service. Les trois sont liés depuis le pied de page de chaque page.

La plateforme de vérification et sa base de données sont hébergées dans l'Union européenne. Quelques services de support, dont les paiements et les emails transactionnels, opèrent en partie en dehors ; la page des sous-traitants nomme chaque tiers, précise son rôle et sa localisation, pour que vous puissiez mener votre évaluation fournisseur sans avoir à demander.

Les clés d'API sont affichées une seule fois et stockées sous forme de hachage : une clé ne peut pas être retrouvée de notre côté, seulement remplacée. Chaque clé est révocable individuellement. L'accès aux systèmes de production est limité aux personnes qui en ont besoin, et les mesures de sécurité que nous appliquons sont décrites sur les pages légales plutôt que présentées comme des badges.

Écrivez directement au support. Aucune file de tickets à traverser, aucun palier à acheter avant qu'un humain réponde. Indiquez l'adresse ou l'identifiant du traitement concerné et la réponse sera précise plutôt que générique.

Oui. Le volume est mutualisé sur le compte, ce qui rend l'exercice intéressant pour une agence ou une équipe qui gère plusieurs clients : un solde, un tarif, des clés distinctes.

Oui, depuis les paramètres du compte, et la suppression est confirmée plutôt que silencieuse. Elle retire le compte et les données associées, sous la seule réserve des enregistrements que nous sommes légalement tenus de conserver, listés dans la politique de confidentialité.

Le site et l'interface du produit sont disponibles en anglais, français, espagnol, italien et allemand. Le support répond en anglais.