Couleurs de vérification email dans TOM : ce que vert, jaune et rouge signifient vraiment

La version courte

Deux choses à remarquer d'emblée. D'abord, la correspondance est ordonnée : TOM lit les tranches de score de haut en bas, donc chaque adresse tombe dans exactement une ligne. Ensuite, il y a sept verdicts derrière trois feux — le rouge couvre quatre situations différentes (unknown, disposable, risky, invalid) qui échouent pour des raisons totalement différentes. La suite de ce guide détaille chacune.

Avant la couleur : ce que la vérification contrôle vraiment

Le feu est la dernière étape d'un pipeline en six étapes. Connaître ces étapes compte, car chaque couleur dit vraiment où l'adresse a échoué ou réussi :

1. Contrôle de syntaxe. L'adresse est-elle bien formée (un seul @, partie locale et domaine valides) ? Une adresse mal formée ne dépasse jamais cette étape — elle devient invalid avec la raison invalid_syntax.
2. Contrôle du domaine. Le domaine existe-t-il et se résout-il en DNS ? Un domaine mort ou non enregistré devient invalid (no_mx_records, ou spf_reject_all quand le domaine rejette explicitement tout courrier entrant).
3. Contrôle des enregistrements MX. Le domaine publie-t-il des serveurs mail capables de recevoir des emails ? Sans enregistrements MX, aucune boîte de réception n'existe — à nouveau invalid.
4. Détection jetable. Le domaine figure-t-il sur la liste des 5 000+ fournisseurs d'emails temporaires connus (Mailinator, 10MinuteMail, Guerrilla Mail et similaires, mise à jour quotidienne) ? En cas de correspondance, cela devient disposable, que la boîte mail existe techniquement ou non.
5. Contrôle SMTP. L'étape décisive : BillionVerify se connecte au serveur mail du destinataire et demande, via RCPT TO, si la boîte mail précise existe. Un 250 OK la confirme (valid) ; un 550 user unknown l'élimine (invalid, mailbox_not_found). Tout ce qui est ambigu — timeouts, greylisting, limites de débit, sondes bloquées — devient unknown ou catchall.
6. Calcul du score. Tous les résultats d'étapes sont combinés en un score de confiance de 0,0 à 1,0. La confirmation SMTP pèse le plus lourd (environ 30 %), suivie des enregistrements MX, de l'existence du domaine, du statut jetable et des signaux de réputation.

Au-dessus de ce pipeline s'ajoutent deux détections orthogonales : les motifs role-based (s'agit-il d'une boîte partagée ?) et le filtrage de réputation contre la Domain Blocklist de Spamhaus (ce domaine est-il une source confirmée de spam, phishing, malware ou botnet ?). Ils produisent respectivement les verdicts role et risky.

Vert : valid

Vert est le seul verdict qui confirme la boîte mail individuelle, pas seulement le domaine. La syntaxe est valide, le domaine existe, les enregistrements MX sont publiés, l'adresse n'est pas jetable, et le serveur destinataire a explicitement accepté le destinataire. La confiance est élevée — dans l'échelle BillionVerify, c'est la tranche 0,9–1,0, « highly confident valid ».

Que faire : inclure dans les campagnes à froid sans hésiter. Les adresses vertes sont l'épine dorsale de chaque envoi ; le seuil de qualité par campagne dans TOM existe précisément pour garder leur part élevée.

Jaune : catch-all

Catch-all est une propriété du domaine, pas de l'adresse. Les petites entreprises et les installations auto-hébergées configurent souvent leur serveur mail — ou une passerelle de sécurité comme Mimecast ou Proofpoint en mode accept-all, ou un relais interne Microsoft 365 — pour accepter chaque destinataire plutôt que de rejeter les inconnus. La conversation SMTP ne prouve donc rien sur le fait que marco@ fonctionne vraiment là-bas.

Les codes de raison typiques derrière un catch-all incluent catch_all_domain (sonde aléatoire acceptée), catch_all_deliverable (domaine catch-all où l'adresse précise a aussi renvoyé 250 OK), gateway_accept_all et m365_internal_relay. Les services d'alias de transfert (SimpleLogin, Firefox Relay, Duck.com) et certains domaines grand public régionaux atterrissent ici aussi.

Pourquoi jaune et pas vert ? Parce que le risque de bounce est structurellement plus élevé : vous envoyez à une adresse que le vérificateur n'a pas pu confirmer individuellement. Pourquoi jaune et pas rouge ? Parce que beaucoup d'adresses catch-all sont de vraies personnes dans de vraies entreprises — les écarter toutes jetterait des prospects légitimes, surtout dans le segment SMB.

Jaune : role-based

Une subtilité de la documentation : les adresses de rôle héritent du code de raison de leur contrôle SMTP sous-jacent — il n'existe pas de codes de raison dédiés pour ce statut. Une adresse de rôle qui a passé le SMTP affiche reason: smtp_deliverable, exactement comme une adresse verte. C'est le drapeau role (is_role: true) qui la distingue.

Toutes les adresses de rôle ne portent pas le même risque. En règle générale, d'après la référence BillionVerify :

Pourquoi jaune ? La boîte mail existe, donc le rouge serait faux — mais un cold email vers info@ est en concurrence avec tous les autres messages entrants de cette entreprise, et certains fournisseurs restreignent purement les adresses de rôle. Très bien pour l'email transactionnel ; pour le cold outreach, à utiliser en connaissance de cause en s'attendant à des taux de réponse plus faibles.

Rouge : unknown

Unknown est le verdict le plus mal compris, car « unknown » semble neutre alors que TOM affiche rouge. Le rouge est intentionnel : une adresse dont la validité ne peut pas être confirmée porte le même risque d'envoi qu'une mauvaise adresse jusqu'à preuve du contraire. C'est pourquoi TOM vous guide vers un cold outreach fait correctement et bloque les adresses rouges au lieu de vous laisser parier un bounce dessus.

Les causes courantes se divisent en deux groupes :

• Temporaires et réessayables — à vérifier à nouveau : smtp_timeout, smtp_rate_limited, smtp_greylisted (y compris la variante Mimecast), recherches async Proofpoint, rejets temporaires Google et Microsoft 365, timeouts DNS et erreurs internes transitoires.
• Structurelles et non réessayables — réessayer ne changera pas le résultat : fournisseurs qui bloquent les sondes SMTP par principe (Apple iCloud, courrier grand public Microsoft, Proton, Tuta, domaines d'opérateurs japonais), serveurs qui ont bloqué la connexion de sonde, configurations DMARC désalignées, boîtes mail pleines ou désactivées, et comptes configurés pour sauter la vérification SMTP.

Règle pratique : revérifiez une fois après un délai — greylisting et limites de débit se résorbent souvent, et l'adresse peut passer au vert ou au jaune et devenir sélectionnable. Tant qu'elle reste unknown, elle demeure exclue par défaut et ne peut pas être ajoutée à une campagne à froid.

Rouge : disposable et risky

Disposable (is_disposable: true, raison disposable_domain) couvre Mailinator, 10MinuteMail, Guerrilla Mail, TempMail et des milliers de petits générateurs. Ces adresses s'engagent rarement, sont souvent utilisées pour le spam ou la fraude, et signalent une valeur vie quasi nulle — particulièrement dommageable dans les flux d'inscription.

Risky est le verdict absent de la plupart des résumés, il mérite donc une explication complète. Il signifie que la boîte mail accepte très probablement le courrier (is_deliverable: true), mais que le domaine destinataire est listé dans la Domain Blocklist de Spamhaus pour spam, phishing, distribution de malware ou commande-et-contrôle botnet. Le tableau risk_reasons dit lequel : spamhaus_dbl_spam, spamhaus_dbl_phish, spamhaus_dbl_malware ou spamhaus_dbl_botnet_cc. Y envoyer peut endommager votre propre réputation d'expéditeur, donc l'action recommandée est identique à disposable : retirer de la liste. Réessayer ne change jamais un résultat risky.

Un élément rassurant de la documentation : les domaines signalés par Spamhaus comme sites légitimes abusés — un site d'entreprise normal qui a été compromis — ne produisent jamais de résultat risky. Un site piraté ne signifie pas que les boîtes mail de cette entreprise sont mauvaises.

Rouge : invalid

Invalid est le verdict négatif le plus confiant (score autour de 0,1). Codes de raison typiques : invalid_syntax (adresse mal formée), no_mx_records (domaine sans serveur mail), spf_reject_all (domaine rejetant explicitement tout courrier entrant), mailbox_not_found (serveur ayant renvoyé 550 / user unknown) et host_not_found (l'hôte MX lui-même est injoignable).

Il n'y a pas de « peut-être » ici et aucune logique de réessai qui aide : une adresse invalid rebondira à chaque fois. En cold outreach, c'est un coût pur — un bounce, un coup à la réputation, et un prospect qui n'a jamais existé.

Score ou statut : qui décide de la couleur ?

Les deux — et ils ne sont jamais en désaccord. Chaque statut porte un score fixe, donc les deux lectures sont équivalentes :

Voyez le score comme la forme lisible par machine du statut, et la couleur comme la forme lisible par humain du score. TOM évalue les tranches de haut en bas — le premier seuil atteint par le score gagne — c'est pourquoi une adresse ne peut jamais avoir qu'un seul feu. Le drapeau is_deliverable suit la même logique : true pour valid (et techniquement pour risky), false pour invalid, null pour unknown et catch-all où la délivrabilité est vraiment indéterminée.

Que faire de chaque couleur dans TOM

La vérification n'est utile que si elle change ce que vous envoyez. Dans TOM, c'est le cas par conception : les adresses rouges sont exclues par défaut et ne peuvent pas être sélectionnées pour une campagne à froid — vous guider vers un cold outreach fait correctement signifie ne pas vous laisser envoyer vers des adresses qui rebondiraient à coup sûr. Vert et jaune sont sélectionnables ; le seuil de qualité par campagne décide ensuite combien de jaune un envoi peut contenir.

Dans TOM, cela se joue à trois endroits : le feu par adresse vous dit ce que vaut chaque contact, le seuil de qualité minimal par campagne garde la part de vert élevée parmi les adresses sélectionnables, et le pre-flight check avant lancement stoppe une campagne dont la qualité de liste brûlerait le domaine. Les adresses rouges n'arrivent jamais jusque-là — elles sont filtrées avant la sélection. Les crédits de vérification n'expirent jamais, donc revérifier une adresse unknown la semaine prochaine — ou nettoyer une liste restée inactive 90 jours — ne coûte rien de plus, et une adresse qui passe au vert ou au jaune devient sélectionnable.

Quand le résultat surprend : les codes de raison

Chaque verdict est livré avec un champ reason — un identifiant chaîne stable qui explique pourquoi l'adresse a reçu son statut. Quand un feu semble faux, c'est la raison qu'il faut regarder. Les plus utiles à reconnaître :

• Semble rouge alors que vous attendiez vert : mailbox_not_found (faute de frappe dans l'adresse ou employé parti), no_mx_records (domaine sans mail), smtp_blocked ou smtp_unverifiable (le fournisseur refuse les sondes — courant avec iCloud, le courrier grand public Microsoft, Proton et Tuta).
• Semble jaune alors que vous attendiez vert : catch_all_domain ou gateway_accept_all (le domaine accepte tout), ou un smtp_deliverable hérité associé à is_role: true (une boîte fonctionnelle mais partagée).
• Bloqué sur unknown : vérifiez si la raison est réessayable (smtp_timeout, smtp_rate_limited, smtp_greylisted, google_rate_limit, dns_timeout) ou structurelle (smtp_unverifiable, carrier_blocked, mailbox_full). Seul le premier groupe s'améliore au réessai.
• Score 0,3 sans cause évidente : vérifiez risk_reasons. Une entrée spamhaus_dbl_* signifie que le domaine est bloqué — l'adresse n'est pas « de faible qualité », elle est activement dangereuse pour votre réputation.

Deux drapeaux compagnons aident à segmenter au-delà de la délivrabilité : is_free (Gmail, Yahoo, Outlook — utile pour le scoring B2B vs B2C et la détection de fraude) et smtp_check (si la sonde SMTP profonde a vraiment tourné, ou si le verdict repose sur des heuristiques au niveau du domaine).

FAQ

Ce guide fait partie du blog TOM. Les statuts et scores de vérification suivent la documentation verification-types de BillionVerify et la référence verification-reasons. À lire aussi : les 12 frameworks de cold email, 12 alternatives de logiciels de cold email comparées et le warmup comme comportement de plateforme.