Entreprise

Conçu pour les équipes dont les emails doivent arriver en boîte de réception.

Une campagne part, le taux de rebond s'envole et le domaine d'envoi en paie le prix : les emails finissent en spam et quelqu'un doit expliquer pourquoi. BounceIntel existe pour que cette liste ne soit jamais envoyée, et pour montrer précisément pourquoi chaque adresse a été retirée.

01Pourquoi nous existons

Un verdict ne vaut que par le raisonnement qui le porte.

Toute équipe qui envoie des e-mails finit par heurter le même mur. Une campagne part, le taux de rebond s'envole, le domaine expéditeur encaisse le coup sur sa réputation, et quelqu'un doit expliquer en réunion ce qui s'est passé. L'outil de vérification censé l'éviter renvoie une couleur et un pourcentage, et ni l'un ni l'autre n'est une explication.

BounceIntel repose sur l'hypothèse inverse : dans une vérification, l'intéressant, ce sont les preuves, pas la conclusion. Chaque contrôle renvoie les codes de motif qui ont produit le verdict, les signaux qui les sous-tendent et un niveau de confiance qui dit honnêtement ce que le pipeline a réellement pu établir.

Cela change la nature de l'outil. Il cesse d'être un filtre auquel on se fie aveuglément pour devenir une source que l'on peut citer : dans une revue de délivrabilité, dans une analyse de protection des données, ou face au collègue qui veut savoir pourquoi quatre mille adresses ont été mises de côté.

02Fonctionnement

Cinq étapes, et un résultat qui montre son raisonnement.

Le même pipeline alimente le vérificateur gratuit de la page d'accueil, le tableau de bord, un import en masse et l'API. Il n'existe pas de voie premium qui vérifierait mieux.

01

Syntaxe et normalisation

L'adresse est analysée selon les règles de la norme, pas selon une expression régulière trouvée au hasard. Lorsqu'un domaine ressemble à une faute de frappe pour un grand fournisseur, nous le signalons au lieu d'échouer en silence : une coquille détectée ici, c'est un crédit non dépensé plus loin.

02

Résolution du domaine et des MX

Nous résolvons le domaine et lisons ses enregistrements MX. Un domaine sans MX ne peut recevoir aucun courrier : c'est une réponse définitive obtenue avant même d'ouvrir une connexion, et la catégorie d'adresse invalide la moins coûteuse à éliminer.

03

Règles des fournisseurs

Les grands fournisseurs appliquent leurs propres règles sur la partie locale (longueur minimale, caractères interdits, mots réservés) et rejettent les adresses qui les enfreignent, qu'une boîte puisse exister ou non. Appliquer ces règles avant la conversation SMTP évite l'aller-retour et produit un code de motif plus précis.

04

Interrogation SMTP

Nous ouvrons une conversation avec le serveur destinataire et l'interrogeons sur le destinataire, sans jamais délivrer de message. C'est là que se révèlent les configurations catch-all, les boîtes désactivées et les boîtes pleines, et là qu'un serveur répondant à l'identique pour toutes les adresses se trahit.

05

Score et codes de motif

Les signaux sont combinés en un score, une catégorie, une action recommandée et les codes de motif qui les expliquent. Lorsque les preuves ne permettent pas de trancher, le résultat indique « inconnu ». C'est un constat, pas un échec, et le traiter comme tel évite d'écarter de bonnes adresses.

03Principes

Les règles que nous nous imposons.

La plupart nous coûtent quelque chose. C'est à peu près le test qui distingue un principe d'un slogan.

01

L'incertitude est signalée, pas dissimulée

Un domaine catch-all ne peut réellement pas être tranché de l'extérieur. Nous l'identifions et vous expliquons ce que cela implique pour votre risque, au lieu de deviner pour que le tableau de bord paraisse catégorique.

02

Vos adresses ne sont pas notre jeu de données

Rien de ce que vous soumettez ne sert à construire un annuaire, à enrichir un produit que nous vendons ou à entraîner quoi que ce soit. Les adresses en masse ne sont jamais écrites dans notre base : seulement dans le rapport que vous téléchargez, qui expire.

03

Un seul pipeline, une seule réponse

La vérification gratuite de la page d'accueil exécute le même code qu'un appel API d'entreprise. Il n'y a pas de voie moins chère et moins précise cachée derrière un tarif plus bas.

04

L'explicabilité par défaut

Les codes de motif font partie de chaque réponse : ce n'est ni une option payante ni un mode de débogage. Si nous ne pouvons pas vous dire pourquoi, le verdict n'a pas mérité votre confiance.

05

Nous refusons du travail

Les listes scrapées, les listes achetées et l'énumération d'adresses sont refusées, et les comptes concernés sont fermés. Un service de vérification qui ne contrôle pas ce qu'on lui envoie devient l'outil de ceux contre qui il devrait protéger.

06

La conservation est un défaut, pas un réglage

Les rapports expirent d'eux-mêmes. En supprimer un supprime les adresses, car il n'existe pas de seconde copie dormant dans une base que l'on finirait par oublier.

04En chiffres

L'échelle, dite simplement.

Le volume ne remplace pas la précision, mais c'est lui qui la rend mesurable : plus un pipeline a vu de boîtes aux lettres, mieux il connaît le comportement de chaque fournisseur.

1B+
Adresses e-mail validées, et ce n'est pas fini
40
Codes de motif dans la taxonomie publiée
< 500ms
Latence médiane pour une vérification unitaire
UE
Où la vérification s'exécute et les données résident

05FAQ

Les questions avant de nous confier une liste

Qui est derrière BounceIntel ?

Une société indépendante établie dans l'Union européenne. Le service que vous appelez sur api.bounceintel.com est le nôtre, construit et exploité en interne plutôt que revendu depuis un autre fournisseur. Les informations d'immatriculation figurent sur la page contact et dans nos documents juridiques.

Conservez-vous les adresses que j'importe ?

Pas dans notre base. Une liste en masse n'existe que dans les fichiers de rapport générés pour vous : ils sont stockés hors de la racine web, accessibles uniquement via un téléchargement authentifié, et supprimés à l'expiration de leur durée de conservation. Ce que nous gardons est agrégé : combien sont revenues sûres, risquées, invalides ou inconnues.

Pourquoi certaines vérifications renvoient-elles « inconnu » ?

Parce que certains serveurs refusent de dire si une boîte existe, et que d'autres sont temporairement injoignables. Inventer un verdict dans ces cas-là, c'est ainsi qu'un outil de vérification finit par écarter de bons clients. Nous vous disons ce qui s'est passé et vous laissons décider.

Comment traitez-vous un domaine catch-all ?

Un catch-all accepte toutes les adresses : aucun test externe ne peut distinguer une vraie boîte d'une adresse inventée. Nous identifions la configuration, évaluons le risque à partir des autres signaux disponibles (comportement du fournisseur, réputation du domaine, historique des envois) et indiquons honnêtement le niveau de confiance.

Puis-je l'utiliser sur une liste achetée ?

Non. Notre politique d'utilisation acceptable interdit les listes achetées, scrapées ou courtées, et nous la faisons appliquer. La vérification confirme que des adresses que vous détenez déjà licitement sont toujours actives ; elle ne rend pas utilisable une liste qui ne l'est pas.

Proposez-vous un accord de traitement des données ?

Oui, et il s'applique automatiquement dans le cadre de nos conditions : vous n'avez rien à signer pour qu'il nous engage. Si votre processus d'achat exige un exemplaire contresigné, ou les clauses contractuelles types signées séparément, demandez-le et nous l'organiserons.

Envoyez-nous la liste dont vous doutez le plus.

100 crédits à l'inscription, sans carte bancaire, et le même pipeline que celui d'un appel API d'entreprise.