Vérification des listes e-mail : contrôles, risques et API

Vous avez constitué une liste et lancé une campagne. Les ouvertures ont baissé et les rejets ont augmenté. Peu après, des messages arrivent dans les indésirables, sans cause évidente. Une arobase et un domaine ne suffisent pas, et une adresse utilisée sans problème il y a trois mois peut avoir changé. Le relevé estime une dégradation de 2 à 3 pour cent par mois, sans en faire une règle universelle. Les adresses utilisées en janvier méritent une nouvelle vérification en avril.

La vérification des listes d'adresses e-mail examine les destinataires avant l'envoi, au-delà de la syntaxe et de l'existence du domaine. Le relevé décrit 25 signaux : recherches MX, informations SPF, heuristiques de pièges à spam et sondages SMTP. Les enregistrements du destinataire ne vérifient pas l'alignement de vos messages, et les pièges ne peuvent pas être détectés de manière fiable. Le score aide à examiner les risques ; il ne prouve ni identité, ni consentement, ni livraison.

La vérification peut contribuer à la délivrabilité avec le consentement, la pertinence, l'authentification et le suivi des incidents. Elle ne remplace pas ces mesures et ne garantit pas la réputation du domaine.

Comment une liste obsolète peut nuire aux envois

Google, Microsoft, Yahoo et Apple peuvent examiner rejets, plaintes et interactions selon leurs politiques. Une liste contenant des adresses obsolètes peut dégrader ces indicateurs, mais aucune mesure n'explique à elle seule le classement des messages.

D'abord, les rejets permanents peuvent augmenter. Une réponse 5xx ne désigne pas toujours une adresse inexistante : elle peut correspondre à une restriction ou à une politique de refus. Les taux de 2 pour cent et de 5 pour cent cités dans le relevé sont indicatifs, pas des seuils universels. Analysez les motifs et suspendez les nouvelles tentatives lorsque cela convient.

Ensuite, il existe un risque de pièges à spam. Des opérateurs réseau et gestionnaires de listes de blocage peuvent utiliser des adresses pour repérer des pratiques problématiques. Certaines sont d'anciennes boîtes réaffectées ; d'autres n'ont jamais appartenu à une personne. Elles peuvent figurer dans des listes achetées ou collectées sans autorisation, mais aucun vérificateur ne peut toutes les exclure avec certitude. Leur effet dépend de l'opérateur et du contexte, sans conséquence unique garantie.

Enfin, les indicateurs d'interaction peuvent se dégrader. Les destinataires qui ne reçoivent pas les messages ou n'en veulent pas n'apportent pas l'engagement attendu. Les fournisseurs peuvent tenir compte de ces signaux parmi d'autres ; les ouvertures ne constituent pas non plus une mesure parfaite. Vérifier une liste ne démontre pas la pertinence d'une campagne et n'élimine pas tout filtrage.

Ce que vérifie le contrôle d'une liste d'adresses

Un système peut combiner contrôles et signaux de risque plutôt que se limiter à valide ou invalide. Le relevé présente TrekMail avec 25 contrôles répartis en deux phases. Vérifiez le périmètre de l'implémentation actuelle avant d'utiliser ces exemples.

Phase 1 : contrôles de base

Dans le modèle décrit, ces contrôles peuvent classer une adresse comme invalide avec un score nul. Il s'agit d'une décision du système, pas d'une preuve universelle qu'aucun message ne peut être reçu.

Dans le modèle du relevé, réussir les sept contrôles conduit à la phase 2 avec un score initial de 100.

Phase 2 : signaux et score de risque

Les contrôles supplémentaires retirent des points ou ajoutent des indicateurs. Le score final classe le résultat du système ; il n'identifie pas une personne réelle.

Catégories de score

Le modèle du relevé répartit les résultats en quatre catégories. Ces étiquettes expriment une estimation heuristique, pas une autorisation d'envoyer.

Un score apporte du contexte, mais ne décide pas seul de l'usage. Un résultat de 62 doit être examiné avant utilisation pour une lettre d'information ou un message transactionnel. Un score de 85 avec une adresse fonctionnelle ne prouve pas non plus l'autorisation d'une campagne B2B. Tenez compte du consentement, de la finalité et du flux concerné.

Modes Quick et Deep

Le relevé décrit deux niveaux de vérification. Confirmez leur périmètre actuel et choisissez selon le contexte, sans confondre profondeur et certitude.

Quick comprend les contrôles de la phase 1 et certains signaux de la phase 2 : syntaxe, domaines temporaires, MX, adresses fonctionnelles, motifs aléatoires, fautes de frappe, signe plus et suppression après rejet. Les recherches MX utilisent bien DNS sur le réseau. Le relevé indique 1 crédit par adresse et des résultats en millisecondes, mais la latence dépend du service. Ce mode peut convenir aux formulaires, webhooks et listes récemment examinées.

Deep applique les 25 contrôles décrits, dont SMTP, DNSBL, RDAP, Gravatar, heuristiques de pièges et fuites connues, pour 2 crédits selon le relevé. Il peut aider à examiner des campagnes autorisées ou des données anciennes. Vérifier une liste achetée ou collectée ne fournit ni consentement ni fondement valable pour l'utiliser.

Vérifier des listes complètes

Une vérification individuelle peut servir aux formulaires et intégrations API. Pour examiner 10,000 ou 50,000 adresses avant une campagne autorisée, envisagez un traitement par lots.

Le relevé décrit des tâches allant jusqu'à 50,000 adresses, soumises en CSV ou XLSX dans le tableau de bord, ou par API. Il mentionne aussi la déduplication pour ne pas facturer plusieurs fois une adresse dans la même tâche. Vérifiez les limites, formats et règles de crédits actuels.

L'architecture décrite comporte trois étapes : analyse du fichier et préchargement DNS par domaine unique, répartition des lots avec une planification round-robin, puis contrôles en parallèle. Cette organisation vise à répartir les ressources entre comptes ; elle ne garantit ni délais identiques ni absence d'attente.

Selon l'implémentation, le tableau de bord affiche progression et répartition entre safe, valid, risky et invalid. À la fin, des exports CSV filtrés permettent notamment de réexaminer les avertissements. Aucune catégorie n'autorise à elle seule l'envoi.

Le relevé indique une conservation des résultats pendant 15 jours, suivie d'une suppression. Vérifiez la politique actuelle : cela ne signifie pas que sauvegardes, journaux et autres données sont tous effacés simultanément.

Intégration par API

L'API REST décrite permet de consulter et demander des vérifications avec un jeton bearer. Utilisez les droits nécessaires : verify:read pour les résultats et verify:write pour les demandes. Vérifiez offre, autorisations et endpoints actuels. Les exemples conservent le format du relevé, y compris un littéral de guillemets endommagé ; ce ne sont pas des commandes prêtes à exécuter.

Vérification individuelle

curl -X POST https://trekmail.net/api/v1/verify   -H "Authorization: Bearer tm_live_your_token"   -H "Content-Type: application/json"   -d \x27{"email": "user@example.com", "mode": "deep"}\x27

La réponse illustrative contient score, catégorie et contrôles exécutés. Une acceptation SMTP ne prouve ni l'existence de la boîte ni la livraison ultérieure :

{
  "status": "safe",
  "score": 95,
  "mode": "deep",
  "checks": {
    "syntax": true,
    "mx": true,
    "disposable": false,
    "role_based": false,
    "gibberish": false,
    "dnsbl_listed": false,
    "domain_age_days": 365,
    "smtp_status": "accepted"
  }
}

Soumission d'une tâche groupée

curl -X POST https://trekmail.net/api/v1/verify/bulk   -H "Authorization: Bearer tm_live_your_token"   -H "Content-Type: application/json"   -d \x27{
    "emails": ["a@example.com", "b@test.com"],
    "name": "March campaign cleanup",
    "mode": "deep"
  }\x27

Selon l'API décrite, la demande renvoie un identifiant de tâche. Consultez son état ou configurez un webhook compatible pour connaître la fin du traitement. Résultats paginés et exports filtrés dépendent de l'endpoint et des autorisations disponibles.

Le relevé cite 60 vérifications individuelles par minute, 10 soumissions groupées par minute et 120 consultations d'état par minute. Confirmez les limites actuelles et gérez les réponses de restriction.

Le relevé décrit aussi huit outils MCP (Model Context Protocol) pour vérifier, soumettre des tâches, consulter les crédits et télécharger les résultats. Leur utilisation dans Claude Desktop, Claude Code, Cursor ou d'autres clients dépend de la compatibilité, des droits et des fonctions disponibles.

Quand réexaminer votre liste

Un contrôle ponctuel ne garantit pas qu'une liste reste actuelle. Les personnes changent d'emploi et les domaines peuvent expirer. Passer de 95 pour cent d'adresses sans avertissement en janvier à 85 pour cent en juin est un exemple du relevé, pas une évolution universelle.

Avant une campagne importante. Pour une liste étendue et autorisée, examinez les adresses et l'historique des envois. La référence de 5 pour cent de rejets est indicative ; analysez les motifs plutôt que d'attribuer automatiquement une conséquence réputationnelle.

Après une période sans envoi. Le relevé propose de réexaminer les segments après 90 jours ou davantage. C'est une indication, pas un délai universel. Vérifiez aussi que l'autorisation et la relation avec le destinataire restent valables.

Lors d'un import externe. Achats, inscriptions à des événements, données de partenaires ou collecte automatisée exigent de vérifier provenance, autorisation et finalité. Deep ne transforme pas des adresses achetées ou extraites en liste utilisable sans consentement.

Au moment de la collecte. Une vérification dans un formulaire ou parcours d'achat peut repérer des fautes possibles. Testez latence, erreurs et confidentialité ; Quick n'élimine pas toutes les données incorrectes, et un résultat incertain ne doit pas bloquer automatiquement une personne légitime.

Périodiquement. Adaptez une fréquence mensuelle ou trimestrielle à l'activité, à l'historique et aux risques. Combinez-la avec désinscriptions, suppression des destinataires et suivi des plaintes.

Crédits et tarifs

Le relevé décrit des crédits mensuels inclus, réinitialisés périodiquement. Le tableau contient des tarifs endommagés ou absents : ils sont conservés pour signaler l'erreur, pas comme prix valables. Consultez l'offre actuelle.

Pour des crédits supplémentaires, consultez le tableau de bord et le calculateur sur la page du vérificateur d'adresses. Les prix par volume et remises dépendent des tarifs en vigueur.

Le relevé attribue 1 crédit à Quick et 2 à Deep, avec déduplication dans la tâche groupée et restitution des crédits non traités en cas d'annulation. Vérifiez le calcul et le moment où les ajustements sont appliqués.

Une vérification intégrée à la messagerie

Certains services de vérification d'adresses sont distincts de l'envoi. Ils peuvent aussi s'intégrer à d'autres produits et utiliser l'historique des rejets lorsqu'il leur est fourni.

L'intégration du vérificateur à TrekMail peut simplifier l'utilisation des données du compte. Cela ne signifie pas que les services externes ne peuvent pas proposer des intégrations similaires.

Suppression automatique après rejet. Le relevé décrit l'ajout des rejets permanents à une liste d'exclusion, consultée pendant la phase 1. Vérifiez classification, actualisation et périmètre. D'autres fournisseurs peuvent également intégrer un historique d'envoi avec les autorisations nécessaires.

Protection dans Postfix. Le relevé indique une synchronisation de la liste toutes les 5 minutes. Son application dépend du moment et de la configuration : ce n'est ni un blocage instantané de tout destinataire problématique ni une garantie de réputation intacte.

Compte, tableau de bord et droits partagés peuvent simplifier l'accès à la messagerie et à la vérification. Vérifiez offre, facturation et jetons ; limitez les privilèges de chaque intégration.

Sécurité et confidentialité

Vérifier suppose de traiter les adresses d'autres personnes. Examinez finalité, minimisation des données, contrôles et conditions du service.

• Chiffrement TLS pour API et tableau de bord selon la configuration ; vérifier la connexion et protéger les jetons.
• Suppression automatique des résultats groupés après 15 jours selon le relevé ; journaux et sauvegardes à examiner séparément.
• Suppression sur demande par API (DELETE /api/v1/verify/bulk/{jobId}) selon les droits ; cette fonction ne garantit pas à elle seule la conformité au RGPD.
• Pas de stockage du contenu des messages dans le périmètre décrit. Le vérificateur examine les adresses ; vérifier les autres données traitées et les politiques actuelles.
• Atténuation des signaux temporels. Le relevé cite un minimum de 200ms pour les réponses individuelles ; ce délai n'élimine pas toutes les attaques fondées sur le temps.

Essayer le vérificateur

Le relevé présente une démonstration du vérificateur TrekMail sans inscription ni carte. Utilisez une adresse vous appartenant ou autorisée et examinez score et contrôles. Disponibilité et délai varient ; le résultat ne garantit ni boîte réelle ni livraison.

Pour une liste autorisée, consultez crédits et offres actuels. Le relevé cite 10 crédits mensuels gratuits et Pro à 0/month avec 300 crédits ; ce tarif est endommagé et ne doit pas être considéré comme valable. Vérifiez API, Deep et autres fonctions avant de souscrire.

Vérifiez provenance, autorisation et actualité de votre liste. Examinez les adresses avant votre prochain envoi.